Univention Bugzilla – Bug 49357
Do not use $HOME=/dev/null/ - Failed to open directory /dev/null
Last modified: 2022-04-26 09:29:16 CEST
The customer reported, that is deamon.log and therefor his device is filled with this log messages: Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.wants: Not a directory Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.requires: Not a directory Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.wants: Not a directory Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.requires: Not a directory Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.wants: Not a directory Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.requires: Not a directory Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.wants: Not a directory Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.requires: Not a directory We already have an article with a workaround but we should fix this in the product! https://help.univention.com/t/problem-journalctl-reports-errors-failed-to-open-directory-dev-null-config-systemd/11874
I have seen this too, many many lines of this in the syslog (mainly because samba logons, which also go through pam) I wonder if we should make pam_systemd optional (with the default not use it). If i recall correctly we have added this only for the ssh/reboot problem in our tests. see also Bug #49382
(In reply to Felix Botner from comment #1) > I wonder if we should make pam_systemd optional (with the default not use > it). "Do not shoot the messenger" - fix the underlying issue: The error is to use the *character device* "/dev/null" as a home *directory*. That was never right and you already get it when doing something like this: $ univention-ssh /etc/machine.secret $HOSTNAME\$@$HOSTNAME /bin/true Could not chdir to home directory /dev/null: Not a directory PS: Do NOT use a shared directory as that would just be a security problem.
Another customer has this problem. The syslog file for one day is about 1GB! Also it looks like a replication was failed as the LDAP server run into a timeout during writing to disk. We need to fix this.
(In reply to Dirk Schnick from comment #3) > Another customer has this problem. The syslog file for one day is about 1GB! > Also it looks like a replication was failed as the LDAP server run into a > timeout during writing to disk. We need to fix this. mhm, I don't think we should "blame" this bug if the replication fails, a system should be able to write 1GB log per day without breaking other services.
(In reply to Philipp Hahn from comment #2) > The error is to use the *character device* "/dev/null" as a home > *directory*. That was never right and you already get it when doing > something like this: > $ univention-ssh /etc/machine.secret $HOSTNAME\$@$HOSTNAME /bin/true > Could not chdir to home directory /dev/null: Not a directory > > PS: Do NOT use a shared directory as that would just be a security problem. If I understand correctly the $HOME of host accounts is /dev/null and leads to these messages / errors. Questions that come to my mind: * What is a proper $HOME for host accounts? /home/$HOSTNAME -> might conflict with usernames (no leading "$")? /home/.$HOSTNAME /home/hostaccounts/$HOSTNAME * are only accounts for UCS instances affected, or also Desktops (Windows, Ubuntu, ...)?
A normal syslogfile is not bigger than 1 GB per day. Also a very lot of entries are these mount wants home entries. As I have seen a lot of names I'm pretty sure windows client machines are affected.
Re: Comment 5: "/home/$(hostname)$" would be the canonical way. But it's not very nice. Another option may be the user runtime directory /run/user/$UID managed by pam_systemd root@primary20:~# su - primary20$ su: warning: cannot change directory to /dev/null: Ist kein Verzeichnis $ systemd-analyze --user unit-paths /dev/null/.config/systemd/user.control /dev/null/.config/systemd/user /etc/systemd/user /run/systemd/user /dev/null/.local/share/systemd/user /usr/local/share/systemd/user /usr/share/systemd/user /usr/local/lib/systemd/user /usr/lib/systemd/user Re: Comment 7: > As I have seen a lot of names I'm pretty sure windows client machines are affected. We should confirm that and see if we can find a different way to avoid this. Possibly this offers more potential to skip unnecessary steps.