hi, I have a problem after the last system update to version ucs 4.4-0 errata11
in the logs, the system flushes the error
I’m already inserting
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.config/systemd/user/exit.target.wants: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.config/systemd/user/exit.target.requires: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.local/share/systemd/user/exit.target.wants: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.local/share/systemd/user/exit.target.requires: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.config/systemd/user/systemd-exit.service.wants: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.config/systemd/user/systemd-exit.service.requires: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.local/share/systemd/user/systemd-exit.service.wants: Not a directory
Mar 25 08:29:03 ucs systemd[13318]: Failed to open directory /dev/null/.local/share/systemd/user/systemd-exit.service.requires: Not a directory
could anyone direct me into the problem?
thank you in advance
@Christian_Voelker Update: This is most likely happening due to the system users in the ldap of Univention having a homeDirectory set to /dev/null and systemd user manager does not find further exit scripts in the given directory. The error happens for example for user 2022, which is a machine account for a dc backup. This may be no problem, can you confirm this CV?
Those errors can be safely ignored. Yes, they’re annoying, but they don’t affect functionality.
systemd is simply looking for optional service units to run whenever a user account logs in or out (“user” can also be a computer as both people and computers are handled similarly and both can log on & off). If those service units aren’t found, they’re not executed. As they’re completely optional, there’s no problem.
Basically this is a bug in systemd. Ideally it should not emit that message if the directory clearly doesn’t exist. My guess is that it checks for presence (but not type) of the home directory (which is /dev/null which does exist but isn’t a file) and then proceeds to try to open the directory beneath it. I don’t think it likely that this is something that would get fixed soon (someone would have to fix it in systemd if it wasn’t already, Univention would have to backport the fix to their own version of systemd and then maintain that fixed version — a lot of effort for something that’s solely a cosmetic issue).
As a workaround you could do the following (untested):
Create an empty directory, e.g. /var/lib/empty-dummy-home
Modify all accounts whose home directory is /dev/null so that their home directory becomes /var/lib/empty-dummy-home
You’ll have to do 2. each time a new account with home /dev/null is added. Mostly this affects computer accounts (not just for Windows clients or UCS servers but also when you install certain Apps that are Dockerized). See the output of getent passwd | grep /dev/null
My guess would be, that a change to
/etc/univention/templates/files/etc/systemd/journald.conf
(and subsequently to /etc/systemd/journald.conf) triggered this behaviour, since that seems to be the only file in the aforementioned packages that has to do with systemd.
