VNC stopt er mee :(
opslag locatie ineens Saving to: “/dev/null”
Ik gebruik het onderstaande script al een hele tijd om bestanden naar mijn server te downloaden:
Quote:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$ch = curl_init();
$source = "http://www.url.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock";
curl_setopt($ch, CURLOPT_URL, $source);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec ($ch);
curl_close ($ch);
$destination = "/home/map/domains/domain.com/public_html/pub/media/importexport/leverancier-voorraad.xml";
$file = fopen($destination, "w+");
fputs($file, $data);
fclose($file);
?>
$ch = curl_init();
$source = "http://www.url.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock";
curl_setopt($ch, CURLOPT_URL, $source);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec ($ch);
curl_close ($ch);
$destination = "/home/map/domains/domain.com/public_html/pub/media/importexport/leverancier-voorraad.xml";
$file = fopen($destination, "w+");
fputs($file, $data);
fclose($file);
?>
Het bestand leverancier-voorraad.xml werd altijd keurig aangemaakt en kan van daaraf met andere cron verwerkt worden.
Nu merkte ik echter dat de voorraad niet goed bijgewerkt werd de afgelopen tijd. dat ik ging kijken bleek dat de laatste versie van leverancier-voorraad.xml 2 weken oud was.
Dus even de rapportage van cron aangezet en krijg ineens de volgende rapportage bij uitvoeren van bovenstaande script:
Quote:
--2018-06-21 06:29:01-- http://www.domain.com/pub/media/importexport/leverancier-voorraad.php
Resolving www.domain.com... ip Connecting to www.domain.com|ip|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 537 [application/x-httpd-lsphp]
Saving to: “/dev/null”
0K 100% 67.4M=0s
2018-06-21 06:29:01 (67.4 MB/s) - “/dev/null” saved [537/537]
Resolving www.domain.com... ip Connecting to www.domain.com|ip|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 537 [application/x-httpd-lsphp]
Saving to: “/dev/null”
0K 100% 67.4M=0s
2018-06-21 06:29:01 (67.4 MB/s) - “/dev/null” saved [537/537]
Cronjob wordt dus goed uitgevoerd, bestand wordt gedownload maar hij slaat het ineens op naar Saving to: “/dev/null”
Volgens mij staat er toch echt een andere opslag locatie in het bestand opgegeven.
Iemand voor deze leek enig idee waarom hij ineens niet meer naar opgegeven locatie opslaat maar naar “/dev/null”
Toevoeging op 21/06/2018 07:28:49:
Ik heb hetzelfde script nog even op andere domeinnaam getest en dan wordt bestand gewoon opgeslagen op de daar opgegeven locatie.
Locatie waar opgeslagen moet worden bestaat ook gewoon (staat ook nog het oude eerder via script gedownloade bestand). en rechten van de map waarbinnen opgeslagen moet worden staat op 0755
Kijk eens normaal met wget als je het daar op wilt slaan.
Gewijzigd op 21/06/2018 08:46:29 door - Ariën -
Toevoeging op 21/06/2018 10:16:27:
die komen er helaas ook nog niet uit.
Cron opdracht die ik gebruik ziet er overigens als volgt uit:
/usr/bin/wget -O /dev/null "http://www.domeinnaam1.com/feeds/merk-voorraad.php"
Op domeinnaam 1 werkt deze dus niet goed, op domeinnaam 2 wel.
Quote:
-O, --output-document=FILE write documents to FILE.
Als je -O /dev/null gebruikt, wat denk je dat er dan gebeurt?
Quote:
/usr/bin/wget -O /dev/null
En dan vind je het gek dat alles in /dev/null wordt opgeslagen? :-)
(om een half-open deur nog iets verder open te trappen: -O is de korte variant van --output-document)
Quote:
Cronjob wordt dus goed uitgevoerd, bestand wordt gedownload maar hij slaat het ineens op naar Saving to: “/dev/null”
Volgens mij staat er toch echt een andere opslag locatie in het bestand opgegeven.
Volgens mij staat er toch echt een andere opslag locatie in het bestand opgegeven.
Je zit helemaal verkeerd te denken.
wget roept de opgegeven url aan en schrijft de output (dus datgene wat je in je browser ziet) naar /dev/null. Wat er in /dev/null terechtkomt, is dus niet de voorraad.xml, maar alle uitvoer van je php-script. Misschien zit daar ook wel een foutmelding in die je nu over het hoofd ziet.
Je zegt in je openingspost dat de rechten van de directory goed zijn en dat het eerder gedownloade bestand daar nog staat. Hoe zit het met de rechten van dat bestand? Kan het zijn dat die (ineens) zo staan dan de fopen() daardoor het bestand niet meer kan openen? Wat gebeurt er als je het bestand hernoemt of weggooit?
(edit)
Terzijde: als je wget gebruikt in cronjobs, kun je het beste ook de parameter -q meegeven. Hij geeft dan geen output naar het scherm (afgezien van eventuele foutmeldingen), zodat je de cron-rapportage niet hoeft te onderdrukken (wat tot gevolg heeft dat je de foutmeldingen mist).
Gewijzigd op 21/06/2018 12:19:16 door Willem vp
Maar met /usr/bin/wget -O /dev/null "http://www.domeinnaam1.com/feeds/merk-voorraad.php" heb ik heel lang dus egwoon dat script uitgevoerd en werd het bestand dat in het script aangegeven stond keurig opgeslagen op de locatie zoals in het bestand staat aangegeven. Maar vannaf datum x werkt dat dus ineens niet meer voor domeinnaam 1.
Op domeinnaam 2 draait exact dezelfde opdracht voor exact hetzelfde script (enkel de opslag locatie is anders. en voor domeinnaam 2 werkt het nog wel.
Maar zou dus /usr/bin/wget "http://www.domeinnaam1.com/feeds/merk-voorraad.php" moeten gebruiken (de locatie waar de file die in "merk-voorraad.php genoemd wordt die hij moet downloaden staat ook in het bestand "merk-voorraad.php"
Toevoeging op 21/06/2018 12:21:44:
waarom werkt dus op ene domeinnaam het deel $destination = "/home/map/domains/domain.com/public_html/pub/media/importexport/leverancier-voorraad.xml"; uit het script wel en op andere domeinnaam niet meer?
Daniel Feenstra op 21/06/2018 12:20:27:
Maar zou dus /usr/bin/wget "http://www.domeinnaam1.com/feeds/merk-voorraad.php" moeten gebruiken (de locatie waar de file die in "merk-voorraad.php genoemd wordt die hij moet downloaden staat ook in het bestand "merk-voorraad.php"
Nee. Dat heeft namelijk tot gevolg dat je óf een foutmelding van wget krijgt dat hij de output niet kan wegschrijven omdat hij geen rechten heeft, óf dat er ergens op het systeem een bestand merk-voorraad.php komt te staan met daarin de uitvoer van het script.
De fout zit ergens anders, we moeten alleen nog een zien te achterhalen waar. Staat er nog iets nuttigs in de errorlog van PHP/webserver?
/usr/bin/wget "http://www.domeinnaam.com/feeds/merk-voorraad.php"
die roept dus het bestand merk-voorraad.php aan.
Hierin staat het volgende:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$ch = curl_init();
$source = "http://www.website-voor-downloaden.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock";
curl_setopt($ch, CURLOPT_URL, $source);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec ($ch);
curl_close ($ch);
$destination = "/home/map/domains/domeinnaam-voor-opslaan.com/public_html/pub/media/importexport/files/merk-voorraad.xml";
$file = fopen($destination, "w+");
fputs($file, $data);
fclose($file);
?>
$ch = curl_init();
$source = "http://www.website-voor-downloaden.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock";
curl_setopt($ch, CURLOPT_URL, $source);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec ($ch);
curl_close ($ch);
$destination = "/home/map/domains/domeinnaam-voor-opslaan.com/public_html/pub/media/importexport/files/merk-voorraad.xml";
$file = fopen($destination, "w+");
fputs($file, $data);
fclose($file);
?>
Hij moet nu dus http://www.website-voor-downloaden.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stoc gaan downloaden en dat bestand opslaan als/op home/map/domains/domeinnaam-voor-opslaan.com/public_html/pub/media/importexport/files/merk-voorraad.xml
Als resultaat van cron krijg ik het volgende nu:
--2018-06-21 12:24:01-- http://www.domein-voor-opslaan.com/feeds/shots-voorraad.php
Resolving www.domeinnaam.com... 185.104.28.87 Connecting to www.domeinnaam.com|185.104.28.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
Saving to: “merk-voorraad.php.1”
0K 0.00 =0s
2018-06-21 12:24:06 (0.00 B/s) - “merk-voorraad.php.1” saved [0/0]
maar op home/map/domains/domeinnaam-voor-opslaan.com/public_html/pub/media/importexport/files/merk-voorraad.xml is niks opgeslagen
Toevoeging op 21/06/2018 12:32:37:
Ben van Velzen op 21/06/2018 12:29:09:
Nu zie ik wat je doet, je roept in cron een PHP script aan die dan daadwerkelijk de cron uitvoert. Waarom die indirectie? Nu zit je dus naar zaken te kijken (die /dev/null) die niet relevant zijn. Roep het cron script eens rechtstreeks aan in de browser en kijk wat er aan foutmeldingen komt. En kijk ook eens in je error logs.
Ik roep met een cron een php script aan. in dat php script staat dus welke bestand vanaf welke domeinnaam hij moet downloaden en naar welke domeinnaam en map en onder welke naam hij die moet opslaan.
Dat gebeurd ook zo omdat voor bepaalde leveranciers er in dat php script ook een stukje code staat die gebruikt wordt om bij die leverancier in te loggen (die productfeeds staan achter een wachtwoord).
Toevoeging op 21/06/2018 12:33:28:
errorlog van webserver is helemaal leeg
[Thu Jun 21 09:59:06.827204 2018] [lsapi:notice] [pid 739201:tid 140574151567104] [client 185.104.28.87:42324] [host www.domein.com] Backend log: PHP Warning: fopen(/home/map/domains/domein.com/public_html/pub/media/importexport/files/merk-voorraad.xml): failed to open stream: No such file or directory in /home/map/domains/domein.com/public_html/feeds/merk-voorraad.php on line 11\n
en
[Thu Jun 21 09:59:06.827257 2018] [lsapi:notice] [pid 739201:tid 140574151567104] [client 185.104.28.87:42324] [host www.domein.com] Backend log: PHP Warning: fputs() expects parameter 1 to be resource, boolean given in /home/map/domains/domein.com/public_html/feeds/merk-voorraad.php on line 12\n
Toevoeging op 21/06/2018 12:38:03:
Willem vp op 21/06/2018 12:34:31:
Wat krijg je te zien als je "http://www.domeinnaam.com/feeds/merk-voorraad.php" in je browser aanroept? Wellicht staat daar nog iets van een foutmelding, maar normaal gesproken krijg je die nooit te zien omdat die naar /dev/null wordt gestuurd.
dan krijg ik een blanco pagina
Quote:
Dat gebeurd ook zo omdat voor bepaalde leveranciers er in dat php script ook een stukje code staat die gebruikt wordt om bij die leverancier in te loggen (die productfeeds staan achter een wachtwoord).
Dat kun je toch ook via wget regelen?
Code (php)
1
wget -q --http-user=USER --http-password=PASSWORD -O /home/map/domains/domeinnaam-voor-opslaan.com/public_html/pub/media/importexport/files/merk-voorraad.xml "http://www.website-voor-downloaden.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock"
en dan heb je dat hele php-script niet eens nodig. ;-)
Gewijzigd op 21/06/2018 12:41:22 door Willem vp
dat klinkt stuk makkelijker.
Ik doe al jaar of 5 dat met die scripts en werkte altijd prima tot dus een week of 2 terug op deze domeinnaam. en op andere domeinnaam werkt het dus nog steeds.
maar ga het eens testen zo rechtstreeks
Toevoeging op 21/06/2018 12:58:37:
Het werkt zo te zien :-)
Bestand is gedownload en op de juiste locatie opgeslagen.
Alleen krijg ik nu geen e-mail meer van cron systeem met of goedgegaan is of niet.
Komt dat door die -q toevallig?
Ik heb het stukje --http-user=USER --http-password=PASSWORD er nu tussenuit gehaald omdat voor deze site dat niet nodig is.
Waarom het ineens op het ene domein mis is gegaan: geen idee. Kan aan een heleboel (ook ogenschijnlijk ongerelateerde) dingen liggen. Het is moeilijk om daar op afstand iets over te zeggen.
Gewijzigd op 21/06/2018 13:08:58 door Willem vp
Lijkt iets overigens toch nog niet helemaal goed te gaan.
Bestand is gedownload en opgeslagen.
Volgende stap is dat dat gedownloade bestand geimporteerd wordt (ook dat start weer via cronjob normaal).
Nu even handmatig gestart via ssh maar hij gaat niet lopen.
Komt niet verder dan:
Entity catalog_product
Begin data validation
Checked column 0
Checked column 1
Finish checking columns
Errors count: 0
Start saving bunches
en dan hoort dus de hele lijst met regels uit gedownload bestand te volgen.
Dus nu zoeken waarom dat nu niet goed gaat.
/pub/media/importexport/merk-voorraad.xml
naar
/pub/media/importexport/files/merk-voorraad.xml
Toevoeging op 21/06/2018 13:35:26:
locatie nu ook weer teruggezet maar blijft dus hangen. controleert de 2 kolommen in het bestand zen zegt dat goed is. daarna moet hij de regels gaan verwerken maar daar start hij niet mee.
Bestand is ook als UTF-8 opgeslagen dus dat is ook goed.
Toevoeging op 21/06/2018 14:37:40:
Blijkt dat hij het wel doet maar nu ineens heel lang nodig heeft om te starten. normaal starte het binnen 1 seconde met verwerken, nu duurt 5 tot 15 minuten. dat nu bij ontwikkelaar van import extensie neergelegd
Thomas van den Heuvel op 21/06/2018 19:19:33:
Wellicht ben je inmiddels van deze constructie afgestapt, maar scripts die op gezette tijden uitgevoerd dienen te worden (via cron) zouden bij voorkeur eigenlijk nooit in de publieke webdirectory mogen staan.
heb nu nog maar paar crons overgezet naar de nieuwe manier van verwerken zonder php file. rest moet nog.
Heb bestanden in die mappen gezet omdat dat is van waaruit de import systemen ze weer verwerken.
Kan waarschijnlijk beter, maar zijn nog paar honderd zaken die in mijn webshop beter kunnen. Maar nu eerst draaiende krijgen en geld verdienen, daarna een nog betere en beter doordachte shop bouwen;-)