Svenska ElektronikForumet

Håller på med att försöka få min raspberry att logga temperaturer
har skrivit/knyckt ett program som gör detta och fungerar om jag kör det via ssh

men när jag stänger ner sessionen så dör programmet oxå

hur startar man ett pythonprogram vid boot som sen ligger i bakgrunden och körs?

//Ola

'nohup' finns om man vill att program skall snurra även när man loggar ur, tror också att man köra med någon argument i bash att hålla liv i program när man loggat ut.

/etc/rc?.d där frågetecken betecknar run level, där brukar man lägga symboliska länkar till sparade script eller program liggande under /etc/init.d som skall starta, stoppas, restartas i samband med boot och andra aktiviteter.

det som brukar knölas med innan allt fungerar är att sätta filrättigheter, användare och grupper samt att det startar i rätt ordning då servisar man anropar i sitt program bör vara startade innan sas.

För att starta ett program i bakgrunden skriver man normalt en & efter, fast det kanske dödas ändå om man loggar ut sessionen (jag är lite osäker).

Men om du vill att det ska starta vid boot så borde du skriva ett upstart-script.

Är det inte Debian i botten på pajen? Då kan du titta under /etc/init.d hur scripten som ligger där ser ut. Det finns ett som heter skeleton som du kan kopiera och utgå från. Du behöver kanske kolla igenom några andra lite enklare script för att se vad du behöver ha med eller inte.

Sen för att bestämma i vilka runlevels det ska köra så använder man update-rc.d. I normala fall brukar det räcka med "update-rc.d <scriptnamn> defaults". Ingen sökväg behövs till scriptnamnet eftersom update-rc.d tittar i /etc/init.d.

OBS! update-rc.d upprätthåller en databas, så lägger man in nåt med den så måste man använda den även för att ta bort eller ändra, annars kommer det tillbaka nästa gång man installerar ett paket (eftersom då uppdateras alla upstart-grejer från databasen).


Googlar du hittar du säkerligen dussintals sidor som har egna varianter på hur man gör, och som dessutom gör "på fel sätt"! I Debian finns det massor med fiffiga hjälpscript just för att man ska slippa en massa manuellt hackande.

En enkel '&' efter programmet fungerar inte när man stänger terminalen - när föräldrarprocessen (ditt shell) dör så dör också alla barnprocesser (dina program) som är startad av shellet

'nohup' fångar signalmeddelandet SIGHUP så att det inte når barnprocessen och dödar denna när föräldarprocessen dödas vid utloggning och när föräldrarprocessen dör så ärver init-processen (1) barnprocessen eftersom den är förfader till samtliga processer som snurrar på en unix-maskin. Även stdin, stdout och stderr måste redirektas om vilket görs av 'nohup' och oftast blir det en 'nohup.out' av eventuella meddelande som programmet skriver ut i roten av hemdirektoryt.

ofta så drar man igång ett program& typ ett backupprogram som skall göra en fullbackup och tar ansenlig tid och efter ett tag inser att man vill stänga terminalen och då är man för sent ute med nohup då denna måste startas samtidigt med programmet ifråga:

i bash kan man använda 'disown -h (job-spec)' där job-spec är 'job-nummret' på programmet som snurrar (typ '%1', leta med 'jobs' vad önskade programmet har för nummer) och bash överger då barnprocessen och som jag gissar även här hamna på init(1):s föräldrarskap och snurrar vidare som en demon oavsett om shellet är dödat eller inte. Skillnaden mellan nohup och disown är att stdin, stdout och stderr blir riktat mot /dev/null i samband med disown och man får inte reda på om programmet har gjort det den skall eller krachat med felmeddelande - möjligen kan det gå med 'program | tee loggfil.log&' innan man gör disown om man skall fånga eventuella meddelande från programmet - har dock inte provat detta...


kort sagt vill man ha ett program startat och inte slockna när man loggar ut så skall det göras av en process som redan är startad innan man loggar in och inte stoppas igen när man loggar ut igen - där är tex. rc.d processerna sådan sak och startar igång saker vid boot.


Man också kan titta på 'screen' med 'screen -A -m -d -S något_namn ./programskript &' och en bakgrundsprocess skapar en virtuell terminal för processen att rapportera emot och man kan logga in senare och titta på det.

en & efter funkar visst att använda i en terminalen. Det viktiga är att LOGGA ut. Loggar man ut kommer processens ägareskap tas över av pid 1. Gör man inte detta och timear ut dör processen.

Startar man med nohup slipper man ovan scenario.

Man kan också när man startat med & för att slippa ovan köra disown så kommer man ge bort ägandeskapet.

Man kan istället för & även använda ctrl + z för att pausa och sedan skriva bg för att sedan skriva disown

Många sätt finns de men det är inte svaret på ursprungsfrågan Vill du ha autostart av saker så lägg dem t ex i /etc/rc.local så kommer de startas vid boot.

Nackdelen med att köra dem i rc.local är väl dock att den bara kan starta grejer?

Gör man ett "riktigt" upstart-script så kan man start, stoppa och starta om. Och dessutom kan man välja i vilka runlevels grejerna ska köras.

tycker jag provat det mesta utan framgång

rc.local har ju en bra rad i sig


# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi

exit 0


har provat med

sudo python /home/pi/temp2.py &
exit 0

men jag får inte ut några värden i min loggfil

mycket av det ni skriver har jag läst mig till men inte förstått

kan någon starta /home/pi/temp2.py vid boot
eller handgripligen berätta hur jag skall göra

//Ola

Grundtips: Skriv alltid hela sökvägen till alla kommandon.

Du vet inte hur PATH ser ut när scriptet körs.

Sen kan du skippa sudo, eftersom uppstartscripten körs som root.


Eventuella felmeddelanden borde du hitta i /var/log/messages eller /var/log/syslog. Min gissning är att du hittar "unknown command" där just eftersom du inte anger hela sögvägen till python.

Håller med Nerre om hela sökvägen.


Du skulle kunna kolla om scriptet verkligen körs.
Det gör man med jobs

Resultatet kan bli t.ex:
[1]+ Kör sudo python scriptnamn.py
[2]+ Stoppat python
[3]+ Kör sudo python scriptnamn2.py


För att "flytta" ett sådant bakgrundsjobb till förgrunden så skriver man "fg" följt av nummret på jobbet.
T.ex fg 3
Sedan är det bara att avsluta (eller annat) precis som vanligt.


En sak till förresten:
Om man skriver t.ex sudo python scriptnamn.py & och trycker Enter
så kan det se ut som att det ändå körs i förgrunden. Tryck då Enter igen så får du tillbaka kontrollen.
(Programmet körs ändå i bakgrunden. Dubbelkolla med jobs.)

Kan ju bidra med några till felsökningstips.

För att kolla om uppstart-grejer körs fungerar det inte så bra att använda print/echo, eftersom man inte riktigt vet var output hamnar.

Ett knep för att kolla om det körs öht är att använda kommandot touch för att skapa eller uppdatera tidsstämpen på en semafor-fil.

Ex.

/usr/bin/touch /root/script_run

och sen kollar man klockslaget på tidsstämpeln på script_run

Ett annat knep är att det finns ett kommando som heter logger som kan användas för att skriva till syslog (/var/log/syslog).

ex.

/usr/bin/logger -t Script Nu körs scriptet

(-t sätter ett unikt prefix på raderna, bra om man vill filtrera ut dem med grep eller nåt)

Ett tredje knep är att det ju går att logga output från det man kör direkt till en egen loggfil

/usr/bin/python scriptnamn.py >>/root/script.log 2>&1 &

Men jag vet inte om det behövs när man kör det som upstart som sagt var, tror att output från de scripten hamnar i syslog automatiskt.

Observera att en vanlig redirect med > eller >> bara tar stdout, vill man ha med felmeddelanden (stderr) så måste man ha det där 2>&1 med också.

Är det något specifikt med RasPI att det ska vara så kollosalt
krångligt att göra något så simpelt och vanligt som att starta
något vid boot? Eller är det generellt för Linux?

Jag är intresserat av att komma igång med Linux men jag saknar rent faktisk just den funktion, gärna så enkelt som det finns(/fanns) i Windows/DOS: Autoexec.bat

Kunde man få till det ville det vara trevligt. Och ja, jag vet om att det kan vara säkerhetsissues med den funktion men för att t.ex. ha en styrning av ett hus vill jag inte ha ett system som fungerar jättebra - men som jag manuellt måste starta manuellt efter power-fail.

sodjan skrev:Är det något specifikt med RasPI att det ska vara så kollosalt
krångligt att göra något så simpelt och vanligt som att starta
något vid boot? Eller är det generellt för Linux?

Vad är det för kollossalt krångligt? Det krångliga är att felsöka när det inte funkar...

Vad finns det för lättare sätt än att skriva in start-kommandot i rc.local? rc.local fungerar nästan precis som autoexec.bat, med den stora skillnaden att DOS är ett single user icke-multitasking operativ. Ska man plötsligt ha flera användare och multitasking blir det lite bökigare.


Dock så ger ju rc.local fenomenet att kommandot alltid körs vid uppstarten, oavsett runlevel. Och om man använder olika runlevels för olika saker så behöver man alltså "krångla lite mer" med update-rc.d och sånt.

Linux är ett fleranvändarsystem och det krånglar till det en del.
Om man vill köra ett initskript som 'user' kan man oftast lägga till en rad i filern .bashrc.
' .bashrc' är en dold fil i /usr/home/xxx där xxx står för 'username'.
Detta gäller i Ubuntu och Debian såvitt jag vet.
Det finns andra varianter, jag vet inte vad som gäller för Raspberry Pi.

Vill man köra sitt skript vid systemstart är det mer komplicerat.
Se t.ex. /etc/init.d/README om den filen finns.

Om det bara hade funnits en runlevel hade det varit lite enklare, då hade man enkelt kunnat ha en mapp med script som bara kördes i nummerordning ungefär.

Det är ju lite så det fungerar idag, fast det är en mapp per runlevel och dessutom så är det inte bara start-script utan även stopp-script för att kunna stoppa vissa grejer när man byter runlevel.

Sen är ju hela det här tjofräset just för att starta upp "services" i rätt följd. Det är ju enkelt att varje "service"-paket man installerar lägger in ett eget startscript och sen talar om när det ska köras. Enkelt att städa bort när man avinstallerar. Tänk om alla program skulle in och rota i samma fil...

Det finns ju ett nyare system, som jag personligen tycker är mycket krångligare, där man istället har olika villkor för att saker och ting ska starta upp. (Det kallas händelse-baserat.)

Så här ser det t.ex. ut för gdm (gnome display manager, d.v.s. loginhanteraren för den grafiska miljön) på min maskin hemma: Det är hur hårigt som helst att felsöka eftersom man inte kan se sambanden mellan de olika filerna... Här ser jag att den beror på en massa event, men det finns (mig veterligen) inget lätt sätt att se vilka grejer som ger desssa event...