cron deinstallieren (aufgegeben)

[tobo]

anacron führt die Aufträge zum angegebenen Zeitpunkt durch oder holt Aufträge nach, die durch Ausschalten/Schlafenlegen verpasst wurden; wird also auf Desktops/Laptops etc. ausgeführt, die zwischenzeitlich augeschaltet werden.

Cron holt auch Cronjobs nach, die durch Suspend2RAM oder Suspend2Disk verpasst wurden.

[dasebastian]

Gar nicht, ...

Ja, nur dass die Frage nicht an dich gerichtet war, ... denn es geht um den nächsten "Trigger" (siehe oben).

Willst du mich hier abprüfen oder auf was soll das hier raus?

[GregorS]

Wie nötig ist cron auf einem Arbeits-PC mit bookworm?

Das kann ich nicht beurteilen. Ich halte cron aber für wesentlich wichtiger als z.B. logrotate.

logrotate verhindert, dass ich ohne „Hilfsmittel“ lesen kann, was z.B letztes Jahr um Weihnachten herum los war. Mit cron kann ich aber ziemlich nützliche Sachen anstellen: Ich logge z.B. minütlich ein paar Werte, um bei Bedarf ein Diagramm malen zu können, das den Verlauf dieser Werte über die Zeit zeigt. Oder ich lasse mir alle 10 Minuten ein neues „E-Mail-Signatur-Textchen“ erstellen.

Auf cron würde ich nicht verzichten. Zumal es systemlastmäßig eine ziemlich kleine Rolle spielt und kaum Plattenplatz braucht.

Gruß

Gregor

[fischig]

Mit cron kann ich aber ziemlich nützliche Sachen anstellen:

Ich selbst will mit cron (oder systemd-units in diesem Zusammenhang) eigentlich gar nichts anstellen. Und Anwender meiner Gehaltsklasse beschäftigen sich auch kaum mit sowas wie cron - denke ich.
Aber ich will darauf vertrauen, dass Debian mir nichts für meine Systeme Nutzloses installiert hat. Es geht nicht darum, Plattenplatz oder andere Resourcen mit einer Deinstallation einzusparen. Das wäre wohl bei diesen Programmen (cron/anacron) wirklich lächerlich.

Alles, was anacron macht, ist, einen Cronjob mitzubringen, der regelmäßig läuft und aufpasst, dass tägliche, wöchentliche oder monatliche Cronjobs auch (nachträglich) ausgeführt werden, wenn das System zu dem Zeitpunkt aus war.

Wenn ich jetzt mal JTH vertraue, dann wäre die Lösung wohl, anacron zusätzlich zu cron zu installieren, um sicherzustellen, dass die Aufgaben, die der Installer ohne mein Zutun in den diversen cron-Verzeichnissen unter/etc vorgesehen hat, auch ausgeführt werden.
cron allein würde das nur tun, wenn der Rechner ständig unter Debian liefe und anacron allein wäre völlig witzlos - richtig?
Letzter Auslöser meiner Frage war (u.a.!) dieser Thread: viewtopic.php?t=187541&hilit=anacron Und wenn ich selbst von einem Rechner ohne mein Zutun zu einem bestimmten zukünftigen Zeitpunkt etwas erledigt haben will, dann bastle ich mir selbst was mit at

[dasebastian]

Wenn ich jetzt mal JTH vertraue, dann wäre die Lösung wohl, anacron ...

Ich sehe das ähnlich. Oder du editierst deine /etc/crontab auf Zeitpunkte, wo der Rechner so gut wie sicher läuft - wenn es die gibt.

[tobo]

cron allein würde das nur tun, wenn der Rechner ständig unter Debian liefe und anacron allein wäre völlig witzlos - richtig?

Jein: a) du kannst die Cron-Zeiten in /etc/crontab anpassen (siehe dasebastian), und b) anacron hat unter SysVinit (oder hast du schon Systemd?) ein Init-Skript (/etc/init.d/anacron), welches ohne Cron auskommt. Aber, die einfache/gute Lösung ist natürlich beides zu installieren...

[fischig]

oder hast du schon Systemd?

Sowohl als auch, aber eher weniger (nur auf einer Maschine). Gut, da muss ich dann wohl unterschiedlich verfahren.

[tobo]

Naja, bestimmt gibt's da auch ein Systemd-Aquivalent, wenn es denn unbedingt sein muss...

[wanne]

Das Problem ist halt, dass seit Jahrzehnten Programme darauf vertrauen, dass cron vorhanden ist. Den einen Killer dürfte es nicht geben zumal alle größeren Projekte meist ihr eigenes Zeug haben oder auf Systemd umgestellt haben. Aber mir würde es auch mulmig werden irgend wo kann immer eine Kleinigkeit liegen, die es noch braucht und Auffallen wird das meist erst nache Jahren, da meistens nur Müll aufgeräumt wird oder eventuelle Fehler verbessert.

Mir bekannte Sachen:
Einige Hardware Monitore glauben regelmäßig Statistiken zusammen.
Raid checks laufen über cron. Wenn du ein Software RAID 6 hast, ist das ziemlich essentiell.
Bei der Installation kann man zustimmen, dass debian Statistiken sammeln darf, welche Software man installiert hat.
Automatische updates per apt-cron oder uanatended upgrades.
Aptitude caching => Wird langsamer, wenn man es raus wirft.
Locate-DB zum Dateien suchen. => Musst du sonst manuell machen, wenn du das nächste mal suchen willst. Sonst bekommst du veraltete Ergebnisse.
Aufräumen der man-DB (Sollte eigentlich von apt erledigt werden. Aber man wenn mal irgend wo abgebrochen wurde etc.)

Programme, die unter bookworm systemd timer als alternative haben.
Wenn logrotate mal nicht durch läuft ist das ziemlich Wurst. Aber über viele Jahre sammeln sich halt irgend wann die Gigabytes an.
ext4 und xfs haben bei SSDs aufgehört direkt beim löschen zu trimen. Stattdessen werden jetzt wöchentlich alle gelöschten Sachen auf einmal getrimt.
Ähnliches gilt für Dateisystemschecks die testen jetzt täglich ob der check älter als eine Woche ist und machen das dann. Wenn das weg fällt, wird es irgend wann beim booten gemacht.
Warnungen, dass es neue updates gibt in apt.
Backups für die dpkg-Datenbank

Alles sachen, die man nicht unbedingt immer braucht. Aber halt in manchen Szenarien sinnvoll sind.

[JTH]

cron allein würde das nur tun, wenn der Rechner ständig unter Debian liefe und anacron allein wäre völlig witzlos - richtig?

b) anacron hat unter SysVinit (oder hast du schon Systemd?) ein Init-Skript (/etc/init.d/anacron), welches ohne Cron auskommt.

Ja, das Initskript gibt es, aber nein, anacron kommt trotzdem nicht ohne cron aus. In besagtem Initskript steht sogar ausdrücklich:

The first purpose of this script is to run anacron at boot so that it can catch up with missed jobs. Note that anacron is not a daemon. It is run here just once and is later started by the real cron. The second purpose of this script is that said cron job invokes this script to start anacron at those subsequent times, to keep the logic in one place.

In /etc/cron.d/anacron wird anacron (das erwähnte Initskript) eben – durch cron – periodisch ausgeführt:

… /usr/sbin/invoke-rc.d anacron start …

Um auch nochmal Dokumentation zu zitieren:

Anacron itself however is not a daemon, so it will either be called at startup, on APM power status change, on systemd timer or by cron. Disabling those will result in some jobs not being executed on time.

Wenn ich jetzt mal JTH vertraue

… man darf mir gerne vertrauen, bei solchen Erklärungen schreib ich seltenst Unsinn

Naja, bestimmt gibt's da auch ein Systemd-Aquivalent, wenn es denn unbedingt sein muss...

Gut, da muss ich dann wohl unterschiedlich verfahren.

Dort, wo du systemd benutzt, würd ich cron & anacron wegschmeißen und einfach systemd-cron installieren. Das erfüllt den Zweck von beiden zusammen.

Sowieso: Für den Fall, dass systemd läuft, bringen die allermeisten Pakete eh inzwischen .timer-Dateien mit, das ist der systemd-native Cron-Ersatz. Dieser Ersatz hat von Haus aus eine anacron-äquivalente Funktionalität – wenn die jeweilige .timer-Datei das so gewünscht hat (per Persistent=yes).

[wanne]

Dort, wo du systemd benutzt, würd ich cron & anacron wegschmeißen und einfach systemd-cron installieren. Das erfüllt den Zweck von beiden zusammen.

Und 10 mal so komplex wie beide zusammen, da er mit 3 verschiedenen Syntaxen umgehen kann und diverse Zusatzfunktionalitäten hat.

[tobo]

cron allein würde das nur tun, wenn der Rechner ständig unter Debian liefe und anacron allein wäre völlig witzlos - richtig?

b) anacron hat unter SysVinit (oder hast du schon Systemd?) ein Init-Skript (/etc/init.d/anacron), welches ohne Cron auskommt.

Ja, das Initskript gibt es, aber nein, anacron kommt trotzdem nicht ohne cron aus.

Für das Skript an sich doch, allerdings nicht - und somit hast du natürlich recht - für den periodischen Teil.

[dasebastian]

... und 10 mal so komplex wie beide zusammen, da er mit 3 verschiedenen Syntaxen umgehen kann und diverse Zusatzfunktionalitäten hat.

Ist das positiv oder negativ gemeint? Oder kann man das (wie meistens) so einfach nicht sagen?

[thunder11]

Zu bedenken:
Beim Laptop läuft anacron nur, wenn das Netzteil angeschlossen ist.
Der anacron.service ist normalerweise nicht aktiviert.

Code: Alles auswählen

~$ cat     /lib/systemd/system/anacron.service
[Unit]
Description=Run anacron jobs
After=time-sync.target
# By default, anacron will not run when no AC power is connected to system.
# If you are using systemd and want to run anacron even when running on
# battery, you should create the following file with the specified content
# and then call "systemctl daemon-reload":
#    /etc/systemd/system/anacron.service.d/on-ac.conf:
#        [Unit]
#        ConditionACPower=
# See /usr/share/doc/anacron/README.Debian for detailed information.
ConditionACPower=true
Documentation=man:anacron man:anacrontab

[Service]
EnvironmentFile=/etc/default/anacron
ExecStart=/usr/sbin/anacron -d -q $ANACRON_ARGS
IgnoreSIGPIPE=false
KillMode=mixed
TimeoutStopSec=infinity

# Use SIGUSR1 to stop gracefully
KillSignal=SIGUSR1

[Install]
WantedBy=multi-user.target

Übrigens ist cockpit ein sehr nützliches Instrument für Systemd. Mir hilft es jedenfalls sehr, mich in Systemd zu orientierten.

[tobo]

Zu bedenken:
Beim Laptop läuft anacron nur, wenn das Netzteil angeschlossen ist.

Ist der default:

ANACRON_RUN_ON_BATTERY_POWER=no

[wanne]

Für das Skript an sich doch, allerdings nicht - und somit hast du natürlich recht - für den periodischen Teil.

Im Prinzip dürfte das vermutlich ziemlich harmlos sein, da so ein Arbeitspc oft genug neu gestartet wird, dass das ziemlich harmlos ist, wenn es halt beim nächsten Start passiert.

[fischig]

Im Prinzip dürfte das vermutlich ziemlich harmlos sein

Fazit also: nichts Genaues weiß man nicht. Hätte ich doch bloß nicht versucht, einen Sinn in diesem Chaos zu verstehen und zu händeln.
Ich rühr die Teile cron, anacron und - soweit es systemd betrifft - anacron.service nicht mehr an. cron entfernen kann ich nicht, nur durch anacron ersetzen. Wo was drauf oder nicht drauf ist, ist mir jetzt auch schon egal.

[dasebastian]

Fazit also: nichts Genaues weiß man nicht.

Naja, doch, schon. Cron kommt fertig eingerichtet zu dir und kümmert sich um "Kleinigkeiten", die sich zu Problemchen auswachsen könnten, wenn du dich nicht selber oder durch Umbau darum kümmerst. Anacron übernimmt diese Cronjobs, wenn der Rechner nicht regelmäßig bzw. zu fixen Zeiten läuft. Sofern installiert.

[Tintom]

Cron kommt fertig eingerichtet zu dir und kümmert sich um "Kleinigkeiten", die sich zu Problemchen auswachsen könnten, wenn du dich nicht selber oder durch Umbau darum kümmerst.

Wie passend. Das wäre eine schöne Paketbeschreibung

[dasebastian]

Danke, danke!

[rjh]

Substantielles kann ich zu der Frage auch nicht beitragen, aber grundsätzlich finde ich es eine gute Idee, das (noch) Vorhandensein bestimmter Programme überhaupt einmal zu hinterfragen. Hatte mir da bisher auch keine großen Gedanken gemacht, cron gehörte halt sozusagen schon "immer und ewig" zu einem unixartigen System dazu.

Hier an dem Notebook an dem ich gerade sitze, ist (mit Debian trixie) cron und anacron installiert, für cron wird anscheinend mit jedem hochfahren ein Prozess gestartet:

Code: Alles auswählen

# ps aux | grep cron
root        3473  0.0  0.0   6624  2560 ?        Ss   06:57   0:00 /usr/sbin/cron -f

Code: Alles auswählen

# journalctl -u cron.service
Aug 28 06:55:15 mbook systemd[1]: Started cron.service - Regular background program processing daemon.
Aug 28 06:55:15 mbook (cron)[613]: cron.service: Referenced but unset environment variable evaluates to an empty string: E>
Aug 28 06:55:15 mbook cron[613]: (CRON) INFO (pidfile fd = 3)
Aug 28 06:55:15 mbook cron[613]: (CRON) INFO (Running @reboot jobs)
Aug 28 06:57:17 mbook systemd[1]: Stopping cron.service - Regular background program processing daemon...
Aug 28 06:57:17 mbook systemd[1]: cron.service: Deactivated successfully.
Aug 28 06:57:17 mbook systemd[1]: Stopped cron.service - Regular background program processing daemon.
Aug 28 06:57:17 mbook systemd[1]: Started cron.service - Regular background program processing daemon.
Aug 28 06:57:17 mbook (cron)[3473]: cron.service: Referenced but unset environment variable evaluates to an empty string: >
Aug 28 06:57:17 mbook cron[3473]: (CRON) INFO (pidfile fd = 3)
Aug 28 06:57:18 mbook cron[3473]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
Aug 28 07:17:01 mbook CRON[3824]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Aug 28 07:17:01 mbook CRON[3825]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Aug 28 07:17:01 mbook CRON[3824]: pam_unix(cron:session): session closed for user root
Aug 28 07:30:01 mbook CRON[4623]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Aug 28 07:30:01 mbook CRON[4623]: pam_unix(cron:session): session closed for user root

Bei einem simulierten Entfernen der Pakete cron und anacron sehe ich jetzt zumindest auf den ersten Blick keine Widerstände:

Code: Alles auswählen

# apt remove cron anacron --simulate
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden Pakete werden ENTFERNT:
  anacron cron task-laptop
0 aktualisiert, 0 neu installiert, 3 zu entfernen und 0 nicht aktualisiert.
Remv task-laptop [3.73]
Remv anacron [2.3-38]
Remv cron [3.0pl1-173]

[dasebastian]

Bei einem simulierten Entfernen der Pakete cron und anacron sehe ich jetzt zumindest auf den ersten Blick keine Widerstände ...

Ist hier bei mir unter Bookworm das selbe, wenn ich das Purgen von task-laptop simuliere, gehen dann aber noch iw und powertop mit ab. Wie wichtig die wieder sind, keine Ahnung.

Ich mag mein Anacron ja, das leert mir meinen Mistkübel!

[uname]

Ich habe jetzt nicht alles gelesen. Aber ich denke cron stellt ein kleineres Problem dar, wenn es um unnötige Software unter Debian geht.

Mit dpigs (debian-goodies) kann man sich anschauen, was die größten Pakete sind. Am besten kann man auch zu Beginn minimal z. B. mit debootstrap oder grml-debootstrap (z. B. GRML Live) installieren und Recommends und Suggests weglassen. Steht auch unter https://wiki.debian.org/ReduceDebian als Tipp.