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

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Entweder hat die Eigenkompilation und Installation von cups eine
>> Konfigurationsdatei verändert oder eine zusätzliche Konfigurationsdatei
>> hinterlassen, die dem Cups-Server sagt, schau bitte auch in /usr/local...
>> nach.
> 
> root at eis64-3 (usr)# grep -rniI "/usr/local/share/systemd" /etc/*
> root at eis64-3 (usr)# grep -rniI "/usr/local/share/systemd" /var/*
> ...liefert haufenweise Fundstellen in Logfiles
> root at eis64-3 (usr)# grep -rni "/usr/local/share/systemd" /usr/*
> /usr/bin/in.grep: /usr/lib/systemd/libsystemd-shared-251.so: binary file
> matches /usr/bin/in.grep: /usr/lib64/systemd/libsystemd-shared-253.so:
> binary file matches /usr/bin/in.grep:
> /usr/lib64/systemd/libsystemd-shared-254.so: binary file matches
> /usr/bin/in.grep: /usr/lib64/libsystemd.so.0.37.0: binary file matches
> 
/usr/share/pkgconfig/systemd.pc:44:systemd_user_unit_path=${systemd_user_conf_dir}:/etc/systemd/user:/run/systemd/user:/usr/local/lib/systemd/user:/usr/local/share/systemd/user:
${systemd_user_unit_dir}:/usr/lib/systemd/user:/usr/share/systemd/user
> 
> letzteres finde ich in gleicher Form auf allen meinen E64-Servern. Das
> kann also nicht die Ursache sein. Hat sich das am Ende in Binarys
> verankert? Wo/wie könnte ich noch suchen?

Das ist hier auch so und in Ordnung.

Wenn der fragliche Pfad nicht in einer Konfigurationsdatei steckt, könnte er 
auch ein Link auf dieses Verzeichnis sein; mach doch mal:

find /root/tmp -exec ls -l {} \; 2>/dev/null | grep 
"usr/local/share/systemd"

oder auch mit kürzerem Suchstring, z. B.:

find /root/tmp -exec ls -l {} \; 2>/dev/null | grep "share/systemd"

Eine Kompilieren von Cups verändert nicht die Binaries von systemd.

-- 
Gruß Marcus
[eisfair-Team]