Hvordan kører jeg et pythonscript ved boot? [LØST]

Det burde være nok at sætte den ind i /etc/rc.local.

Hvor er den installeret? Det kan være at din /usr/local/bin ikke er i PATH når rc.local køres. Hvis det er problemet, så kan du bare angive absolut sti til cloudprint.

Står der noget i /var/log/messages?

Jeg bruger allerede en absolut sti, men det virker alligevel ikke. Scriptet kører dog :

grep -lf cloudprint

1770 /usr/bin/python /usr/local/bin/cloudprint


Men det fungerer ikke, det printer ingenting ud. Så snart jeg kører det direkte fra kommandolinjen virker det fint.

Det ligger i /usr/local/bin/cloudprint

Kan det være noget med den bruger det kører under i rc.local? Det er sådan at scriptet bruger nogle crendentials i /root/.cloudprintauth. Kan der være problemer med at tilgå denne under opstart?

Scriptet kører som root indefra /etc/rc.local

Du kan bruge
su - [brugernavn] -c "[commando]"

#3: Du kan bruge
su - [brugernavn] -c "[commando]"

Mener du ikke:

su -u [brugernavn] sh -c "[commando]"

Men det virker stadig ikke. Dette er den fulde linje i rc.local:

sudo sh -c "/usr/bin/python /usr/local/bin/cloudprint -d"

Jeg bruger ikke -u da det skal køre som root.

Er der nogen måde at "genkøre" rc.local til testbrug så man ikke skal boote hver gang?

Det irriterende er at der ikke er nogen logmeddelelser der kan hjælpe. Hverken i syslog eller messages etc.

#4: sudo sh -c "/usr/bin/python /usr/local/bin/cloudprint -d"

Hvis du bruger sudo, står den så ikke og venter på password - som så aldrig kommer?

rc.local køres som udgangspunkt af root, så sudo er næppe nødvendigt. Jeg har selv bakset med den slags nogle gange, og det lykkes mig som regel først at fatte sammenhængen, når jeg får den til at logge noget meningsfyldt.

Hvad med at prøve:
/usr/bin/python /usr/local/bin/cloudprint -d 2> /tmp/stderr.txt

Jeg tror ikke du kan eksekvere rc.local på en måde, så det svarer til situationen i forb. med boot.

Men du logger vel ikke ind på din plug? Du starter den vel bare op, og så kører de tjenester, som de skal?
Kalder den nogle tjenester, som ikke er startet op på det tidspunkt, hvor du kører den? I så fald, hvad sker der, hvis du sleep'er den, så kommandoen kører efter det hele er oppe?

#5: Hvis du bruger sudo, står den så ikke og venter på password - som så aldrig kommer?
Ikke som root. Normalt så går kommandoer direkte gennem sudo hvis man er logget ind som root.

@marlar, hvordan ser din rc.local ud?

#6: Men du logger vel ikke ind på din plug?

Det er jo netop det der er problemet. Men da cloudprint ikke virker ved boot er jeg nødt til at logge ind og starte programmet manuelt hvis jeg af en eller anden grund har genstartet serveren.

#6: Kalder den nogle tjenester, som ikke er startet op på det tidspunkt, hvor du kører den? I så fald, hvad sker der, hvis du sleep'er den, så kommandoen kører efter det hele er oppe?

Godt tænkt, men desværre virker det ikke.

#5: Hvad med at prøve:
/usr/bin/python /usr/local/bin/cloudprint -d 2> /tmp/stderr.txt

Vi er vist ved problemets kerne. I loggen står: Google username:

Med andre ord spørger programmet om mine loginoplysninger, noget det ellers normalt læser fra filen /root/.cloudprintauth. Eller med andre ord præcis det som jeg foreslår i #2.

Men hvorfor kan programmet ikke læse .cloudprintauth under opstart?

Er du kommet videre?

#8: Men hvorfor kan programmet ikke læse .cloudprintauth under opstart?
Tja, jeg ville da tro at /root er mountet på det pågældende tidspunkt. Kan det være permissions eller noget andet?

Man kan sikkert læse tykke bøger om emnet. Man kan også bare gå i krig med med loggingen :)...

Tilføj i rc.local:
mount -l > /tmp/test.txt
ls -la /root >> /tmp/test.txt

(muligvis absolutte stier på mount og ls)

Eller er det evt. en mulighed at ligge credentials-filen et andet sted - fx. under /etc, hvor den vel egentlig har sin rette placering?

Nu fik jeg så svaret på stackexchange.

Scriptet har hardcoded stien til .cloudprintauth:

self.auth_path = os.path.expanduser('~/.cloudprintauth')

Og shell-expansion af ~ virker ikke ved boot.

Tricket er derfor at ændre i scriptet så der bruges /root i stedet.

Så virker det :)

#10: Og shell-expansion af ~ virker ikke ved boot.

Er det noget du ved, eller noget du tror? Eller udleder af opførslen?

Expansion af ~ afhænger jo af hvem, der er bruger på det pågældende tidspunkt. Er det root eller su'er jeg til root, bliver ~ til /root/, men jeg ved ikke, om det virker anderledes, hvis man bruger sudo.

Under alle omstændigheder er moralen vel, at man bør bruge absolutte stier i scripts, hvor man er i tvivl.

#11: Er det noget du ved, eller noget du tror? Eller udleder af opførslen?

Det stod i svaret fra stackexchange og det virkede da jeg ændrede det til en absolut sti. Det tyder altså på at det er korrekt.

Men jeg kender ikke som sådan reglerne for shell-expansion.