info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Was passiert mit einem cron job, wenn crond bei der Ausführung neu gestartet wird?
0 views
Skip to first unread message
Nelson Matias
Nov 9, 2023, 2:08:43 PM11/9/23
to
Hallo Gruppe,
ich habe hier ein Script, das ich gerne 3 mal im Monat starten möchte.
Also hab ich in die crontab folgendes eingetragen:
12 0 0,10,20 * * /home/ich/machwas.sh
Soweit ist alles gut. Jetzt ist es aber so, das dieses Script in der
Regel zwischen 5 und 7 Stunden Laufzeit hat. Bisher ist das Script noch
NIE zu Ende gelaufen. Das erste mal ist es mir nicht aufgefallen, aber
nach dem 2. mal hab ich gesucht.
Was ich gefunden habe:
Mein Status-log des Scripts hört einfach auf. Es gibt keinen Fehler und
somit auch keine fcron-Mail. In /var/log/messages sehe ich aber zu der
Zeit wo mein Script aufhört, dass Cron neu gestartet wurde.
Ist das der Grund warum mein Script sang und klanglos stirbt? Wenn ja,
gibt es eine Möglichkeit das Script trotzdem laufen zu lassen?
Ich hab schon Tante Google bemüht, aber scheinbar bin ich nicht in der
Lage ihr mein Problem richtig zu schildern um brauchbare Antworten zu
bekommen.
Danke schon mal für die Hilfe.
--
Gruß
Nelson
ich habe hier ein Script, das ich gerne 3 mal im Monat starten möchte.
Also hab ich in die crontab folgendes eingetragen:
12 0 0,10,20 * * /home/ich/machwas.sh
Soweit ist alles gut. Jetzt ist es aber so, das dieses Script in der
Regel zwischen 5 und 7 Stunden Laufzeit hat. Bisher ist das Script noch
NIE zu Ende gelaufen. Das erste mal ist es mir nicht aufgefallen, aber
nach dem 2. mal hab ich gesucht.
Was ich gefunden habe:
Mein Status-log des Scripts hört einfach auf. Es gibt keinen Fehler und
somit auch keine fcron-Mail. In /var/log/messages sehe ich aber zu der
Zeit wo mein Script aufhört, dass Cron neu gestartet wurde.
Ist das der Grund warum mein Script sang und klanglos stirbt? Wenn ja,
gibt es eine Möglichkeit das Script trotzdem laufen zu lassen?
Ich hab schon Tante Google bemüht, aber scheinbar bin ich nicht in der
Lage ihr mein Problem richtig zu schildern um brauchbare Antworten zu
bekommen.
Danke schon mal für die Hilfe.
--
Gruß
Nelson
Thomas
Nov 9, 2023, 2:48:29 PM11/9/23
to
Was bringt Ausprobieren? Einfach ein Script schreiben, das jede Sekunde
eine Zeile (mit Zähler) in eine Datei schriebt.
Das Script über die crontab starten und während das Script läuft cron
stoppen. Etwa über:
A) crond (Prozess für cron) per kill -9
B) Normal (die systemd-Kommandos oder sysV init routine)
Meine Erwartung ist, dass das Script einfach weiter läuft.
Wenn das Script weiter läuft, würde ich das logging in Deinem Script
erweitern.
Wenn das Script nicht weiter läuft, würde ich vermuten dass Dir
folgender Ansatz hilft:
* Du schreibst zwei Scripte
a) ein Starter-Script
b) das Worker-Script (das ist Dein jetziges mit langer Laufzeit)
* In der crontab trägst Du das Starter-Script ein
* Das Starter-Script hat nur die Aufgabe Dein Worker-Script *im
Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile wie:
*******************************************
Worker-Script &
*******************************************
Das &-Zeichen am Ende der Zeile sorgt dafür, dass für Dein Worker-Script
ein eigener Prozess gestartet wird, der auch dann weiter läuft, wenn das
Starter-Script beendet wird.
Gruß
Thomas
Alexander Bahlo
Nov 9, 2023, 4:16:03 PM11/9/23
to
Am Thu, 9 Nov 2023 20:08:38 +0100
schrieb Nelson Matias <nel...@anires.de>:
> 12 0 0,10,20 * * /home/ich/machwas.sh
Es soll also um 00:12 Uhr am Monats-0.?, 10. und 20. starten. Der
Monatsnullte ist mir allerdings ein Rätsel. :-)
> Soweit ist alles gut. Jetzt ist es aber so, das dieses Script in der
> Regel zwischen 5 und 7 Stunden Laufzeit hat. Bisher ist das Script noch
> NIE zu Ende gelaufen. Das erste mal ist es mir nicht aufgefallen, aber
> nach dem 2. mal hab ich gesucht.
Hast du es denn schon mal ohne Cron gestartet? Läuft es da
zufriedenstellend durch? Woran konntest du das feststellen?
Mach ein paar Ausgaben. Nach Stdout (das du dann ggf. umleitest) oder in
ein definiertes Logfile, das ist aber evtl. in Cron auch tricky, wenn du
Logfilerotate benutzt oder sonstiges (kann auch bei stdout tricky sein).
Ich würde es nicht sekündlich, minütlich oder stündlich machen, sondern
nach "Meilensteinen" dessen, was es abarbeiten soll und zuletzt daran,
woran du festmachst, das es fertig ist. Erst interaktiv, dann vielleicht
in einem nohup-Aufruf o.ä., dann in Cron.
Geht es um ein Script auf fli4l oder auf deinem Arbeitsplatz?
Gruß, Alexander.
schrieb Nelson Matias <nel...@anires.de>:
> 12 0 0,10,20 * * /home/ich/machwas.sh
Monatsnullte ist mir allerdings ein Rätsel. :-)
> Soweit ist alles gut. Jetzt ist es aber so, das dieses Script in der
> Regel zwischen 5 und 7 Stunden Laufzeit hat. Bisher ist das Script noch
> NIE zu Ende gelaufen. Das erste mal ist es mir nicht aufgefallen, aber
> nach dem 2. mal hab ich gesucht.
zufriedenstellend durch? Woran konntest du das feststellen?
Mach ein paar Ausgaben. Nach Stdout (das du dann ggf. umleitest) oder in
ein definiertes Logfile, das ist aber evtl. in Cron auch tricky, wenn du
Logfilerotate benutzt oder sonstiges (kann auch bei stdout tricky sein).
Ich würde es nicht sekündlich, minütlich oder stündlich machen, sondern
nach "Meilensteinen" dessen, was es abarbeiten soll und zuletzt daran,
woran du festmachst, das es fertig ist. Erst interaktiv, dann vielleicht
in einem nohup-Aufruf o.ä., dann in Cron.
Geht es um ein Script auf fli4l oder auf deinem Arbeitsplatz?
Gruß, Alexander.
Marcus Röckrath
Nov 9, 2023, 4:20:03 PM11/9/23
to
Hallo Thomas,
Thomas wrote:
> Was bringt Ausprobieren? Einfach ein Script schreiben, das jede Sekunde
> eine Zeile (mit Zähler) in eine Datei schriebt.
>
> Das Script über die crontab starten und während das Script läuft cron
> stoppen. Etwa über:
> A) crond (Prozess für cron) per kill -9
> B) Normal (die systemd-Kommandos oder sysV init routine)
>
> Meine Erwartung ist, dass das Script einfach weiter läuft.
Ich habe interessehalber das mal schnell auf dem eis getestet. Ein Restart
des fcron bricht die noch laufenden von fcron gestarteten Skripte ab.
> Wenn das Script nicht weiter läuft, würde ich vermuten dass Dir
> folgender Ansatz hilft:
> * Du schreibst zwei Scripte
> a) ein Starter-Script
> b) das Worker-Script (das ist Dein jetziges mit langer Laufzeit)
> * In der crontab trägst Du das Starter-Script ein
> * Das Starter-Script hat nur die Aufgabe Dein Worker-Script *im
> Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile
> wie: *******************************************
> Worker-Script &
> *******************************************
Probieren geht über studieren:
Und auch das stirbt.
--
Gruß Marcus
Thomas wrote:
> Was bringt Ausprobieren? Einfach ein Script schreiben, das jede Sekunde
> eine Zeile (mit Zähler) in eine Datei schriebt.
>
> Das Script über die crontab starten und während das Script läuft cron
> stoppen. Etwa über:
> A) crond (Prozess für cron) per kill -9
> B) Normal (die systemd-Kommandos oder sysV init routine)
>
> Meine Erwartung ist, dass das Script einfach weiter läuft.
des fcron bricht die noch laufenden von fcron gestarteten Skripte ab.
> Wenn das Script nicht weiter läuft, würde ich vermuten dass Dir
> folgender Ansatz hilft:
> * Du schreibst zwei Scripte
> a) ein Starter-Script
> b) das Worker-Script (das ist Dein jetziges mit langer Laufzeit)
> * In der crontab trägst Du das Starter-Script ein
> * Das Starter-Script hat nur die Aufgabe Dein Worker-Script *im
> Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile
> wie: *******************************************
> Worker-Script &
> *******************************************
Und auch das stirbt.
--
Gruß Marcus
Alexander Bahlo
Nov 9, 2023, 4:40:25 PM11/9/23
to Marcus Röckrath
Am Thu, 09 Nov 2023 22:09:36 +0100
schrieb Marcus Röckrath <marcus.r...@gmx.de>:
> > Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile
> > wie: *******************************************
> > Worker-Script &
> > *******************************************
>
> Probieren geht über studieren:
>
> Und auch das stirbt.
Ja klar. Damit es nicht stirbt, ist "nohup" erforderlich.
Also: "nohup worker.sh &".
--
Remark of Dr. Baldwin's concerning upstarts: We don't care to eat
toadstools that think they are truffles.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
schrieb Marcus Röckrath <marcus.r...@gmx.de>:
> > Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile
> > wie: *******************************************
> > Worker-Script &
> > *******************************************
>
> Probieren geht über studieren:
>
> Und auch das stirbt.
Also: "nohup worker.sh &".
--
Remark of Dr. Baldwin's concerning upstarts: We don't care to eat
toadstools that think they are truffles.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Kay Martinen
Nov 9, 2023, 5:40:02 PM11/9/23
to
Am 09.11.23 um 22:40 schrieb Alexander Bahlo:
2-3 laufzeiten des langen scripts per 'at' zu terminieren. Dann müsste
es egal sein ob cron läuft ob das script unter cron liefe...
Allerdings muß ich grade sagen habe ich keine Idee wodurch at-jobs
gestartet werden. Vermutlich von einem at-daemon aber aufgefallen ist
mir der auch noch nie.
Werden nicht bei den zertifikaten für mail u.a. at-jobs eingesetzt - wg.
deren längerer Laufzeit (x Wochen, Tage, Monate in der Zukunft).
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
> Am Thu, 09 Nov 2023 22:09:36 +0100
> schrieb Marcus Röckrath <marcus.r...@gmx.de>:
>
>>> Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile
>>> wie: *******************************************
>>> Worker-Script &
>>> *******************************************
>>
>> Probieren geht über studieren:
>>
>> Und auch das stirbt.
>
> Ja klar. Damit es nicht stirbt, ist "nohup" erforderlich.
> Also: "nohup worker.sh &".
Wäre es dann nicht einfacher per crontab z.b. am Ersten des Monats die
> schrieb Marcus Röckrath <marcus.r...@gmx.de>:
>
>>> Hintergrund* zu starten. Sprich im Starter-Script steht nur eine Zeile
>>> wie: *******************************************
>>> Worker-Script &
>>> *******************************************
>>
>> Probieren geht über studieren:
>>
>> Und auch das stirbt.
>
> Ja klar. Damit es nicht stirbt, ist "nohup" erforderlich.
> Also: "nohup worker.sh &".
2-3 laufzeiten des langen scripts per 'at' zu terminieren. Dann müsste
es egal sein ob cron läuft ob das script unter cron liefe...
Allerdings muß ich grade sagen habe ich keine Idee wodurch at-jobs
gestartet werden. Vermutlich von einem at-daemon aber aufgefallen ist
mir der auch noch nie.
Werden nicht bei den zertifikaten für mail u.a. at-jobs eingesetzt - wg.
deren längerer Laufzeit (x Wochen, Tage, Monate in der Zukunft).
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Alexander Bahlo
Nov 9, 2023, 6:58:23 PM11/9/23
to
Am Thu, 9 Nov 2023 23:30:57 +0100
schrieb Kay Martinen <use...@martinen.de>:
> Allerdings muß ich grade sagen habe ich keine Idee wodurch at-jobs
> gestartet werden. Vermutlich von einem at-daemon aber aufgefallen ist
> mir der auch noch nie.
atd, nunmehr oft unter /usr/sbin/atd.
Ausführbare Programme: at, batch, atq, atrm - queue, examine, or delete
jobs for later execution
--
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain
schrieb Kay Martinen <use...@martinen.de>:
> Allerdings muß ich grade sagen habe ich keine Idee wodurch at-jobs
> gestartet werden. Vermutlich von einem at-daemon aber aufgefallen ist
> mir der auch noch nie.
Ausführbare Programme: at, batch, atq, atrm - queue, examine, or delete
jobs for later execution
--
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain
Marcus Röckrath
Nov 10, 2023, 2:30:03 AM11/10/23
to
Hallo Kay,
Kay Martinen wrote:
> Allerdings muß ich grade sagen habe ich keine Idee wodurch at-jobs
> gestartet werden. Vermutlich von einem at-daemon aber aufgefallen ist
> mir der auch noch nie.
Wenn du das atd-Paket (Konfiguration steckt in System...| Job scheduler...)
nicht installiert oder aktiviert hast, gibts den bei dir auch nicht.
> Werden nicht bei den zertifikaten für mail u.a. at-jobs eingesetzt - wg.
> deren längerer Laufzeit (x Wochen, Tage, Monate in der Zukunft).
Nein, nicht wegen der Laufzeit, die ist nämlich in der Nutzung durch das
certs-Paket sehr kurz.
Das certs-Paket nutzt at-Jobs, weil die notwendige Startzeit von Zertifikat
zu Zertifikat unterschiedlich und variabel ist.
--
Gruß Marcus
Kay Martinen wrote:
> Allerdings muß ich grade sagen habe ich keine Idee wodurch at-jobs
> gestartet werden. Vermutlich von einem at-daemon aber aufgefallen ist
> mir der auch noch nie.
nicht installiert oder aktiviert hast, gibts den bei dir auch nicht.
> Werden nicht bei den zertifikaten für mail u.a. at-jobs eingesetzt - wg.
> deren längerer Laufzeit (x Wochen, Tage, Monate in der Zukunft).
certs-Paket sehr kurz.
Das certs-Paket nutzt at-Jobs, weil die notwendige Startzeit von Zertifikat
zu Zertifikat unterschiedlich und variabel ist.
--
Gruß Marcus
Marcus Röckrath
Nov 10, 2023, 2:40:03 AM11/10/23
to
Hallo Alexander,
Alexander Bahlo wrote:
>> Und auch das stirbt.
>
> Ja klar. Damit es nicht stirbt, ist "nohup" erforderlich.
> Also: "nohup worker.sh &".
Stirbt dennoch.
--
Gruß Marcus
Alexander Bahlo wrote:
>> Und auch das stirbt.
>
> Ja klar. Damit es nicht stirbt, ist "nohup" erforderlich.
> Also: "nohup worker.sh &".
--
Gruß Marcus
Alexander Bahlo
Nov 10, 2023, 7:40:28 AM11/10/23
to
Am 10.11.23 08:32, schrieb Marcus Röckrath:
Das finde ich allerdings sonderbar.
Nelson Matias
Nov 10, 2023, 3:04:41 PM11/10/23
to
Hallo Alexander,
Alexander Bahlo schrieb:
>> Soweit ist alles gut. Jetzt ist es aber so, das dieses Script in der
>> Regel zwischen 5 und 7 Stunden Laufzeit hat. Bisher ist das Script noch
>> NIE zu Ende gelaufen. Das erste mal ist es mir nicht aufgefallen, aber
>> nach dem 2. mal hab ich gesucht.
>
> Hast du es denn schon mal ohne Cron gestartet? Läuft es da
> zufriedenstellend durch? Woran konntest du das feststellen?
Ja. Das Script läuft so wunderbar. Es geht alle Verzeichnisse durch und
räumt dort auf. Die Laufzeit ist deshalb so lange, weil jede einzelne
Datei überprüft werden muss. Wird sie noch gebraucht, bleibt sie und es
wird das Backup überprüft. Wird sie nicht mehr gebraucht, dann wird sie
gelöscht und die Datei aus dem Backup ins Archiv verschoben. Das ganze
so ca. 400-450 -tausend mal. Für die Arbeit mit Cron hab ich die Ausgabe
entfärbt und in eine log-Datei umgeleitet. Daher habe ich den Abbruch
auch mitbekommen. Das log hört einfach mittendrin auf.
> Mach ein paar Ausgaben. Nach Stdout (das du dann ggf. umleitest) oder in
> ein definiertes Logfile, das ist aber evtl. in Cron auch tricky, wenn du
> Logfilerotate benutzt oder sonstiges (kann auch bei stdout tricky sein).
> Ich würde es nicht sekündlich, minütlich oder stündlich machen, sondern
> nach "Meilensteinen" dessen, was es abarbeiten soll und zuletzt daran,
> woran du festmachst, das es fertig ist. Erst interaktiv, dann vielleicht
> in einem nohup-Aufruf o.ä., dann in Cron.
>
> Geht es um ein Script auf fli4l oder auf deinem Arbeitsplatz?
Es geht um ein Script auf dem Eis. Da Markus schon so fleißig war und
deine Vorschläge schon getestet hat hab ich nun eine andere Idee.
Der Eis hat ja jetzt systemd ... kann mir jemand helfen für das Script
eine 'aufraeum.service' und die entsprechende 'aufraeum.timer' zu
basteln? Vielleicht geht das damit ja auch.
Mir fehlt leider zu viel Grundwissen über systemd um die Anleitungen
richtig zu verstehen.
Ach ja. Ich starte das Script über ein worker-Script weil ich ein paar
Argumente mit übergebe. Falls das für den systemd-service wichtig ist.
Ich kann aber auch den eigentlichen Aufruf in dem unit-File machen und
da den worker umgehen.
Danke zumindest schon mal zu meinem Problem.
--
Gruß
Nelson
Alexander Bahlo schrieb:
> Am Thu, 9 Nov 2023 20:08:38 +0100
> schrieb Nelson Matias <nel...@anires.de>:
>
>> 12 0 0,10,20 * * /home/ich/machwas.sh>
> Es soll also um 00:12 Uhr am Monats-0.?, 10. und 20. starten. Der
> Monatsnullte ist mir allerdings ein Rätsel. :-)
Danke. Ich habe das (vorerst) auf 1,11,21 geändert.
> schrieb Nelson Matias <nel...@anires.de>:
>
>> 12 0 0,10,20 * * /home/ich/machwas.sh>
> Es soll also um 00:12 Uhr am Monats-0.?, 10. und 20. starten. Der
> Monatsnullte ist mir allerdings ein Rätsel. :-)
>> Soweit ist alles gut. Jetzt ist es aber so, das dieses Script in der
>> Regel zwischen 5 und 7 Stunden Laufzeit hat. Bisher ist das Script noch
>> NIE zu Ende gelaufen. Das erste mal ist es mir nicht aufgefallen, aber
>> nach dem 2. mal hab ich gesucht.
>
> Hast du es denn schon mal ohne Cron gestartet? Läuft es da
> zufriedenstellend durch? Woran konntest du das feststellen?
räumt dort auf. Die Laufzeit ist deshalb so lange, weil jede einzelne
Datei überprüft werden muss. Wird sie noch gebraucht, bleibt sie und es
wird das Backup überprüft. Wird sie nicht mehr gebraucht, dann wird sie
gelöscht und die Datei aus dem Backup ins Archiv verschoben. Das ganze
so ca. 400-450 -tausend mal. Für die Arbeit mit Cron hab ich die Ausgabe
entfärbt und in eine log-Datei umgeleitet. Daher habe ich den Abbruch
auch mitbekommen. Das log hört einfach mittendrin auf.
> Mach ein paar Ausgaben. Nach Stdout (das du dann ggf. umleitest) oder in
> ein definiertes Logfile, das ist aber evtl. in Cron auch tricky, wenn du
> Logfilerotate benutzt oder sonstiges (kann auch bei stdout tricky sein).
> Ich würde es nicht sekündlich, minütlich oder stündlich machen, sondern
> nach "Meilensteinen" dessen, was es abarbeiten soll und zuletzt daran,
> woran du festmachst, das es fertig ist. Erst interaktiv, dann vielleicht
> in einem nohup-Aufruf o.ä., dann in Cron.
>
> Geht es um ein Script auf fli4l oder auf deinem Arbeitsplatz?
deine Vorschläge schon getestet hat hab ich nun eine andere Idee.
Der Eis hat ja jetzt systemd ... kann mir jemand helfen für das Script
eine 'aufraeum.service' und die entsprechende 'aufraeum.timer' zu
basteln? Vielleicht geht das damit ja auch.
Mir fehlt leider zu viel Grundwissen über systemd um die Anleitungen
richtig zu verstehen.
Ach ja. Ich starte das Script über ein worker-Script weil ich ein paar
Argumente mit übergebe. Falls das für den systemd-service wichtig ist.
Ich kann aber auch den eigentlichen Aufruf in dem unit-File machen und
da den worker umgehen.
Danke zumindest schon mal zu meinem Problem.
--
Gruß
Nelson
Marcus Röckrath
Nov 10, 2023, 4:10:03 PM11/10/23
to
Hallo Nelson,
Nelson Matias wrote:
>>> 12 0 0,10,20 * * /home/ich/machwas.sh>
>> Es soll also um 00:12 Uhr am Monats-0.?, 10. und 20. starten. Der
>> Monatsnullte ist mir allerdings ein Rätsel. :-)
>
> Danke. Ich habe das (vorerst) auf 1,11,21 geändert.
>>
> Der Eis hat ja jetzt systemd ... kann mir jemand helfen für das Script
> eine 'aufraeum.service' und die entsprechende 'aufraeum.timer' zu
> basteln? Vielleicht geht das damit ja auch.
> Mir fehlt leider zu viel Grundwissen über systemd um die Anleitungen
> richtig zu verstehen.
Ich würde mir an deiner Stelle mal in /usr/lib/systemd/system die *.timer
samt zugehöriger *.service anschauen.
Als OnCalender-String könnte ich mir bei Dir eventuell
1,11,21 *-*-* 00:12:00
vorstellen
> Ach ja. Ich starte das Script über ein worker-Script weil ich ein paar
> Argumente mit übergebe. Falls das für den systemd-service wichtig ist.
> Ich kann aber auch den eigentlichen Aufruf in dem unit-File machen und
> da den worker umgehen.
Du kannst bei ExeStart eine beliebige Komandozeile samt Optionen angeben.
--
Gruß Marcus
Nelson Matias wrote:
>>> 12 0 0,10,20 * * /home/ich/machwas.sh>
>> Es soll also um 00:12 Uhr am Monats-0.?, 10. und 20. starten. Der
>> Monatsnullte ist mir allerdings ein Rätsel. :-)
>
> Danke. Ich habe das (vorerst) auf 1,11,21 geändert.
>>
>> Geht es um ein Script auf fli4l oder auf deinem Arbeitsplatz?
>
> Es geht um ein Script auf dem Eis. Da Markus schon so fleißig war und
> deine Vorschläge schon getestet hat hab ich nun eine andere Idee.
aufgrund der NG hatte ich eher auf fli4l geschlossen.
>
> Es geht um ein Script auf dem Eis. Da Markus schon so fleißig war und
> deine Vorschläge schon getestet hat hab ich nun eine andere Idee.
> Der Eis hat ja jetzt systemd ... kann mir jemand helfen für das Script
> eine 'aufraeum.service' und die entsprechende 'aufraeum.timer' zu
> basteln? Vielleicht geht das damit ja auch.
> Mir fehlt leider zu viel Grundwissen über systemd um die Anleitungen
> richtig zu verstehen.
samt zugehöriger *.service anschauen.
Als OnCalender-String könnte ich mir bei Dir eventuell
1,11,21 *-*-* 00:12:00
vorstellen
> Ach ja. Ich starte das Script über ein worker-Script weil ich ein paar
> Argumente mit übergebe. Falls das für den systemd-service wichtig ist.
> Ich kann aber auch den eigentlichen Aufruf in dem unit-File machen und
> da den worker umgehen.
--
Gruß Marcus
Marcus Röckrath
Nov 10, 2023, 4:20:05 PM11/10/23
to
Hallo,
Marcus Röckrath wrote:
> Als OnCalender-String könnte ich mir bei Dir eventuell
>
> 1,11,21 *-*-* 00:12:00
Irrtum, eher so:
*-*-1,11,21 00:12:00
--
Gruß Marcus
Marcus Röckrath wrote:
> Als OnCalender-String könnte ich mir bei Dir eventuell
>
> 1,11,21 *-*-* 00:12:00
*-*-1,11,21 00:12:00
--
Gruß Marcus
Nelson Matias
Nov 12, 2023, 8:37:42 AM11/12/23
to
Hallo Marcus,
Marcus Röckrath schrieb:
durch neue Hardware ersetzt. Und seit dem läuft hier ein pfsense. Aber
ich bin nicht ganz zufrieden mit dm.
>> Der Eis hat ja jetzt systemd ... kann mir jemand helfen für das Script
>> eine 'aufraeum.service' und die entsprechende 'aufraeum.timer' zu
>> basteln? Vielleicht geht das damit ja auch.
>> Mir fehlt leider zu viel Grundwissen über systemd um die Anleitungen
>> richtig zu verstehen.
>
> Ich würde mir an deiner Stelle mal in /usr/lib/systemd/system die *.timer
> samt zugehöriger *.service anschauen.
>
> Als OnCalender-String könnte ich mir bei Dir eventuell
>
> 1,11,21 *-*-* 00:12:00
>
> vorstellen
Hier mal meine Versionen der Dateien:
--- SCHNIPP: cleaner.service ---
[Unit]
Description=Unit to clean the work-directories
[Service]
Type=oneshot
ExecStart=/home/ainex/clean-cron.sh 000 499
User=ainex
--- SCHNAPP ---
--- SCHNIPP: cleaner.timer ---
[Unit]
Description=Timer to start cleaner.service
[Timer]
OnCalendar=*-*-1,11,21 00:12:00
[Install]
WantedBy=timers.target
--- SCHNAPP ---
Ich hab ein zweites für 500 bis 999
Mein erster Test lief soweit super.
Aber gestern hab ich ich mir überlegt, dass dies ja still und leise im
Hintergrund läuft. Wenn ich jetzt den Server neu starte (wie zum
Kernelwechsel) dann wird das Script abgebrochen. Beim Neustart aber
nicht wieder gestartet.
Ich habe mir überlegt, dass ich meinen Fortschritt auf /tmp speichern
kann. Im Falle eines Neustarts könnte ich dann das Script neu starten
und auf /tmp nachschauen wie weit die Aktion gekommen ist und an der
Stelle weiter machen.
Jetzt meine Frage dazu: Muss ich noch ein paar *.timer/*.service Dateien
machen oder kann ich auch eine OnBootSec=15m in die bestehende
cleaner.timer ergänzen? Dann würde ich die Fortschrittsverwaltung ins
Script einbauen.
--
Gruß
Nelson
Marcus Röckrath schrieb:
>> Es geht um ein Script auf dem Eis. Da Markus schon so fleißig war und
>> deine Vorschläge schon getestet hat hab ich nun eine andere Idee.
>
> aufgrund der NG hatte ich eher auf fli4l geschlossen.
Meinen Fli4l hab ich leider vor 2 Jahren eingestellt. Der alte PC wurde
>> deine Vorschläge schon getestet hat hab ich nun eine andere Idee.
>
> aufgrund der NG hatte ich eher auf fli4l geschlossen.
durch neue Hardware ersetzt. Und seit dem läuft hier ein pfsense. Aber
ich bin nicht ganz zufrieden mit dm.
>> Der Eis hat ja jetzt systemd ... kann mir jemand helfen für das Script
>> eine 'aufraeum.service' und die entsprechende 'aufraeum.timer' zu
>> basteln? Vielleicht geht das damit ja auch.
>> Mir fehlt leider zu viel Grundwissen über systemd um die Anleitungen
>> richtig zu verstehen.
>
> Ich würde mir an deiner Stelle mal in /usr/lib/systemd/system die *.timer
> samt zugehöriger *.service anschauen.
>
> Als OnCalender-String könnte ich mir bei Dir eventuell
>
> 1,11,21 *-*-* 00:12:00
>
> vorstellen
--- SCHNIPP: cleaner.service ---
[Unit]
Description=Unit to clean the work-directories
[Service]
Type=oneshot
ExecStart=/home/ainex/clean-cron.sh 000 499
User=ainex
--- SCHNAPP ---
--- SCHNIPP: cleaner.timer ---
[Unit]
Description=Timer to start cleaner.service
[Timer]
OnCalendar=*-*-1,11,21 00:12:00
[Install]
WantedBy=timers.target
--- SCHNAPP ---
Ich hab ein zweites für 500 bis 999
Mein erster Test lief soweit super.
Aber gestern hab ich ich mir überlegt, dass dies ja still und leise im
Hintergrund läuft. Wenn ich jetzt den Server neu starte (wie zum
Kernelwechsel) dann wird das Script abgebrochen. Beim Neustart aber
nicht wieder gestartet.
Ich habe mir überlegt, dass ich meinen Fortschritt auf /tmp speichern
kann. Im Falle eines Neustarts könnte ich dann das Script neu starten
und auf /tmp nachschauen wie weit die Aktion gekommen ist und an der
Stelle weiter machen.
Jetzt meine Frage dazu: Muss ich noch ein paar *.timer/*.service Dateien
machen oder kann ich auch eine OnBootSec=15m in die bestehende
cleaner.timer ergänzen? Dann würde ich die Fortschrittsverwaltung ins
Script einbauen.
--
Gruß
Nelson
Marcus Röckrath
Nov 12, 2023, 2:00:03 PM11/12/23
to
Hallo Nelson,
Nelson Matias wrote:
Nelson Matias wrote:
> Mein erster Test lief soweit super.
>
> Aber gestern hab ich ich mir überlegt, dass dies ja still und leise im
> Hintergrund läuft.
Das ist bei zeitgesteuerten Jobs (auch bei fcron) so :-)).
>
> Aber gestern hab ich ich mir überlegt, dass dies ja still und leise im
> Hintergrund läuft.
> Wenn ich jetzt den Server neu starte (wie zum
> Kernelwechsel) dann wird das Script abgebrochen.
Systemreboot reagieren, sondern hart abgebrochen - je nachdem, was ein
Skript/Programm tun soll, kann das ja dann auch negative Effekte haben.
Ein Dienst, der so viele Stunden zu ackern hat, wäre mir als Dauerlösung
sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
kann.
Wenn du das nun auf zwei Durchläufe <500 >500 aufteilst, muss man natürlich
aufpassen, ob die notfalls auch parallel laufen können/dürfen, ohne sich
gegenseitig in die Quere zu kommen.
> Beim Neustart aber nicht wieder gestartet.
> Ich habe mir überlegt, dass ich meinen Fortschritt auf /tmp speichern
> kann. Im Falle eines Neustarts könnte ich dann das Script neu starten
> und auf /tmp nachschauen wie weit die Aktion gekommen ist und an der
> Stelle weiter machen.
> Jetzt meine Frage dazu: Muss ich noch ein paar *.timer/*.service Dateien
> machen oder kann ich auch eine OnBootSec=15m in die bestehende
> cleaner.timer ergänzen? Dann würde ich die Fortschrittsverwaltung ins
> Script einbauen.
früheren Boot abgebrochenen Job damit "zur Fortstzung zu bringen".
--
Gruß Marcus
Nelson Matias
Nov 13, 2023, 1:08:36 PM11/13/23
to
Hallo Marcus,
Marcus Röckrath schrieb:
Marcus Röckrath schrieb:
> Nelson Matias wrote:
>
>> Wenn ich jetzt den Server neu starte (wie zum
>> Kernelwechsel) dann wird das Script abgebrochen.
>
> Dein Skript wird wohl nicht selbst auf die "Stop"-Anforderung beim
> Systemreboot reagieren, sondern hart abgebrochen - je nachdem, was ein
> Skript/Programm tun soll, kann das ja dann auch negative Effekte haben.
>
> Ein Dienst, der so viele Stunden zu ackern hat, wäre mir als Dauerlösung
> sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
> kann.
Das Problem ist, das nicht alle Prozesse immer sauber angeschlossen
>
>> Wenn ich jetzt den Server neu starte (wie zum
>> Kernelwechsel) dann wird das Script abgebrochen.
>
> Dein Skript wird wohl nicht selbst auf die "Stop"-Anforderung beim
> Systemreboot reagieren, sondern hart abgebrochen - je nachdem, was ein
> Skript/Programm tun soll, kann das ja dann auch negative Effekte haben.
>
> Ein Dienst, der so viele Stunden zu ackern hat, wäre mir als Dauerlösung
> sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
> kann.
werden. Wenn mal eine Verbindung abbricht oder jemand vergisst sein
Projekt zu schließen bleiben Dateileichen stehen. Diese möchte ich auf
diese weise loswerden. Und weil ich das nicht händisch machen will läuft
das Script eben durch und muss dann alle denkbaren Fälle checken um
beurteilen zu können ob das weg kann oder nicht. Deshalb ist die
Kontrolle für jedes Verzeichnis bis zu 60 Sekunden.
Ein harter Abbruch ist kein Problem. Werden die Dateileichen beim
nächsten mal beseitigt. Entweder durch mein Script oder durch richtiges
Öffnen des Projekts mit anschließendem Schließen.
> Wenn du das nun auf zwei Durchläufe <500 >500 aufteilst, muss man natürlich
> aufpassen, ob die notfalls auch parallel laufen können/dürfen, ohne sich
> gegenseitig in die Quere zu kommen.
parallele Lauf beider Hälften ist kein Problem. Es wird ja nichts
bearbeitet sondern nur Daten abgefragt und wenn die Kriterien nicht
erfüllt sind die temporären Dateien gelöscht. Selbst wenn das Script im
Hintergrund läuft und ich das Script ein zweites mal starten sollte,
kann es theoretisch dazu kommen, dass das gleiche Verzeichnis von beiden
zeitgleich bearbeitet wird. Dann löscht das schnellere die Dateien und
beim anderen gibt es eine Fehlermeldung, das die Dateien nicht gelöscht
werden können weil nicht vorhanden. Wenn nichts gelöscht werden muss,
dann werden auch beide Scripte zum gleichen Ergebnis kommen und
weitermachen.
>> Beim Neustart aber nicht wieder gestartet.
>
> Hat der fcron das gemacht?
>> Ich habe mir überlegt, dass ich meinen Fortschritt auf /tmp speichern
>> kann. Im Falle eines Neustarts könnte ich dann das Script neu starten
>> und auf /tmp nachschauen wie weit die Aktion gekommen ist und an der
>> Stelle weiter machen.
>
> Denkbare Idee.
Script schreibt seinen Fortschritt nach /tmp/fortschritt.1 (oder das
andere in *.2). Das starter-Script überprüft ob es die entsprechende
Datei in /tmp findet und liest gegebenenfalls die zu übergebenden
Parameter daraus aus.
>> Jetzt meine Frage dazu: Muss ich noch ein paar *.timer/*.service Dateien
>> machen oder kann ich auch eine OnBootSec=15m in die bestehende
>> cleaner.timer ergänzen? Dann würde ich die Fortschrittsverwaltung ins
>> Script einbauen.
>
> Ich sehe nicht, wie man OnBootSec dazu benutzen kann, einen beim einem
> früheren Boot abgebrochenen Job damit "zur Fortstzung zu bringen".
im [Timer]-Abschnitt genannt werden. Somit habe ich jetzt auch
OnBootSec=15m drin und im starter-Script ja oben berichtete Abfrage.
Ergänzt habe ich jetzt auch, dass bei nicht vorhandener
Fortschritts-Datei die uptime mehr als 1h sein soll um dann das
Arbeitsscript normal zu starten. Ich kann ja keine unterschiedlichen
ExecStart-Zeilen für die unterschiedlichen Events verwenden, oder?
--
Gruß
Nelson
Marcus Röckrath
Nov 13, 2023, 1:30:04 PM11/13/23
to
Hallo Nelson,
Nelson Matias wrote:
Nelson Matias wrote:
>> Ein Dienst, der so viele Stunden zu ackern hat, wäre mir als Dauerlösung
>> sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
>> kann.
>
> Das Problem ist, das nicht alle Prozesse immer sauber angeschlossen
> werden. Wenn mal eine Verbindung abbricht oder jemand vergisst sein
> Projekt zu schließen bleiben Dateileichen stehen. Diese möchte ich auf
> diese weise loswerden.
Dateileichen kenne ich auch aus der Schule, da konnte ich nicht oft genug
>> sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
>> kann.
>
> Das Problem ist, das nicht alle Prozesse immer sauber angeschlossen
> werden. Wenn mal eine Verbindung abbricht oder jemand vergisst sein
> Projekt zu schließen bleiben Dateileichen stehen. Diese möchte ich auf
> diese weise loswerden.
daran erinnern, zumindest bei Dienstschluss allles zu beenden,
Dateileichen sollten dann aber doch einen Datumsstempel nach dem letzten
Lauf haben. Wenn man den Start des letzten Laufs speichert, könnte man doch
die Suche mittels find auf Dateien nach diesem Zeitpunkt einschränken.
> Und weil ich das nicht händisch machen will läuft
> Ich kann ja keine unterschiedlichen
> ExecStart-Zeilen für die unterschiedlichen Events verwenden, oder?
--
Gruß Marcus
Nelson Matias
Nov 13, 2023, 1:54:45 PM11/13/23
to
Hallo Marcus,
Marcus Röckrath schrieb:
Marcus Röckrath schrieb:
>>> Ein Dienst, der so viele Stunden zu ackern hat, wäre mir als Dauerlösung
>>> sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
>>> kann.
>>
>> Das Problem ist, das nicht alle Prozesse immer sauber angeschlossen
>> werden. Wenn mal eine Verbindung abbricht oder jemand vergisst sein
>> Projekt zu schließen bleiben Dateileichen stehen. Diese möchte ich auf
>> diese weise loswerden.
>
> Dateileichen kenne ich auch aus der Schule, da konnte ich nicht oft genug
> daran erinnern, zumindest bei Dienstschluss allles zu beenden,
Ja ... aber da gibt es noch eine anderes Problem ... geteilte PCs. Da
>>> sowieso suspekt und würde mal schauen, wie man das zeitlich optimieren
>>> kann.
>>
>> Das Problem ist, das nicht alle Prozesse immer sauber angeschlossen
>> werden. Wenn mal eine Verbindung abbricht oder jemand vergisst sein
>> Projekt zu schließen bleiben Dateileichen stehen. Diese möchte ich auf
>> diese weise loswerden.
>
> Dateileichen kenne ich auch aus der Schule, da konnte ich nicht oft genug
> daran erinnern, zumindest bei Dienstschluss allles zu beenden,
ist noch ein anderer Benutzer angemeldet aber es wird der Reboot
forciert weil Windows ja das Update machen will ... *Augenrollen*
> Dateileichen sollten dann aber doch einen Datumsstempel nach dem letzten
> Lauf haben. Wenn man den Start des letzten Laufs speichert, könnte man doch
> die Suche mittels find auf Dateien nach diesem Zeitpunkt einschränken.
gewollt, damit Zwischenstände gesichert sind. Sollte das System mal
abstürzen können so die eingegebenen Daten rekonstruiert werden.
Manchmal eben auch erst ein oder zwei oder auch 200 Tage später. Was
gäbe ich darum wenn es so einfach wäre ....
>> Und weil ich das nicht händisch machen will läuft
>
> Das kann ich verstehen, wäre zeitlich aussichtslos oder eine Lebensaufgabe.
>
>> Ich kann ja keine unterschiedlichen
>> ExecStart-Zeilen für die unterschiedlichen Events verwenden, oder?
>
> IMHO nein.
>
Zumindest hab ich ein wenig mehr über systemd gelernt.
--
Gruß
Nelson
0 new messages