systemd erkennt [Timer] nicht

Krik

Fleet Admiral
Registriert
Juni 2005
Beiträge
15.019
Moin zusammen,

ich probiere mich gerade an dieser Anleitung aus: https://wiki.archlinux.org/title/Profile-sync-daemon
Kurz gesagt, ist das ein kleiner Dienst, der das Browser-Profil in eine RAM-Disk kopiert und regelmäßig mit der Festplatte synchronisiert.

Ich hänge an dem Punkt 4.1 Sync at more frequent intervals fest. Darin wird über den Befehl
systemctl --user edit psd.service --drop-in=frequency
die entsprechende Datei erzeugt und mit dem vorgegebenen Inhalt befüllt. Anschließend führe ich
systemctl --user daemon-reload
aus und lasse mir mit
systemctl --user status psd
ausgeben, ob er das geschluckt hat.

Hat er natürlich nicht 😡
Bash:
● psd.service - Timer for Profile-sync-daemon - 10min
     Loaded: loaded (/usr/lib/systemd/user/psd.service; enabled; preset: enabled)
    Drop-In: /home/krik/.config/systemd/user/psd.service.d
             └─frequency.conf
     Active: active (exited) since Sun 2025-01-12 14:26:05 CET; 6min ago
 Invocation: 24f2864cba274fb0ad15ad47247eb3f1
       Docs: man:psd(1)
             man:profile-sync-daemon(1)
             https://wiki.archlinux.org/index.php/Profile-sync-daemon
   Main PID: 20492 (code=exited, status=0/SUCCESS)
      Tasks: 8 (limit: 17606)
     Memory: 2.5M (peak: 3.6M)
        CPU: 113ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/psd.service
             ├─20513 /bin/bash /usr/bin/psd-suspend-sync
             ├─20514 gdbus monitor --system --dest org.freedesktop.login1
             ├─20516 systemd-inhibit --mode=delay --what=sleep --who=profile-sync-daemon "--why=psd resync on suspend" cat
             ├─20517 /bin/bash /usr/bin/psd-suspend-sync
             └─20525 cat

Jan 12 14:26:05 krax systemd[818]: Starting Profile-sync-daemon...
Jan 12 14:26:05 krax profile-sync-daemon[20492]: psd startup check successful
Jan 12 14:26:05 krax systemd[818]: Finished Profile-sync-daemon.
Jan 12 14:31:50 krax systemd[818]: /home/krik/.config/systemd/user/psd.service.d/frequency.conf:4: Unknown section 'Timer'. Ignoring.

Der Inhalt der frequency.conf ist einfach nur ein Copy'n'Paste aus der ArchWiki.
Code:
[Unit]
Description=Timer for Profile-sync-daemon - 10min

[Timer]
OnUnitActiveSec=
OnUnitActiveSec=10min

Ich weiß nicht, was sein Problem ist. Den [Timer]-Block sollte er auf alle Fälle erkennen.

Wisst ihr, was hier los ist?


System: CachyOS Handheld Edition on Steam Deck

Gruß
Krik
 
Timers are systemd unit files with a suffix of .timer. Timers are like other unit configuration files and are loaded from the same paths but include a [Timer] section which defines when and how the timer activates. Timers are defined as one of two types:
Die meinden das leider wort woertlich. Bin ich auch mal mit auf die Nase gefallen

Bei examples steht es auch nochmal:
A service unit file can be scheduled with a timer out-of-the-box. The following examples schedule foo.service to be run with a corresponding timer called foo.timer.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
@AlphaKaninchen
An der letzten Zeile im Log (man muss hier im Forum runterscrollen):
Bash:
Jan 12 14:31:50 krax systemd[818]: /home/krik/.config/systemd/user/psd.service.d/frequency.conf:4: Unknown section 'Timer'. Ignoring.
Edit: Du hast deinen Post nochmal bearbeitet. Bitte meinen Text hier ignorieren.

@madmax2010
Also kann man keinen Timer in einer .conf-Datei haben? Man muss explizit eine .timer-Datei verwenden? Habe ich das so richtig verstanden?
Ergänzung ()

Nachtrag:
Ich sehe gerade, dass ich mich vertan habe. Ich habe
systemctl --user edit psd.service --drop-in=frequency
statt
systemctl --user edit psd-resync.timer --drop-in=frequency
ausgeführt.

Dann erklärt sich auch der Fehler.


Also manchmal würde ich gerne...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: AlphaKaninchen
Krik schrieb:
Also kann man keinen Timer in einer .conf-Datei haben?
Genau wobei ich mir nicht sicher bin ob das drop in .timer oder das zu ersetzende .timer heißen muss.
Ergänzung ()

Krik schrieb:
Edit: Du hast deinen Post nochmal bearbeitet. Bitte meinen Text hier ignorieren.
Ich habe nix bearbeitet, habe den letzten Satz geschrieben weil psd.service und der Titel nicht zusammen passen, sowie um das von @madmax2010 zu unterstreichen. Die letzte Zeile im Log ist mir entgangen
 
Ich bin der Meinung, dass ich vor meinem Post die Zeile
AlphaKaninchen schrieb:
Aber der Timer sollte auch mit <Name>.timer benannt sein
nicht gesehen habe.
Deswegen habe ich erst mal alles an dich zurückgezogen, um noch mal neu zu schauen.


Der systemd-Befehl erzeugt von alleine die .conf-Endung. Wenn ich die Doku richtig verstanden habe, dann nimmt er die ursprüngliche unit und adaptiert nur die Änderungen aus den zugeordneten .conf-Dateien. Was dann in der .conf akzeptiert wird, hängt von der ursprünglichen unit ab.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
Krik schrieb:
Der systemd-Befehl erzeugt von alleine die .conf-Endung. Wenn ich die Doku richtig verstanden habe, dann nimmt er die ursprüngliche unit und adaptiert nur die Änderungen aus den zugeordneten .conf-Dateien. Was dann in der .conf akzeptiert wird, hängt von der ursprünglichen unit ab.
Ja, xyz.service und die xyz.timer sind ganz unterschiedliche units. Du kannst eine service unit nicht zu einer timer unit machen. Eine service unit ist immer eine service unit. In deinem edit Befehl steht doch auch schon psd.service!

Wenn du sagst ich will ich die xyz.service editieren (wie du es mit deinem systemctl --user edit xyz.service --drop-in=frequency command eben tust), dann kriegst du eine drop-in config /etc/systemd/system/xyz.service.d/frequency.conf. Also eine config die die xyz.service Unit ergänzt. Wenn du einen Timer haben willst musst du eine timer unit xyz.timer erstellen. Der Clou: Die timer unit triggered die gleichnamige .service unit. Die heißt dann also /etc/systemd/system/xyz.timer. Drop-ins für diesen Timer würden dann z.B. /etc/systemd/system/xyz.timer.d/frequency.conf heißen.

Warum sind das zwei verschiedene Units? Weil du den service ja auch unabhängig vom timer starten kannst.

systemctl enable xyz.service => Macht das was in der xyz.service unter [Install] steht (z.B. WantedBy=multi-user.target damit der Service bei jedem Systemstart startet)
systemctl start xyz.service => Startet den Service sofort. Unabhängig von irgendeinen Timer den es geben könnte der den Service vielleicht auch irgendwann mal triggert
systemctl enable xyz.timer => Macht das was in der xyz.timer unter [Install] steht (z.B. WantedBy=timers.target damit der Timer bei jedem Systemstart anfängt zu laufen)
systemctl start xyz.timer => Startet den Timer. Dadurch wird nicht zwangsläufig der Service gestartet! Der Service wird erst dann gestartet wenn der Timer triggered

Neben service und timer units gibt es auch noch andere spannende Unit Typen, die in der man page gelistet sind. Eine Erklärung dieser .target units findet sich auch in systemd.special(7) ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: madmax2010
Zurück
Oben