Bash script om python programma te laden werkt niet

[Brilsmurfffje]

Ik ben probeer een Raspberry PI een python script te laten starten zodra het apparaat opstart, helaas krijg ik het voor geen meter aan de praat.

Ik heb een Python bestand:

code:

print "Hello World!"

Ik heb een .sh bestand:

code:

#! /bin/sh

echo "launching Python script!"

python /home/pi/Desktop/test.py

Dit .sh bestand heb ik opgeslagen als test.sh op de volgende locatie:
/etc/init/d
Vervolgens heb ik dit bestand uitvoerbaar gemaakt:
sudo chmod +x test.sh

Hierna heb ik het volgende commando gedraaid om test.sh toe te voegen aan de boot sequence:
sudo update-rc.d test.sh defaults

Een reboot van het systeem en nog steeds geen hello world in beeld, iemand een idee wat hier is misgegaan?

Ik heb het ook al via cron geprobeerd, helaas ook zonder soelaas.

[Sleepkever]

Kijk eens in je logging. Grote kans dat het daar ergens staat. Zou je ook even kunnen vermelden wat je uiteindelijk doel is hiermee? Dat maakt de richting die je uit gestuurd word waarschijnlijk ook beter.

Je doet nu bij startup een regel loggen. Deze zie je natuurlijk niet in je terminal want die terminal referentie word alleen doorgegeven bij programma's die je uit dat terminal opstart (als je 2 terminals opent en in de een een programma start zie je toch ook niet hello world in beide terminals?).

Je hello world word naar stdout geschreven, normaal een terminal, maar in het geval van een init script waarschijnlijk ergens geredirect naar een logfile. Je zou deze output kunnen redirecten naar een logfile naar keuze in je bash script, maar redirecten naar een ander terminal is erg lastig volgens mij.

[Brilsmurfffje]

Sleepkever schreef op dinsdag 12 januari 2016 @ 12:03:
Kijk eens in je logging. Grote kans dat het daar ergens staat. Zou je ook even kunnen vermelden wat je uiteindelijk doel is hiermee? Dat maakt de richting die je uit gestuurd word waarschijnlijk ook beter.

Je doet nu bij startup een regel loggen. Deze zie je natuurlijk niet in je terminal want die terminal referentie word alleen doorgegeven bij programma's die je uit dat terminal opstart (als je 2 terminals opent en in de een een programma start zie je toch ook niet hello world in beide terminals?).

Je hello world word naar stdout geschreven, normaal een terminal, maar in het geval van een init script waarschijnlijk ergens geredirect naar een logfile. Je zou deze output kunnen redirecten naar een logfile naar keuze in je bash script, maar redirecten naar een ander terminal is erg lastig volgens mij.

Waar kan ik die logging vinden?

Het uiteindelijke doel is een Python script starten dat UDP packetjes verstuurd vanuit een while true loop (infinity)

Dit python script werkt prima, als ik een terminal open en ik type, python /PATH/script.py dan werkt het zonder problemen..

[Sleepkever]

Ik zou eens een kijkje nemen in /var/log, en dan beginnen met syslog. Sowieso is het wel de moeite waard om in je achterhoofd te houden wat voor logfiles daar allemaal staan. mocht je ooit in de toekomst nog problemen ondervinden met je raspberry staan daar vaak de meldingen waarop je kan gaan googlen

Wat je ook kan doen om het voor jezelf makkelijker te maken is om alle output van je python script te redirecten naar een bepaalde logfile. Dat zou kunnen op de volgende manier als je je file bijvoorbeeld test.log in /var/log noemt (allemaal vrije keuze natuurlijk, wel zorgen dat de user waaronder je script draait daar schrijfrechten heeft!)

Bash:

#! /bin/sh

echo "launching Python script!"

python /home/pi/Desktop/test.py >/var/log/test.log 2>/var/log/test.log

met > redirect je de stdout naar die file toe en met 2> de stderr (de plek waar alle errors normaal naar toe gaan) naar dezelfde file zodat je die ook mee krijgt. Op die manier heb je het in ieder geval gescheiden van de rest.

[Brilsmurfffje]

Sleepkever schreef op dinsdag 12 januari 2016 @ 12:41:
Ik zou eens een kijkje nemen in /var/log, en dan beginnen met syslog. Sowieso is het wel de moeite waard om in je achterhoofd te houden wat voor logfiles daar allemaal staan. mocht je ooit in de toekomst nog problemen ondervinden met je raspberry staan daar vaak de meldingen waarop je kan gaan googlen

Hij staat er daar tussen als: Failed to start

Wat je ook kan doen om het voor jezelf makkelijker te maken is om alle output van je python script te redirecten naar een bepaalde logfile. Dat zou kunnen op de volgende manier als je je file bijvoorbeeld test.log in /var/log noemt (allemaal vrije keuze natuurlijk, wel zorgen dat de user waaronder je script draait daar schrijfrechten heeft!)

Bash:

#! /bin/sh

echo "launching Python script!"

python /home/pi/Desktop/test.py >/var/log/test.log 2>/var/log/test.log

met > redirect je de stdout naar die file toe en met 2> de stderr (de plek waar alle errors normaal naar toe gaan) naar dezelfde file zodat je die ook mee krijgt. Op die manier heb je het in ieder geval gescheiden van de rest.

Is er een simpele manier om dit gewoon voor elkaar te krijgen? Op windows plaats je een .bat in de juiste folder en voila het werkt..

[begintmeta]

Staat python in de PATH van de init-script als die wordt gestart? Je zou eventueel eens /usr/bin/python (of wat het dan ook maar zou moeten zijn) in plaats van python kunnen proberen.

[ Voor 48% gewijzigd door begintmeta op 12-01-2016 13:07 ]

[Sleepkever]

Brilsmurfffje schreef op dinsdag 12 januari 2016 @ 12:57:
Is er een simpele manier om dit gewoon voor elkaar te krijgen? Op windows plaats je een .bat in de juiste folder en voila het werkt..

Tja. Ik zou inderdaad even de suggestie van begintmeta uitzoeken, kijken of python wel op je path staat op dat moment.
Ik vermoed dat het makkelijkste manier zonder al te veel ellende is om het gewoon onder je eigen user in crontab te zetten met @reboot ervoor en > en 2> erachter om je output te redirecten naar een bepaalde logfile. Vermoedelijk heb je dan ook iets minder ellende met paths omdat python al wel beschikbaar is onder je eigen gebruiker.

[gekkie]

Ga er inderdaad maar vanuit dat het een PATH probleem is, meestal is dat niet gezet als init scripts dan wel scripts via cron uitgevoerd worden.
Dus of zelf zetten in je script of volledige path van de executable gebruiken zoals begintmeta aangeeft.

[Brilsmurfffje]

begintmeta schreef op dinsdag 12 januari 2016 @ 13:06:
Staat python in de PATH van de init-script als die wordt gestart? Je zou eventueel eens /usr/bin/python (of wat het dan ook maar zou moeten zijn) in plaats van python kunnen proberen.

Hoe bedoel je?

Ik zie in de logs wel de echo terugkomen die ik in het .sh bestandje had gezet. Deze echo staat in het syslog

[begintmeta]

Brilsmurfffje schreef op dinsdag 12 januari 2016 @ 13:09:
Hoe bedoel je?
...

Een programma draait vanuit een bepaalde 'omgeving', die kan bepaalde parameters bevatten die de werking van het betreffende programma beïnvloeden, 'environment variables'. Een van die variabelen is 'PATH', die wordt door software vaak gebruikt om de volgorde en/of plaats waar naar executables wordt gezocht te bepalen. Als de omgeving waar je init-script niet het pad bevat waar python te vinden is, zal het script die executable dus wellicht niet kunnen vinden. Als je je initscript $PATH laat echoen, kan je eventueel ook eens teruglezen welke waarde die variabele in die concrete omgeving had, en controleren of python daar te vinden is.

Mocht dat niet zo zijn kan je ofwel de path zodanig veranderen dat python wel kan worden gevonden (voor je oproep van python), of de python-executable inclusief expliciete locatie oproepen, of python naar een plek kopieren/verplaatsen waar het wel zal worden gevonden.

[ Voor 16% gewijzigd door begintmeta op 12-01-2016 13:24 ]

[Brilsmurfffje]

begintmeta schreef op dinsdag 12 januari 2016 @ 13:17:
[...]

Een programma draait vanuit een bepaalde 'omgeving', die kan bepaalde parameters bevatten die de werking van het betreffende programma beïnvloeden, 'environment variables'. Een van die variabelen is 'PATH', die wordt door software vaak gebruikt om de volgorde en/of plaats waar naar executables wordt gezocht te bepalen. Als de omgeving waar je init-script niet het pad bevat waar python te vinden is, zal het script die executable dus wellicht niet kunnen vinden. Als je je initscript $PATH laat echoen, kan je eventueel ook eens teruglezen welke waarde die variabele in die concrete omgeving had, en controleren of python daar te vinden is.

Mocht dat niet zo zijn kan je ofwel de path zodanig veranderen dat python wel kan worden gevonden (voor je oproep van python), of de python-executable inclusief expliciete locatie oproepen, of python naar een plek kopieren/verplaatsen waar het wel zal worden gevonden.

Dit was precies het probleem, alleen heb ik het opgelost door het script 5 seconden te laten slapen

Bedankt voor de hulp!

[begintmeta]

Brilsmurfffje schreef op dinsdag 12 januari 2016 @ 13:56:
[...]


Dit was precies het probleem, alleen heb ik het opgelost door het script 5 seconden te laten slapen

Bedankt voor de hulp!

Het leek me wel een plausibele verklaring, fijn dat het opgelost i, alleen kan je je misschien afvragen of je oplossing wel de stabielste is, want waarom werkt het wel met wachten? Kan datgeen wat in de tussentijd gebeurt eventueel niet gebeuren of eens wat later gebeuren, waardoor je script toch noch zou falen?

[Orthodroom]

Wellicht beter om het python script aan te roepen in /etc/rc.local

[Brilsmurfffje]

begintmeta schreef op dinsdag 12 januari 2016 @ 21:12:
[...]

Het leek me wel een plausibele verklaring, fijn dat het opgelost i, alleen kan je je misschien afvragen of je oplossing wel de stabielste is, want waarom werkt het wel met wachten? Kan datgeen wat in de tussentijd gebeurt eventueel niet gebeuren of eens wat later gebeuren, waardoor je script toch noch zou falen?

Ja daar heb je gelijk in, misschien dat ik dat nog ga doen, het is voorlopig een proof of concept en er is een visuele terugkoppeling in de vorm van een ledje bij de ontvanger om te zien of het werkt.
De 5 seconden zijn lang genoeg omdat het probleem erin zit dat het script al ingeladen wordt voor de GUI en op dat punt waarschijnlijk nog geen netwerk actief is.

[stfn345]

Kleine opmerking, je shebang staat zo: #! /bin/sh , volgens mij moet dat officieel #!/bin/sh zijn (zonder spatie).

[begintmeta]

Brilsmurfffje schreef op woensdag 13 januari 2016 @ 11:44:
...
De 5 seconden zijn lang genoeg omdat het probleem erin zit dat het script al ingeladen wordt voor de GUI en op dat punt waarschijnlijk nog geen netwerk actief is.

Je zou eventueel ook met dependencies kunnen werken, als je dan toch bezig bent.

razorhead schreef op woensdag 13 januari 2016 @ 11:47:
Kleine opmerking, je shebang staat zo: #! /bin/sh , volgens mij moet dat officieel #!/bin/sh zijn (zonder spatie).

Mag vziw* wel, moet zeker niet inderdaad.

[ Voor 34% gewijzigd door begintmeta op 13-01-2016 12:14 ]