In both Debian 9 (stretch) and Debian 10 (buster), the process is started by the following two systemd timers:
(The anacron job /etc/cron.daily/apt-compat still exists, but exits if it detects systemd. Without systemd, it will run /usr/lib/apt/apt.systemd.daily without sub-command, which means both update and install. See other answers or anacron documentation on changing the schedule if you don't use systemd.)
The systemd timers can be set to trigger at a higher frequency, in your example every four hours, by overriding the default schedule. First, for updating the package list:
$ systemctl edit apt-daily.timer This creates /etc/systemd/system/apt-daily.timer.d/override.conf. Fill it as follows: [Timer] OnCalendar=*-*-* 0,4,8,12,16,20:00 RandomizedDelaySec=15m
Then, for the actual upgrades 20 minutes later:
$ systemctl edit apt-daily-upgrade.timer [Timer] OnCalendar=*-*-* 0,4,8,12,16,20:20 RandomizedDelaySec=1m
To check your work:
$ systemctl cat apt-daily{,-upgrade}.timer $ systemctl --all list-timers apt-daily{,-upgrade}.timer
(Taken partly from Debian Wiki: UnattendedUpgrades.)
Für ein reboot am selbigen Tag um 23:00 könnte man folgendes als root ausführen:
systemd-run --on-calendar '23:00' -- systemctl reboot
solche run units werden im RAM gespeichert und laufen periodisch so lange bis zum nächsten reboot. Also falls man sowas für einen job verwenden will der nur einmalig triggern sollte (und nicht durch ein reboot eh resettet), einfach das Datum als YYYY-MM-DD vor der Uhrzeit hängen, etwa:
systemd-run --on-calendar '2023-02-08 23:00' -- systemctl reboot
Bei der Suche nach Platz benutzt man dafür meistens „du -sh /*|grep G“ .
Irgendwann bei der Suche, stolpert man über die großen Mengen Speicherplatz die in /var/log verwendet werden und hier ist i.d.R. der Syslogd der Platzkiller. Nun will man natürlich auch ältere Logs haben, damit darin nach Fehlern suchen kann. Insofern ist es ok, wenn die Logs etwas größer sind. Damit man aber schnell mal 2 GB Platz auf der Platte für andere Sachen gewinnt, kann man z.b. folgende Befehle benutzen:
journalctl --vacuum-time=10d journalctl --vacuum-size=1G
Der erste Befehl löscht alle Logs, die älter als 10 Tage sind. Der zweite Befehl löscht alles weg, was mehr als 1 GB belegt. Ein 1 GB Log sollte für alle jüngeren Problemfälle reichen.
Jetzt könnte man die Größe des Logfiles in der Systemd Konfiguration dauerhaft hinterlegen, oder man nutzt den freien Platz nur temporär. Wenn man sich für letzteres entscheidet, darf man das Problem nicht auf die Lange Bank schieben, sondern sollte schnellstmöglich eine Entlastung der Platte durch Löschen anderer Daten herbeiführen.
Mit journalctl _SYSTEMD_INVOCATION_ID=$(systemctl show –value -p InvocationID ${unit}) kriegt man nur das Journal des aktuellen Starts der Unit. Funktioniert ab systemd 232.
Shell-Funktion mit
journalctl-current () { journalctl _SYSTEMD_INVOCATION_ID=$(systemctl show --value -p InvocationID $1) }
an entsprechender Stelle sourcen für einen Shortcut.