A jelenlegi drupal adatbazisomon nem fut le a drupal cron job. A futas helyett feldob egy letoltes ablakot a "run-cron.txt" filera. Itt mindegy, hogy mit csinalok (open, save, ...) a cron job nem fut le.
Kiprobaltam egy "ures" adatbazison egy azonos drupal verziot, illetve a hibas adatbazison tobb drupal verziot is a jelenseg ugyanaz.
Megprobaltam a drupal admin felulet alol a cachet torolni, egyelore nem segitett.
Turtam a netet, hogy milyen cache tablak vannak meg, azokat toroltem phpmyadminbol, de az sem segitett.
Tud valaki megoldast?
- 6322 megtekintés
Hozzászólások
Azt nem wgettel kene leszedni cronbol?
Vagy mi a fenet keres egy cron job egy bongeszoben?
- A hozzászóláshoz be kell jelentkezni
Elindithatod a bongeszobol kezzel is. Normal esteben a hosting crontabjaba teszed be wgettel.
De mondjuk ez nem valtoztat azon, hogy nem fut le.
- A hozzászóláshoz be kell jelentkezni
Hanyas verziójú drupal? Mert pl. a 7-es már automatikusan bizonyos idő után egy-egy kérésbe beszúrja a cron futtatást.
- A hozzászóláshoz be kell jelentkezni
Az mindegy, hogy automatikus vagy manualis, ah nem fut le. Probaltam 6-ossal es 7-essel is. Ez feltehetoleg egy adatbazis problema.
- A hozzászóláshoz be kell jelentkezni
Abban a könyvtárban, ahol a cron job van, van futtatási jog? A file-ra van engedélyezve a futtatás? Kinek a nevében futtatnád a cron-t?
- A hozzászóláshoz be kell jelentkezni
A helyzet az, hogy ha csinalok egy vadonatuj installaciot egy szuz adatbazist, akkor minden megy ragyogoan. Ha beimportalom a regi adatbazist ugyanebbe az installacioba, akkor a cron nem fut le tobbe. A filerendszerben nincs valtozas. Tehat nem valoszinu, hogy jogosultsagi problema. Egyekent ha az lenne, akkor permission denied jellegu hibauzenet erkezne.
"Abban a könyvtárban, ahol a cron job van, van futtatási jog?"
Igen
"A file-ra van engedélyezve a futtatás?"
Nem volt, de nem valtoztat a dolgon. Ahol mukodik, ott mukodik anelkul is, ahol nem mukodik, ott nem megy azzal sem.
"Kinek a nevében futtatnád a cron-t?"
A host felhasznalom neveben, feltehetoleg.
- A hozzászóláshoz be kell jelentkezni
Esetleg probald meg drush-on keresztul futtatni. Az a tool egyebkent masra is hasznos, erdemes megnezni. :)
- A hozzászóláshoz be kell jelentkezni
Eloszor le kene fusson manualis modban.
- A hozzászóláshoz be kell jelentkezni
A nyito postbol nem derult ki egyertelmuen, hogy manualisan sem fut le. Esetleg error log?
- A hozzászóláshoz be kell jelentkezni
Bocs, tenyleg nem volt egyertelmu.
- A hozzászóláshoz be kell jelentkezni
Adatbázisban töröld a cron_semaphore-t. Ez szokott segíteni beragadt cron feladatoknál.
delete from variable where name = 'cron_semaphore';
- A hozzászóláshoz be kell jelentkezni
cron_semaphore nem volt egyik serult adatbazis variable tablajaban sem (sem a 6-sban, se a 7-eseb importaltabn), viszont a 7-es altal ltrehozott szuz adatbazisban a variable tablaban van egy cron_key meg egy cron_last, de cron_semaphore ott sincs. Gondolom ez egy atmenetileg letrehozott valtozo a cron futas idejere.
- A hozzászóláshoz be kell jelentkezni
Felrakod az XDebug-ot, beraksz a cron-fajl elejere egy trace requestet, leszeded wgettel, elolvasod a trace fajlt, orulsz (vagy sirsz...)
- A hozzászóláshoz be kell jelentkezni
A shared hostingra hogy rakom fel?
- A hozzászóláshoz be kell jelentkezni
A problemat egy php oldal okozza (ide kikommentezve teszem be):
<?php
/*
$file = $_GET['file'];
$filePathName = $_SERVER['DOCUMENT_ROOT'] . $_GET['path'] . $file;
$mime = $_GET['mime'];
header ("Content-type: $mime");
header ("Content-disposition: attachment; filename=".$file.";");
header("Content-Length: ".filesize($filePathName));
readfile($filePathName);
exit;
*/
?>
Ezt nem tudja felindexelni.
Ezt a kodreszletet arra talaltam korabban megoldaskent, hogy kikenyszeritsem a bongeszobol letolteskor a mentes/megnyitas abalakot. Ugyanis ha barmilyen allomanyt tolt le a felhasznalo, akkor az minden bongeszonel mashogy tud vislekedni pl. attol fuggoen, hogy van e beagyazodo applikacio az adott tartalomhoz, stb.
Ha az allomany nagyobb, a felhasznalo gyakran elkattint, mert azt hiszi, hogy nem tortenik semmi, mikozben a browser csendebn a hatterben tolt.
Szoval vagy a cron temat tekintem megoldottnak, de akkor a bongeszoablak megnyitas nem mukodik es akkor nyithatok egy uj temat a bongeszoablak probelamanak, vagy pedig sikerul olyan php kodot irni, amit fel tud indexelni a cron.
Oteltek?
- A hozzászóláshoz be kell jelentkezni
Az indexelesi problemat egesz pontosan az exit utasitas okozza. Viszont ha ez hianyzik, a letoltes sem mukdik.
- A hozzászóláshoz be kell jelentkezni
Mi akadályozza, h ezzel le lehessen tölteni pl. a db user/pass -t ?
- A hozzászóláshoz be kell jelentkezni
Ez egy nagyon jo kerdes, ill. meg az is szep kerdes, hogy es ennek mi a fasszeh' kell futnia a cronban is?
- A hozzászóláshoz be kell jelentkezni
Azert mert a drupal minden php oldalt ertelmez amikor felindexeli. Tehat nem aphp kodot indexeli, hanem lefuttatja szkriptet es az eredmenyet indexeli. Sajnos nem lehet meg a 7-es drupalnak sem kivetleket megadni.
- A hozzászóláshoz be kell jelentkezni
Valaki legyen oly' kedves elmagyarazni, hogy az elso mondatnak mi a jelentese. Tudtommal a Drupal nem PHP oldalakat indexel, hanem a sajat adatbazisaban gyujtoget. De lehet, hogy tevedek, viszont erdekelne, hogy ez akkor hogy mukodik.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Nem tuidom, hogy mennyire fogalmaztam pontosan. A lenyeg, hogy amikor a drupalban oldalt hozol letre, akkor az egyik lehetseges tipus a php (a htaml es szukitett html mellett). A mondat pedig azt jelenti, hogy a php tartalmu oldalak eseteben nem a php kod kerul szovegkent felindexelesre, hanem a kod altal generalt html oldal.
- A hozzászóláshoz be kell jelentkezni
Ha ilyen igényed van, miért nem modult fejlesztesz? Megerőszakolod a rendszert és csodálkozol, ha hibásan működik.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Nem eroszakolom meg a rendszert. Hasznalom az altala nyujtott szolgaltatasokat. Hogy ez jo vagy rossz az mas kerdes.
- A hozzászóláshoz be kell jelentkezni
A PHP filtert minden jo erzesu ember nagyon-nagyon-nagyon messzirol keruli, es modulszinten kapcsolja ki. Csak nagyon-nagyon ellenorzott korulmenyek kozott szabad hasznalni - es akkor is nyolcvanotszor meg kell fontolni, hogy tenyleg kell-e ez, nem lenne-e jobb modult gyartani ra.
Roviden: A PHP filter rossz, ertem?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ezek szerint nem vagyok jo erzesu ember. En egy szimpla weboldalt akarok osszerakni drupallal, es abban ket helyen is kell egy par sornyi php kod. (Ja PHP kod azert kell, mert az egesz webes technologia egy rakas ..., raadasul minden bongeszo mashogy viselkedik,) Ehhez irjak modult? Miben jobb a modul, mintha a php filteren megy at? Azzal, hogy a php kod nem az adatbazisban lakik? Hat miert nem oldjak meg rendszer szinten, hogy ne ott lakjon. Egyelore nem latom, hogy miert nem (keret)rendszer szinten van a php problema kezelve, miert is kell nehany sor php kodhoz modult gyartani, es azt allandoan karbantartani, az upgradekkel elvezni, stb.
- A hozzászóláshoz be kell jelentkezni
Ha elmondod, miert kell a PHP kod, es nem csak felhaborodottan vagdalkozol, akkor lehet, hogy meg segiteni is tudunk.
A PHP filter egyebkent azert nem jo dolog, mert nagyon sokmindenre kihatassal lehet. Egy modul sokkal specifikusabb, sokkal finomabb eszkoz, mint egy node-ba/blockba beszurt PHP kod. Kicsit a kobalta meg a precizios furo esete, mindkettovel celt lehet erni, csak az elobbivel tobb kart csinalsz kozben.
A custom modulokat nem kell upgradelni. A Drupal API csak foverzionkent valtozik nagyot, de akkor amugy is olyan melyrehato valtozasok vannak, hogy az, hogy egy egyfuggvenyes modult frissiteni kell, eltorpul amellett, amennyi munka egyebkent van vele. De egy foverzion belul az API-k 99%-a egyaltalan nem valtozik (legfeljebb bovul).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Azt még tegyük hozzá, hogy egy ilyen node-ba írt PHP gányolással sok dolgot nem lehet kihasználni a Drupal funkciói közül. Illetve ha valami miatt hiba kerül bele (pl. PHP frissítés, elírt függvénynév), akkor törik az egész oldal és lehet az adatbázisban pucolgatni.
A PHP filter nem azért van, hogy ott programozzunk, ez igenis megerőszakolása a rendszernek. Na de majd mindjárt jön a témaindító és megmagyarázza, hogy ő márpedig ért a Drupalhoz és így kell ezt.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Nem vagdalkozom, csak a kerdesfelvetesemre vicces modon lecseszesek jonnek. Nekem a webprogramozas nem szakteruletem, ezert probalok egy kesz keretrendszert alkalmazni, hogy az eletem egyszerubb legyen. Az akkor miert csinalod kerdeseket megelozendo: egy non-profit oldalrol van szo, amit ingyen szeretetbol (es rohadt keves idobol) csinalok, es nincs mas, aki csinalna.
Szoval a PHP reszek:
Az egyik problema ez: http://hup.hu/node/114266#comment-1455895
A masik, amire php-t hasznalok az egy tablazat generalasa.
Es talan van meg egy, ahol egy automatikus mailt kuldok.
- A hozzászóláshoz be kell jelentkezni
Na most ez jo kerdes. Mondjkuk az, hogy tudni kene, hogy ezt az oldalt hogy hivjak, a db-t hogy hivjak stb.
De ha tudsz jobbat annak orulnek.
- A hozzászóláshoz be kell jelentkezni
az inputok ellenőrzése nem "jobbat tudás", hanem az abszolút minimum.
$file = $_GET['file'] ennek mi értelme van - azon kívül h szaporítod a változókat?
- A hozzászóláshoz be kell jelentkezni
"az inputok ellenőrzése nem "jobbat tudás", hanem az abszolút minimum."
Igen lehetne, nem igazan gondoltam ra. (Nem foglalkozom alapvetoleg webes programozassal, csak kenyszerbol naha, es nem gondoltam ra, hogy ez egy tamadasi felulet.) Az inputok ellenorzese egyebkent szerintem tervezesi es nem kodolasi kerdes, ez pedig egy "quick and dirty" dolog, ahol mukodes szempontjabol minden input elfogadhato. De ertem a problemat es koszonom, hogy felhivtad ra a figyelmem. A tudsz jobbat pedig a megoldasra ertettem, de tenylegesen egy input szuressel valoszinuleg az is megoldhato, hogy a cron lefusson. Majd este megnezem.
"$file = $_GET['file'] ennek mi értelme van - azon kívül h szaporítod a változókat?"
Ket helyen van hsznalva, de mondjuk tenyleg nem letszukseg, hogy valtozoban legyen. En egyebkent inkabb hasznalok valtozokat, mint tobbszoros vagy egymasba agyazott hivasokat. De nem vagyok a PHP nagy muveloje, csak muszajbol hasznalom neha neha, tehat nem feltelenul hasznalom optimalisan.
- A hozzászóláshoz be kell jelentkezni
Ha már dirty hack, akkor adj meg spéci user agentet a cron-os wget -nél, és ebben a fájlban PHP-val csekkold, h mi a user agent! Vagy már rewrite-tal elküldheted a bánatba és akkor nem kell a PHP-ban koszolni!
- A hozzászóláshoz be kell jelentkezni
Eloszor is, ez a PHP kod hogyan fut? Valahogy mindenki nagyon okosnak latszik itten, pedig te nem irtal le semmi konkretumot. En meg valahogy hulyenek erzem magam, pedig nagyon szivesen segitenek.
Egyfelol a Drupal kepes a letoltesek kezelesere, PHP-n atszurve a dolgokat, a 'drupal private filesystem' kulcsszavakra keress ra (aposztrofok nelkul). Sztem erre a mokolasra szukseg nincsen.
Masfelol pedig sztem a webszerveren is ki lehetne eroszakolni egy ilyen header elkuldeset adott fajlok eseteben. De meg az sem lehetetlen, hogy van ilyen Drupal modul, csak te meg nem tudsz rola.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
> Egyfelol a Drupal kepes a letoltesek kezelesere
Fent leirtam a kulonbozo bongeszokkel tapasztalt jelensegeket.
> drupal private filesystem
Ez hogyan tudna segiteni a probleman?
> Masfelol pedig sztem a webszerveren is ki lehetne eroszakolni egy ilyen header elkuldeset adott fajlok eseteben.
Hogyan?
> De meg az sem lehetetlen, hogy van ilyen Drupal modul, csak te meg nem tudsz rola.
A forumokat bongeszve mas sem. Ettol meg lehet, hogy letezik.
- A hozzászóláshoz be kell jelentkezni
Valójában mi lenne a feladat és mivel próbálkoztál eddig?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
A feladat az, hogy bizonyos allomanyok letolthetoek legyenek egy html oldalba agyazott linkre kattintva. Korabban ezt egyszeruen ugy oldottam meg, hogy a drupal belso relativ linkjet tettem be az anchor tagbe. (pl. /files/vmi/vmi2/vmi3.pdf) Ennek az volt az eredmenye, hogy a bongeszok kulonfelekeppen kezeltek a letoltest. Van amelyik nyitott abalakot, van amelyik a hatterben toltott. Ez nyilvan egy nehany MBs allomanynal mar probelmas lehet, mert egy csomo user elkattint, hogy hat ez nem is mukodik, nem tortenik semmi. Ennek kikuszobolesere akarom kikenyszeriteni, hogy a letoltes ablak mindig azonnal megyniljon, amint a user a linkre kattint.
- A hozzászóláshoz be kell jelentkezni
A topic cim pont megfelel, bar a problemam kicsit eltero. D7 alatt a cron jobok nem futnak le, ha kivulrol probalom futtatni curl-lal, csak ha drush-sal futtatom oket. Bar a D7 alapbol tartalmaz egy poorman's cron implementaciot, azert en megis jobban orulnek, ha ez a mod mukodne.
Sikerult mar vkinek mukodesre birnia? A cron_key-t meg szoktam adni, ezzel egyutt sem megy, es nem tudom, milyen jog kellene hozza.
A hibajelenseg: egy teljesen renderelt (sminkelt) drupal-os "Hozzaferes megtagadva" oldalt kapok.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni