[Eisfair] [E64] exim: "systemd: Failed to resolve symlink /usr/local/share/systemd/user, ignoring: Permission denied"
Marcus Röckrath
marcus.roeckrath at gmx.de
Mo Nov 4 22:00:57 CET 2024
Hallo,
Marcus Röckrath wrote:
>> Dennoch habe ich ein "make DESTDIR=/tmp/cups install" ausgeführt und
>> finde jetzt in /tmp/cups die Unterverzeichnisse "etc" und "usr". Darüber
>> ein "grep -r /share/systemd" ausgeführt liefert kein Ergebnis.
>>
>> Suchen wir hier an der richtigen Stelle? Selbst wenn diese misslungene
>> Installation Ursache für den Fehler ist - wie stehen die hier gewonnenen
>> Dateien im Zusammenhang mit einem User-Login? Müssten wir nicht
>> eigentlich im Bereich systemd irgendwie fündig werden?
>
> Ich habe hier eine Situation erstellen können, die genau deine
> Fehlermeldung provoziert:
>
> Nov 4 21:42:58 eis systemd[7036]: Failed to resolve symlink
> /usr/local/share/systemd/user, ignoring: Permission denied
> Nov 4 21:42:58 eis systemd[7036]: Failed to open
> "/usr/local/share/systemd/user", ignoring: Permission denied
>
> Was habe ich getan?
>
> Das Verzeichnis /tmp/x angelegt.
>
> /usr/local/share/systemd/user als Symlink auf /tmp/x angelegt:
>
> ln -s /root/tmp/x /usr/local/share/systemd/user
Typo:
ln -s /tmp/x /usr/local/share/systemd/user
> /usr/local/share/systemd/user ist nicht das Ziel des Symlinks sondern es
> der Symlink, der in meinem Beispiel auf das Verzeichnis /tmp/x zeigt.
>
> Dann habe ich /tmp/x entfernt, so dass nun der Symlink ins Leere zeigt.
>
> Nun kommt, wenn der User exim aktiv wird, weil fetchmail pollt die obige
> Fehlermeldung.
>
> Ob das bei dir die Ursache ist, sagt das nicht, du hast ja auch schon
> gesagt, dass es /usr/local/share/systemd/user bei dir nicht gibt.
>
--
Gruß Marcus
[eisfair-Team]
Mehr Informationen über die Mailingliste Eisfair