Svenska ElektronikForumet

> Vad är det för kollossalt krångligt?

OK, jag bara läste denna tråd...

Jag förstår inte vad "flera användare" eller "multitasking" har med detta att göra.
Finns det ett uppstartsscript (t.ex rc.local) så är det väl bara att starta skiten
därifrån !? Är det problem att starta något från root åt/för någon annan?

> Tänk om alla program skulle in och rota i samma fil...

Där jag kör skapar varje applikation en egen STARTUP fil i den gemensamma
STARTUP katalogen. Sedan lägger system managern in ett anrop till denna
fil i det system gemensamma startup scriptet. Enkelt. Dessutom finns det inget
tjafs med olika runlevels, är det ett multiuser/multitasking system så är det...

Det absolut enklaste:
1. Se till att ditt skript är körbart d.v.s. #!/usr/bin/env python på första raden och flaggad som körbar
2. Stoppa in i rc.local med den absoluta sökvägen samt avsluta med ett &

Sen är ju frågan exakt vad ditt python skript gör, vad annat måste vara startat o.s.v.

Om det är så att du bara skriver rakt ut (t.ex. med print()) så måste du redericta utskriften till en fil med
>> /sökväg/till/fil

>Där jag kör skapar varje applikation en egen STARTUP fil i den gemensamma STARTUP katalogen.
Så funkar det på Linux med, dock finns det flera run levels (t.ex. så att du kan starta upp i konsolmiljö
först innan du drar igång det grafiska). Om man inte använder detta måste man dock veta vilken som
är standard i den distributionen du har (2 i Ubuntu, 5 i Debian)

sodjan skrev: Finns det ett uppstartsscript (t.ex rc.local) så är det väl bara att starta skiten
därifrån !? Är det problem att starta något från root åt/för någon annan?

Nej, men problemet här var ju att TS hade lagt in starten av sin grej där men den startade inte. Då måste man felsöka, och det är kanske inte så lätt alla gånger eftersom man inte säkert vet vad felet är. Man behöver nån form av felmeddelanden eller använda uteslutningsmetoden.

Där jag kör skapar varje applikation en egen STARTUP fil i den gemensamma
STARTUP katalogen. Sedan lägger system managern in ett anrop till denna
fil i det system gemensamma startup scriptet. Enkelt. Dessutom finns det inget
tjafs med olika runlevels, är det ett multiuser/multitasking system så är det... :-)

Men så är det ju här också ungefär. Alla programs uppstart-script ligger i /etc/init.d/.

Sen finns det en mapp för varje runlevel (ex. /etc/rc4.d). I den mappen ligger det symboliska länkar till scripten i /etc/init.d. Länkarna är döpta till Snn<scriptnamn> eller Knn<scriptnamn>, där nn är nummer från 00 till 99. När man går in i en runlevel så körs alla S-script i nummerordning med parametern "start". När man lämnar en runlevel körs alla K-script i nummerordning med parametern "stop". Sen finns det logik som ser att "om det finns ett K-script i gamla runleveln och ett S-script i den nya behöver jag inte stoppa och sen starta utan skippar dem".

Dessa länkar är bökiga att underhålla själv, därför finns update-rc.d som automatiserar det hela lite.

Finessen med runlevels är främst att man enkelt kan dra upp maskinen i ett läge där bara vissa services är igång. Idag används det nog inte så ofta, men förr ville man kanske kunna starta maskinen i ett läge där man enkelt kan göra backup utan att filerna är låsta och liknande. Idag löser man det oftast på smidigare sätt.

Ett annat sätt bör väl vara att köra cron och använda @reboot?

Var bara noga att använda absoluta sökvägar. Då får du ju logg på om nåt gick fel vid starten av skriptet i /var/log/cron

Precis tänkte precis skriva crontab för usern och @reboot. Funkar ypperligt.

Och som sagt alltid full path. T ex crontab har långt ifrån hela pathen inladdad!

Liten sidofråga bara:

Pajn:
"Se till att ditt skript är körbart d.v.s. #!/usr/bin/env python på första raden och flaggad som körbar"

Vad är skillnaden mellan att ha den raden jämfört med att inte ha den? (Bortsett från just den skillnaden. )

Jag har aldrig med den raden och startar mina script med python scriptnamn.py
så jag blev nyfiken på varför den raden behövs.

> Vad är skillnaden mellan att ha den raden.......

http://en.wikipedia.org/wiki/Shebang_%28Unix%29

Nu förstår jag. Tack.

jag har ytterligare en fundering kring detta.
När jag startar mitt script i rc.local så kan man se att programmet är uppe och kör bland processerna. Men hur gör jag för att se vad programmet har skrivit ut för information till terminalen om jag t.ex vill logga in via Telnet och kolla status om allt är som det ska?

/Daniel

Du får redericta stdout till en fil med hjälp av >> /sökväg/till/fil

Eller använda "screen".

screen -dR gör en ny screen-session, om det inte redan finns en, då går den till den sessionen.
Man gör vad man vill (t.ex startar ett script) och kan stänga terminalfönstret.
Det kan då varna att något körs (det man startat), men det är ingen fara eftersom man kör med screen.

Sedan, när man vill kolla vad som händer, så öppnar man ett terminalfönster
och knappar in screen -dR så är man tillbaka där man slutade.

(Tänk på att det är skillnad mellan stora och små bokstäver.)

Några länkar med mer info:
http://sipb.mit.edu/doc/screen/
http://www.tecmint.com/screen-command-e ... terminals/
http://www.computerhope.com/unix/screen.htm#02



edit:
Danielr112:
"en & efter funkar visst att använda i en terminalen. Det viktiga är att LOGGA ut."

Jag testade nyss och det hjälper inte att logga ut. jobs ger tomt resultat när jag loggat in igen.
Samma sak om man lägger till nohup.
(Testat på en Raspberry Pi med det vanliga Raspbian wheezy (Debian).)

edit 2:
Jag hade nog lite för mycket blod i kaffeomloppet i förra edit.
jobs returnerar ju förstås inte de script som körts med sudo scriptnamn.py

du lär inte hitta en nohup:ad eller disown:ad process med jobs när du loggar in igen då jobs bara är relaterat processer som aktuella shellet själv startat - inte vad som droppat ned till pid(1) när gamla shellet från förra sessionen dödades när du loggade ut.

Du får titta med 'ps' när du loggar in igen för att se om processen lever eller inte och med lite förberedelse med omdirigerade stdin, stdout och stderr till loggfiler på lämpligt ställe innan det körs så bör något i loggfilväg dyka upp om programmet ifråga övh. har skrivit ut något med echo eller printf och motsvarande .

med kill -20 pid gör det samma sak som Ctrl-Z (SIGTSTP)
med kill -19 pid så stoppar man processen (SIGSTOP)
med kill -18 pid startar man upp processen som stoppades av kommandona innan (SIGCONT)

och med kill -9 pid så dödar man processen

'pid' är då processnummer som man ser i ps med rätt flaggor och lite snopet blir det om man som root skriver 'kill -9 1' utan att vilja det...

Jag gjorde ett nytt test.
sudo nohup ./pannlog_styrning_v1.py &

Sedan logout/login och då visar sudo ps:
Logfilen (output-filen) från nohup är förresten också tom.
(Mitt script skriver ut lite info när det körs igång och precis innan det avslutas.)

prova ps -x och se om det visar lite mer - risken är stor att du bara ser shellets startade processer med bara 'ps' och inte de som är utanför ditt shells ägansdeskap

jag har ett gammal 'ps -lax' i mina fingrar om man skall se något intressant...


Det är heller inte säkert att det skrivs ut något i filen synligt utifrån medans programmet snurrar - det kanske behöver 256 - 4096 tecken utskrivet text beroende på filbufferstorlek innan det flushar ut på filen eller att programmet stängs ned innan du ser något.

vet inte om 'sync' kan tvinga ut data i förtid...


---

hmm det där att försöka få ut senast skrivna texten ur filbuffer som logfil från en alltjämt gående script som skriver ut en rad då och då verkar vara en huvudvärk som har värkt i dekader i unixvärlden.

folk som hackar i clib, stdio mm. som hanterar detta verkar vara väldigt reluktant på att lägga in förändringar som skulle underlätta detta då man har argument som att det skulle kunna öppna för säkerhetshål mm. och de goda förslagen som ändå kommit - implementeras inte.

Så fort processen kopplas ifrån en tty-terminal med tecken och/eller radorienterad buffring och istället skriver mot pipe eller fil så åker det in en filebuffer på mellan 1024 till 4096 byte (systemberoende) innan det flushar på fil eller vidare i en pipe och görs synlig för andra processer.

och man får labba mot 'stdbuf' eller program som 'unbuffer' som följer med vissa verktyg som lurar systemet att programmet som man vill sniffa loggen ifrån, kopplas till en virtuell teckenorienterad tty-terminal att skriva emot och inte skriver mot en block-device...

vet inte om det skulle gå med liknande trix med 'dd' med ibs=x och obs=x (där x är antal byte i blocket) kan styra inlästa och utskrivna blockstorlek

Om scriptet är perl så kan man tydligen göra utskriften 'het' och radorienterad med '$| = 1;' på en rad och göra den befintliga filpekaren att den uppdaterar radvis även när den är omriktad mot fil/pipe

python har en -u som också skall forcera utskriften till radorienterat när den skriver mot fil

Icecap skrev:Autoexec.bat.

Närmast det är /etc/rc.local

Men det bästa är att göra det som en faktisk tjänst. Och låta init hantera det.