[Eisfair] [E64] exim: "systemd: Failed to resolve symlink /usr/local/share/systemd/user, ignoring: Permission denied"

[Rolf Bensch]

Am 02.11.24 um 16:08 schrieb Marcus Röckrath:
> Hallo Rolf,
> 
> Rolf Bensch wrote:
> 
>>>>       grep ": (to exim) root on none" /var/log/messages
>>>>
>>>> liefert Ausgaben pünktlich alle 15 Minuten, vielfach ohne Zusammenhang
>>>> mit einer Attacke.
>>>
>>> Wie ist dein Mailabrufintervall im mail-Paket?
>>>
>>> FETCHMAIL_DAEMON
>>>
>>> Wenn da 900 drin steht, passt das zu den 15 Minuten.
>>
>> steht hier auf 900. War es aber nicht so, dass die 900 Sekunden erst am
>> Ende eines "fetch" starten und deshalb automatisch immer einer
>> Verschiebung eintritt?
> 
> Hier beispielhaft von meinem System, wobei bei den meisten Abrufen (von 4
> Konten) keine Mails da sind:
> 
> Nov  2 15:47:04 eis su[7707]: (to exim) root on none
> Nov  2 15:48:06 eis su[10272]: (to exim) root on none
> Nov  2 15:49:08 eis su[10525]: (to exim) root on none
> Nov  2 15:50:10 eis su[12943]: (to exim) root on none
> Nov  2 15:51:12 eis su[15510]: (to exim) root on none
> Nov  2 15:52:14 eis su[18071]: (to exim) root on none
> Nov  2 15:53:16 eis su[20632]: (to exim) root on none
> Nov  2 15:54:18 eis su[21276]: (to exim) root on none
> Nov  2 15:55:20 eis su[23281]: (to exim) root on none
> Nov  2 15:56:22 eis su[25848]: (to exim) root on none
> Nov  2 15:57:24 eis su[28414]: (to exim) root on none
> Nov  2 15:58:26 eis su[30959]: (to exim) root on none
> Nov  2 15:59:28 eis su[31988]: (to exim) root on none
> Nov  2 16:00:30 eis su[1279]: (to exim) root on none
> Nov  2 16:01:33 eis su[3828]: (to exim) root on none
> 
> Die Verschiebung ist natürlich da, aber in der Regel klein.
> 
> Ist die Verschiebung bei dir "0"? Bei wenigen (1?) Konten und ohne
> eingehende Mail kann das wohl auch sein.

Nach Prüfung: die Verschiebung ist nicht exakt 0 und entspricht ziemnlich genau den Aufzeichnungen in fetchmail.log. Die Wahrscheinlichkeit, dass der Mailabruf die Ursache ist, scheint sehr hoch zu sein.

> 
> Stell doch mal ein anderes Abrufintervall ein.
> 
>>> greppe doch mal mit dem dem String "usr/local" auf
>>>
>>> /etc/systemd und /usr/lib/systemd (hier Treffer in binären (Lib-)Files
>>> ignorieren.
>>
>>     root at eis64-3 (~)# grep -rl "/usr/local" /etc/systemd/*
>>       root at eis64-3 (~)# grep -rl "/usr/local" /usr/lib/systemd/*
>>     /usr/lib/systemd/libsystemd-core-251.so
>>     /usr/lib/systemd/libsystemd-shared-251.so
>>     /usr/lib/systemd/system/brute_force_blocking.service
>>     /usr/lib/systemd/system/systemd-confext.service
>>     /usr/lib/systemd/system/systemd-modules-load.service
>>     /usr/lib/systemd/system/systemd-binfmt.service
>>     /usr/lib/systemd/systemd
>>     /usr/lib/systemd/systemd-binfmt
>>     /usr/lib/systemd/systemd-modules-load
>>     /usr/lib/systemd/systemd-sysctl
>>     /usr/lib/systemd/systemd-sysupdate
>>     /usr/lib/systemd/systemd-timedated
>>     /usr/lib/systemd/systemd-udevd
>>     /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-
> generator
>>       root at eis64-3 (~)# grep -rln "/usr/local/share/systemd"
>>       /usr/lib/systemd/*
>>     /usr/lib/systemd/libsystemd-shared-251.so
>>
>> Hmmm, ich kann damit wenig anfangen.
> 
> Ich frage mich, wieso systemd. Suche mal in /run/systemd.

   root at eis64-3 (~)# grep -rln "/usr/local" /run/systemd/*
   /usr/bin/in.grep: /run/systemd/io.system.ManagedOOM: No such device or address
   /usr/bin/in.grep: /run/systemd/notify: No such device or address
   /usr/bin/in.grep: /run/systemd/private: No such device or address

Auch nix :-|

Grüße

Rolf