kcron? Wo? Wie?

Hinweis: In dem Thema kcron? Wo? Wie? gibt es 26 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Kann man überhaupt mit kcron irgendwelche systemd -timer verwalten?

    nein
    Deswegen hab ich ja darauf verwiesen, dass du dir systemd.timers ansehen musst, wenn du die hauseigenen Timer der Opensuse-Installation bearbeiten möchtest.
    Fürs ansehen gibt es ui-Hilfsmittel (SystemdGenie) - zum Bearbeiten ist m.E. Handarbeit angesagt.

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 123843 haftet ausdrücklich der jeweilige Autor: wurzel99

  • Klare Antwort: Jain.


    Es sind zwei völlig verschiedene Welten.


    Das Cron- Subsystem stammt aus der SystemV Zeit.
    SystemV (sprich: System Fünf) war ein Unix von AT&T aus den 1980ern.
    Dessen Gene tragen heute mehr oder weniger alle Linuces.


    Es ist ähnlich dem System V Init- System
    Es gibt viele Verzeichnisse mit genau festgelegten Namen (cron.daily, cron.weekly usw.)
    Und dort gibt es für jeden Job ein entsprechendes File, was es natürlich für jeden User einmal gibt und einmal für das System.
    Ein Daemon klappert periodisch alles ab und startet dann die entsprechenden Jobs.
    Man muss sich dabei natürlich selber um so Kleinigkeiten kümmern, wie saubere Verteilung, dass nicht alle Jobs auf einmal gestartet werden usw.


    Bei Systemd wird ein Prozess gestartet (der unter Überwachung von systemd selbst läuft),
    der nur noch alle fälligen Jobs startet.
    Die zugehörigen Dateien sind für einen Job lediglich zwei:
    ein MeinService.service und ein MeinService.timer.
    Das sind kleine Konfigurationsdateien mit ein paar Zeilen.


    Das System ist viel flexibler und braucht auch weniger Ressourcen. Außerdem ist es __wirklich__ nebenläufig -im Gegensatz zu cron, das strukturell bedingt alle Jobs nacheinander abarbeiten muss.
    Jedem Job kann man bei Systemd-Timer sagen: laufe ungefähr jeden Tag um 15:00Uhr +/- 30min
    Damit werden Lastspitzen, um die man sich bei cron selbst kümmern muss- egalisiert. Systemd verteilt die Jobs dann nach Zufalls- und Erfahrungswerten, so dass die Systemlast möglichst gering bleibt.


    Systemd.timers sind dem Cron- System also weit überlegen. Kein Wunder: cron ist fast 40 Jahre alt, Systemd- Timer noch jung.


    Aber: Aus (dem heiligen) Kompatabilitätsgründen gibt es natürlich eine Systemd- Schicht, die die alten Cronjobs mitausführt.
    (Ich bin mir nicht sicher, glaube aber, dass cron einfach intern die Jobs an Systemd delegiert; müsste man jetzt im Quellcode nachlesen)
    Es sollen ja die Cronjobs von alten Daemons einfach weiter funktionieren.


    Die korrekte Antwort auf deine Frage wäre also:
    Nein, ganz sicher nicht, aber sehr eingeschränkt ein wenig, das aber nur sehr indirekt.


    Womit ich mich auf die Eriwan- Antwort festlege:
    Im Prinzip Nein.
    Aber, ein klitzeklein wenig hintenrum schon. Derzeit halt noch.


    Man könnte auch auf die völlig bescheurte Idee kommen, einen "echten" Systemd-Timer durch cron zusätzlich ausführen zu lassen.
    Der originale Systemd- Timer startet seine Jobs nur jedes gerade Mal seiner geplanten Ausführung
    und cron startet den Job jedes ungerade Mal.
    Womit natürlich dann doppelte Konfiguration fällig ist.


    Nimmt man nur kcron, steht dieser Weg in die Verwaltungshölle weit offen.
    Man will das ja selber regeln, und hat das ja schon immer so gemacht.
    Dös woar no nie ned so, des machma heid a ned, des brach ma ned.

  • Bei Systemd wird ein Prozess gestartet (der unter Überwachung von systemd selbst läuft),
    der nur noch alle fälligen Jobs startet.

    Bei Systemd wird ein Prozess gestartet. OK. Systemd ist in dem Fall wie ein Chef, der dem Prozess (dem Vorarbeiter) sagte was zu tun ist.
    Und der Prozess (der Vorarbeiter) startet dann die fälligen Jobs (die Handlanger in der Firma)
    Alles klar. Muss einem ja nur gesagt werden.
    Is ja wie inner Firma. :D


    Systemd.timers sind dem Cron- System also weit überlegen. Kein Wunder: cron ist fast 40 Jahre alt, Systemd- Timer noch jung.

    Auweia. So alt ist cron schon? Der gehört in Rente. Lass mal die jungen ran.
    Aber wenn die Cronjobs von alten Daemons weiter funktionieren sollen, darf cron nicht in Rente gehen.
    Es sei denn ... Ich glaube das schafft Systemd auch noch.


    Und da cron alle Jobs nacheinander abarbeitet und Systemd (mehr oder minder) alles parallel schafft, ist es wie in früheren Zeit mit dem Thema:
    Nehmen wir jetzt serielle oder parallele Abarbeitung? Jaja. Parallel ist schneller.
    Wir haben heute nicht umsonst mehrere Kerne in einer CPU.
    Ein Kern tut was und die anderen schauen zu wie der eine sich abrackert? Kommt gar nicht in die Tüte. X(

    PCFreddy

    Für den Inhalt des Beitrages 123845 haftet ausdrücklich der jeweilige Autor: pcfreddy

  • Er ist bekehrt!
    Er ist bekehrt!
    Er ist bekehrt!


    Halleluja!!!



    Es sei hinzugefügt, dass das alles parallel abgearbeitet werden _könnte_.
    Tatsächlich versucht der Daemon eine möglichst gleichmäßige Lastverteilung.
    Hintergrundjobs sollen ja möglichst wenig Ressourcen fressen.


    Versucht wird in diesem Fall das genaue Gegenteil(, das aber hochparallel!)

  • Tatsächlich versucht der Daemon eine möglichst gleichmäßige Lastverteilung.
    Hintergrundjobs sollen ja möglichst wenig Ressourcen fressen.

    Daher auch die vielen kleinen Häppchen (Scripte). Jaja.
    Hat man viele kleine Dinge zu tun, machts ersten mehr Spaß und zweitens ist man, wenn man die vielen kleinen Häppchen auf einige Leute aufteilt, schneller fertig.
    Und dann kommt noch der dritte Punkt ins Spiel, dass es auch etliche Arbeiten (Häppchen, Scripte) gibt die aufeinander warten.
    Jepp. Is gebont. Hach, is det schööön. Wie im wahren Leben, ohne Rückenschmerzen.

    PCFreddy

    Für den Inhalt des Beitrages 123847 haftet ausdrücklich der jeweilige Autor: pcfreddy