Založení a design webu a eshopu taneční školy
Zobrazují se odpovědi 1 až 23 z 23

Nespuštění / nefunkční skript přes CRON

  1. Prosím o radu. Mám managed server u Českého hostingu, kde nastavuji přes webcron URL skriptu ke spuštění.

    Když skript spustím přímo / ručně, tak dojde k jeho vykonání (generuje .xml do složky). Pokud však nastavím CRON úlohu, tak se nic neděje.

    Podpora u Českého hostingu je tristní. Píší, že v logu mají, že dochází ke spuštění skriptu. Což nemůže být pravda, neboť kdyby ke spuštění skriptu došlo, tak bude ve složce vygenerované .xml. Pokud oni sami skript spustí, tak se taktéž provede standardně. Když má ale dojít ke spuštění přes CRON tak se nic neděje - xml se nevygeneruje, ale oni mi trvdí, že v logu vidí, že skript byl spuštěn.

    S prominutím už jsem z toho na palici. Skript přes CRON funguje u všech ostatních hostingových společností (wedos, active, one-bit atd.) zcela korektně jen prostě u Českého hostingu nic.

    Žádal jsem je o sdělení jestli mají nějaké nestandardní nastavení CRON serveru, ať mi jej sdělí. Prý nic. Nastavil jsem skriptu i maximální práva (CHMOD) a taktéž nic. Žádal jsem Český hosting aby vše prověřili a jediné, co vždy provedou, že spustí skript ručně. Poté ve složce vidím vygenerovaný xml s příslušným datumem a časem vytvoření. Když ale má dojít ke spuštění přes CRON, tak nic, ale dle nich vše funguje...

  2. Co se právě děje na Webtrhu?
  3. a co nějaké vlastní logy? Není problém s memory limitem, moduly, délkou běhu nebo právy na zápis toho xml?

  4. No to jsem vše vyloučil. Já když skript spustím přímo přes prohlížeč, zadáním URL, tak funguje. Když čekám na CRON, tak zkrátka nic. Myslel jsem tedy, že něco blbě nastavuji, ale dle sdělení českého hostingu je úloha nastavena správně. Oni v logu vidí, že úloha byla spuštěna. Nic víc mi k tomu nenapíšou. Žádám je o vysvětlení, ať mi tedy napíší rozdíl mezi spuštěním přímo přes prohlížeč a přes CRON. Memory limit je stejný, délka běhu taktéž, práva jsem dával maximální a nic.

    Přeci když spustím skript přes prohlíteč ručně a poté přes cron, tak se musí chovat stejně. Kdyby byl problém s délkou běhu, memory limitem atd. tak by to nemělo jít ani při ručním spuštění.

  5. zkus napsat script, který ti jen uloží nějaký záznam do databáze a nech ho projet CRONem. Pokud se neprovede, máš celkem vysokou jistotu, že CRON jim neběhá správně. Pokud ano, musíš jít dál vylučovací metodou. Nějak ořezávat script, než půjde, tím vyloučíš co zlobí.

  6. cron může mít jinou konfiguraci, být spuštěný pod jiným uživatelem či mít jiné omezení, může být i chyba v kódu. Do php souboru je možné přidat vlastní logování, vlastní odchytávání chyb a vlastní trasování atd.

  7. Citace Původně odeslal Steeta Zobrazit příspěvek
    zkus napsat script, který ti jen uloží nějaký záznam do databáze a nech ho projet CRONem. Pokud se neprovede, máš celkem vysokou jistotu, že CRON jim neběhá správně. Pokud ano, musíš jít dál vylučovací metodou. Nějak ořezávat script, než půjde, tím vyloučíš co zlobí.
    No to nepřipadá v úvahu. To je jednodušší změnit poskytovatele. Teď jak na to koukám, tak tam mám další crony, které se sice spustí a mají za úkol stáhnout .xml od dodavatelů a naimportovat do databáze ceny a stavy skladů. XML se stáhnou, ale zápis do databáze neproběhne.

  8. z moji zkušenosti je drtivá většina podobných problémů způsobena nevhodným nebo špatným kódem, třeba tam opravdu máš chybu. Hostingy se mohou chovat různě.

  9. Citace Původně odeslal TomášX Zobrazit příspěvek
    cron může mít jinou konfiguraci, být spuštěný pod jiným uživatelem či mít jiné omezení, může být i chyba v kódu. Do php souboru je možné přidat vlastní logování, vlastní odchytávání chyb a vlastní trasování atd.
    jj, to je o co je žádám. Psal jsem jim, pokud má cron jinou konfigurace nebo jiná omezení, tak ať mi je laskavě sdělí. Vše je prý stejné. Pokud by CRON skončil s chybou, měl by se uložit log do složky. Když se nic neuloží = žádná chyba tam není.

    Asi mi doopravdy nezbyde nic jiného, než prostě odkrokovat jednotlivé funkce ve skriptu, aby vždy vyhodily výpis.

    Každopádně se mi to dělat nechce. Platím si virtual managed server, abych měl vše bez starostí. Částka není nikterak malá. Tak snad by nemělo být mojí starostí, abych zjišťoval co za speciální konfiguraci mají u CRONu a měli by mi to sdělit rovnou.

    ---------- Příspěvek doplněn 06.03.2020 v 20:08 ----------

    Citace Původně odeslal TomášX Zobrazit příspěvek
    z moji zkušenosti je drtivá většina podobných problémů způsobena nevhodným nebo špatným kódem, třeba tam opravdu máš chybu. Hostingy se mohou chovat různě.
    Kdybych tam měl chybu, tak ji musí ten jejich systém vyhodit do logu do složky. Pokud tvrdí to co píší, že je konfigurace stejné, tak by se chyba musela projevit i při běžném běhu tj. přímém spuštění.

  10. Proc si neodchytit vsechny logy vcetne erroru do sveho souboru? Ja to mam treba udelane takto:

    5,10,15,20,25,30,35,40,45,50,55 * * * * /data/SAT/run17_MParallel.sh >> /data/SAT/run17_MParallel.log 2>&1

  11. management za mě je starost o server a služby, nikoliv o samotné aplikace. Správně bys měl mít i logy, které prokáží funkčnost, v praxi máme v systémech více logů než dat.

    Tenhle hosting neznám podrobně a teď mě nenapadá jiná rada.

  12. Skript se pustí, ale nevykona to co očekáváš. Zkontroluj si jak to máš udělané a nastavené! Nebo si objednej odborníka.

  13. Ja bych se rad podival. Nemuzes mi treba poslat ten php soubor? Nebo cely balik, pokud to neni jen one file.

  14. Citace Původně odeslal josef.jebavy Zobrazit příspěvek
    Skript se pustí, ale nevykona to co očekáváš. Zkontroluj si jak to máš udělané a nastavené! Nebo si objednej odborníka.
    Ne, skript se prostě neprovede přes CRON. Udělané a nastavené to je správně. Nevím kolikrát to mám psát jak zde, tak na podporu!!! Když to před týdnem fungovalo a nyní to nefunguje a na druhém serveru u jiného klienta taktéž u českého hostingu to také funguje, tak je chyba ve skriptu...

    ---------- Příspěvek doplněn 06.03.2020 v 22:17 ----------

    Citace Původně odeslal TomášX Zobrazit příspěvek
    management za mě je starost o server a služby, nikoliv o samotné aplikace. Správně bys měl mít i logy, které prokáží funkčnost, v praxi máme v systémech více logů než dat.

    Tenhle hosting neznám podrobně a teď mě nenapadá jiná rada.
    No právě... a když služby nefungují, tak mám asi dolovat důkazy, abych jim doložil, že to mají blbě nastavené? Jak jinak jim mám sdělit, že je chyba u nich než, že jim napíšu, že je problém jen při spuštění CRONu na tomhle serveru. Jinde to funguje zcela korektně - před týdnem to fungovalo korektně.

    ---------- Příspěvek doplněn 06.03.2020 v 22:22 ----------

    Citace Původně odeslal musil.david Zobrazit příspěvek
    Ja bych se rad podival. Nemuzes mi treba poslat ten php soubor? Nebo cely balik, pokud to neni jen one file.
    Je to modul pro generování feedů pro Prestashop - placený a aktualizovaný. Bohužel jej zaslat nemůžu, jak píši je placený. Už jsem si však do modulu přidal záchytné body a generování do vlastního logu. Uvidíme za půl hodiny, kdy by mělo dojít ke spuštění.

  15. Co přesně je v crontabu?

  16. Citace Původně odeslal Dolphi Zobrazit příspěvek
    Co přesně je v crontabu?
    3-59/30 * * * *

    Kdyby to bylo nastaveno špatně, tak by to jejich systém nevzal.

  17. To je nějak málo ne? Chybí co se má spustit, to je to podstatné

  18. Tak mám již výsledek. Chyba je doopravdy u nich.

    Skript se provede bez chyb, tak jak psala podpora. Výsledné .xml se však má uložit do složky nazevdomeny/xml, to tam však není. Když jsem skript změnil a zadal uložení do stejné složky tj. ze které je spouštěn skript, tak se .xml uloží. Zkusil jsem tedy zadat zpracování přes adresářový CRON, což je další možnost, kterou nabízejí. Zde se skript taktéž vykoná a končeně se .xml uloží i do správné složky tj. nazevdomeny/xml.

    Zjistil jsem tedy, že pokud se zadá CRON přes jejich webové rozhraní, tak se výsledné .xml neuloží do složky do které chci, ale do složky o 2 úrovně výše tj. do složky, do které nemám přístup.

    ---------- Příspěvek doplněn 06.03.2020 v 23:22 ----------

    Citace Původně odeslal Dolphi Zobrazit příspěvek
    To je nějak málo ne? Chybí co se má spustit, to je to podstatné
    No málo to je. Nic jiného se u nich nenastavuje. Jen čas spuštění a URL. Vše se zadává přes jejich administrační rozhraní. Problém jsem však již vyřešil a oznámil na podporu.

  19. cron-job.org - Free cronjobs - from minutely to once a year.

    ---------- Příspěvek doplněn 07.03.2020 v 00:55 ----------

    Skus pouzit, vyuzivam uz dlho a funguje na sto pro.

  20. Tak jasně, to je prostě Managed. Nějaké limity tam být musí aby si kdejaký script nezapisoval cokoliv kamkoliv chce. Proto je možná jen jejich jedna definovaná cesta přes webové rozhraní, kterou mají nejspíše nějak ošetřenou. Kdyby člověk mohl cokoliv, tak pak už to není managed.

    Jinak Český Hosting patří u nás nejlepším, je bych určitě nektritizoval

  21. Citace Původně odeslal Mirek Novotny Zobrazit příspěvek
    Tak jasně, to je prostě Managed. Nějaké limity tam být musí aby si kdejaký script nezapisoval cokoliv kamkoliv chce. Proto je možná jen jejich jedna definovaná cesta přes webové rozhraní, kterou mají nejspíše nějak ošetřenou. Kdyby člověk mohl cokoliv, tak pak už to není managed.

    Jinak Český Hosting patří u nás nejlepším, je bych určitě nektritizoval
    Ale to není pravda, že je to prostě Managed a je to nějaké jeho specifikum. Ano limity tam být musí, ale tohle je pravý opak... Naopak byl povolen zápis a to špatným nastavením, že se zapisovalo a dokonce šlo vytvořit novou složku do úrovní před doménou tj. tam kam bych nikdy neměl mít přístup. Zároveň, když jsem vše porovnál a hledal, zda nemám dalšího klienta u českého hostingu, tak jsem zjistil, že mám, a u něj vše funguje normálně. Nekritizuji, že to bylo špatně nastavené, to se stane, kritizuji přístup podpory, kdy bez jakéhokoliv zkoumání napíšou, že je chyba na mé straně ve skriptu i když žádná chyba v logu není. Skript sami po mé urgenci spustí ručně a vidí, že vše probíhá bez chyb a přesto opět napíší, že je chyba ve skriptu. Když žádám o vysvětlení, proč stejný skript u jednoho klienta na serveru funguje a u druhého na jiném serveru nefunguje i když tam před týdnem ještě fungoval a oba dva servery mají stejnou konfiguraci, nedokáží odpovědět jinak, než že je chyba ve skriptu... Nakonec jim člověk sdělí, kde je chyba, oni se nenamáhají na otevřený ticket ani odpověď a poděkovat, ale chybu si opraví...

  22. Citace Původně odeslal Mirek Novotny Zobrazit příspěvek
    Tak jasně, to je prostě Managed. Nějaké limity tam být musí...
    "Managed VPS" znamená, že má člověk pronajatý server (je jedno že virtuální) a k tomu si kupuje správu tohoto serveru. Správa serveru = administrátor, který jej spravuje a nastaví a udělá vše podle toho, co aplikace potřebuje v nějakém rozumném časovém fondu. Na tom se asi shodneme. Limity aby skript nezapisoval kam chce tam být nemusí, protože máte pronajatý celý server (byť ne fyzický), takže nevadí, že může skript zapisovat do úrovně nad doménou, byť se tím dá nadělat zřejmě víc škody než užitku.

    Člověk by řekl, že je to jasné, ale není. Český hosting nenabízí Managed VPS, nabízí klasický webhosting, kterému říkají "managed vps". Je to jen marketingové označení.

    Běžně se stane, že po komunikaci s podporou Českého hostingu vám napíšou, že něco nenainstalují nebo nenastaví, nebo naopak, mají limity odpovídající jejich běžnému zákazníkovi a neupraví vám je. Podobně absurdní je třeba zpoplatněný provoz vlastního SSL certifikátu cenou 200 Kč/rok ... "managed vps" by měl být server + administrátor a mělo by jim být kulové do toho jaké certifikáty používáte nebo co vám tam běží.

    Na druhou stranu chápu, že nedává smysl kontrolovat každou nahlášenou chybu a řádek po řádku ve skriptu, zkoumat co má skript dělat a zda má nastavenou relativní či absolutní cestu ... to je opravdu zodpovědnost vývojáře.

  23. Nestahuje se to XMLko náhodou jiným scriptem, který má jinak nastavená práva. Nastav si tam přes FTP práva k tomu php souboru spouštěného CRONem na 700.

  24. Citace Původně odeslal Martin Kejzlar Zobrazit příspěvek
    Nestahuje se to XMLko náhodou jiným scriptem, který má jinak nastavená práva. Nastav si tam přes FTP práva k tomu php souboru spouštěného CRONem na 700.
    Jaj, už jsem psal, že chyba byla na straně poskytovatele... Práva byla první, která jsem upravil a to na 770 pro testování. Problém byl ve výpisu cesty. Český hosting nespouští CRONy na stejném serveru tj. webserveru, ale simuluje spouštění na jiném serveru a zde bylo chybné nastavení cesty tzn. simulové spouštění bylo nastavené špatně a to jen na tomto serveru. Jakmile jsem to zjistil, tak jsem zajistil spouštění skriptu nikoliv přes jejich web administraci, ale přes adresářový CRON, kde jsem spustil skript přes file_get_contents tj. jako kdyby to běželo na webserveru. Poskytovatel si následně chybu u sebe opravil a nyní to běží i přes simulaci ve webovém rozhraní.

Spolupracujeme: Jooble.org, Aximum - profesionální překlady Hostujeme u Server powered by TELE3