RaspberryPi FTP - ncftpput laddar upp "tom" bildfil.

[sodjan]

Har inte miljön (något slags Linux?) något slags batch-köer?

Om jag (i en helt annan miljö) har saker som ska köras "samtidigt"
men ändå ett i taget, så har jag ett "SUBMIT/QUE=MYQUE job" i
CRONTAB filen och batchkön MYQUE har sedan JOB_LIMIT=1.
På det sättet serialiseras allt.

Ett annat sätt är att starta/submita den andra jobbet på slutet
av det första jobbet.

En annan sak...
Det verkar som att du kör t.ex perl och ftp verktyget direkt from crontab?
Är det inte generellt mer flexibelt att alltid köra ett shell-script som sedan,
förrutom att köra perl eller ftp, även kan göra annat, så som t.ex en delay
om det behövs eller något annan "house keeping" som man behövas...

D.v.s att om du alltid vill överföra dina resultat när en ny bild genereras så så kan
ju scriptet som cron startar både köra perl och ftp-verktyget i samma script.
Då kan inga fil konflikter uppstå.

[Nerre]

Det finns nog ett dussin olika lösningar för batch-köer, finns ingen som direkt "ingår i systemet".

Linux i sig är ju bara kerneln, sen har ju alla linux-distributioner lite olika val av vilka applikationer man anser vara "grundsystemet".

[sodjan]

OK.
Frågan var mer hur man normalt kör "saker" från cron.
Om det är normalt att man kör t.ex perl eller ftp verktyg
direkt eller om deet är normalt att man bakar in det i ett script.
Som jag ser det har man bättre kontroll/styr möjligheter om
man kör det hela från ett script.

[Nerre]

Det beror helt på.

Ska man göra ett script så är det kanske inte alltid man kommer på ett bra ställe att lägga scriptet på (de script jag kör från /etc/crontab har jag nog ligger i /root/ men det är nog inte riktigt bästa stället), och om det ändå bara är ett kommando som ska köras så...

Det är ju så att det finns dels en global cron-lista (/etc/crontab) och sen har varje användare (inklusive root) en egen crontab (som man inte kan redigera som en fil utan måste redigera med kommandot crontab). Kör man ett script så finns det ju en liten liten risk att man råkar köra samma script från två olika crontab utan att man inser det.

Sen har vi å tredje sidan det att i debian-baserade system så har man idag mapparna
/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly

där man kan "droppa" script som då körs med de intervallen.

[sodjan]

> Det beror helt på.

Tja, t.ex i det aktuella fallet i tråden.
Perl skapar grafiken och ftp verktyget flyttar filen.
Är det inte då normalt att lägga dom i samma script?
Istället för att ha flera crontab entries?
D.v.s om de alltid ska köras tillsammans i alla fall?

(Att det kan finnas flera crontab filer eller att det finns
olika teknik att lägga/droppa filer där är ointressant.)

[Nerre]

Jo, det var ju det jag skrev innan också, att det måste vara smartare att göra ett script som först anropar scriptet som skapar filen och sen laddar upp den.

Men det beror ju på vad scriptet som skapar filen egentligen gör, det scriptet kanske bara signalerar till en befintlig process och då kommer det ju inte att vänta på att filen är skapad innan det släpper kontrollen vidare.

[sodjan]

Nej det är ju sant. Aja, jag bara reagerade lite när jag såg
att ftp verktyget kördes direkt från crontab. Det gör det ju
svårt att få med t.ex felhantering (det var ju även frågor om
returnkoderna från ftp verktyget och de "försvinner" väl bara
om man kör det så) eller filhantering kring ftp överföringen,
ibland vill man arkiva/spara filer o.s.v.

[Nerre]

Nej, felmeddelanden från grejer som körs från crontab hamnar i crons loggfil. Vill man slippa det måste man köra redirect (antingen till /dev/null eller till separat loggfil). Fast det är bättre att se till att det bara blir output om det verkligen blir nåt fel (oftast funkar det att redirectla stdout till /dev/null och låta stderr hamna i loggarna).

[sodjan]

Hela "grejen" med returkoder från verktyg är ju för att se om det gick bra eller inte!
Varför i jösse namn skulle man vilja styra dom till dev/null ?

> ...och låta stderr hamna i loggarna

Där gör det ju ingen nytta, om man inte *tittar* i loggarna, d.v.s t.ex vid
senare felsökning då man undrar varför det inte har fungerat (på en vecka ).
Hela grejen är ju att fånga upp felet just då det sker och agera på det direkt.

För att ta det aktuella fallet i tråden. Vi antar att en FTP alltid ska köras
när en ny bild har skapats. Då skulle jag vilja ha ett script som både kör
perl programmet och FTP överföringen. Båda har lite felhantering och
skickar t.ex ett mail då något går fel. Scriptet kan sedan startas via
cron, det är ju det normala.

Om FTPn inte ska köras för varje ny bild, så blir det något mer jobb...

[Nerre]

Inte returkoder, men en del grejer är kanske inte gjorda för att köras i "tyst" läge utan babblar en massa även om saker och ting går enligt planen.

Jag har sett script där ett kommando körs med output omstyrt till /dev/null, sen OM returkoden indikerar att något gick fel så körs samma kommando en gång till, utan redirect, för att få felmeddelanden till loggen.

Men sen beror det ju helt på hur viktigt det är att man upptäcker felet när det uppstår. Det är skillnad på felsökning och övervakning. Om en uppladdning som ska köras en gång i timmen går fel så finns ju eventuella felmeddelanden i loggen för den senaste timmen.

Att skicka felrapport via mail kan ha nackdelar också... Ponera att det skickas en bild i minuten och klockan 2 på natten blir det nåt fel. När du vaknar klockan 8 på morgonen har du då över 300 mail i inkorgen med samma felmeddelande...

[sodjan]

Jo. Man jag har det hellre i loggarna *om* jag skulle vilja se det än i
papperskorgen. Problemet är att när det händer något så kanske man
inte kan köra om det bara för att få se meddelanderna. De gör ju inte
direkt någon skada i loggarna, bara några bytes extra lagringsutrymme.

Aja, strunt samma. Som jag uppfattade så verkar "root-cause" i detta
fall ha varit att FTP försökte överföra filen innan Perl var klar med den.
Och alltså blev den tom på mottagande system. Genom att synka de två
stegen ("skapa filen" och "överföra filen") så borde det fixa sig.

[XorXaX]

Det här är ju nästan ett bokexempel på vad semaforer används till i programmering

[sodjan]

OK, hur löser semaforer rent praktiskt det aktuella fallet?
Stöder de aktuella programmen (perl resp FTP verktyget) semaforer?

[XorXaX]

Det har jag ingen aning om. I det aktuella exemplet skulle jag nog snarare löst det genom att se till att sköts seriellt, först skapa filen och sedan ladda upp den, i samma program.

Men någon som är mer haj på Linux än mig kanske vet om det finns något semaforprogram man skulle kunna använda? Jag tänker mig att programmet har inparametrar som program att köra samt ett semafornamn (låsfil?).

T.ex.:

Kod: Markera allt

sema sema.lock ~/script1.sh
sema sema.lock ~/script2.sh

Där första anropet skapar låsfilen (semaforen) och startar ~/script1.sh, och släpper semaforen när exekveringen utav ~/script1.sh är klar, så klart i en bakgrundstråd så man kan gå vidare till nästa rad.
Andra anropet kollar om det finns en låsfil och väntar i så fall tills den är borta innan den skapar en ny semafor och sedan startar ~/script2.sh.

[thebolt]

Finns ju överhuvudtaget ingen anledning att krångla till det så med externa program för att sekvensiera två anrop.

Som Sodjan skriver är ju det bästa att köra ett shell-script som sen anropar de program som behvs, eller om man vill göra det lite snabbare i detta fallet använda

Kod: Markera allt

skapa-graf.pl && ncftp..

. Baserat på short-circuit-logiken i alla (moderna) shells i linux så får det följden att skapa-graf.pl körs först, om den returnerar icke-felkod så körs ncftp (annars inte).