Am 26.04.2015 um 14:12 schrieb Dmitry Katsubo: > On 26/04/2015 01:05, Michael Biebl wrote: >> Am 26.04.2015 um 00:36 schrieb Michael Biebl: >>> Am 26.04.2015 um 00:05 schrieb Dmitry Katsubo: >>>> >>>> Afterwards the process systemd opens a file in /var/run, thus >>>> not allowing me to unmount /var: >> >>>> systemd opens a file in /run, thus allowing the administrator >>>> to umount and e.g. repair /var volume. >> >>> According to codesearch [1], we have quite a few locations where >>> "/var/run/dbus/system_bus_socket" is hard-coded. >> >> >> After thinking about this some more, I'm actually not convinced >> this is a bug at all. /var/run/dbus/system_bus_socket is by far not >> the only resource, which could be openend from /var. >> >> In the end, I think it's rather questionable if it's a good idea to >> run fsck on a system partition in single user mode. And if you want >> to do so, you'll just need to shut down all services, sockets and >> processes manually, e.g. by running "systemctl stop foo.socket". >> >> If you want to run a forced fsck, there are much better facilities, >> like passing fsck.mode=force on the kernel-command-line [1]. >> >> Given this, I'm not sure if it's worth the effort to move the dbus >> socket around and I'm inclined to just close this bug report. >> >> I'll leave the decision to Simon though. >> >> Michael >> >> [1] man 8 systemd-fsck > > Michael, I agree that is not a bug but rather an improvement. "/run" > was introduced long time ago, and it is known to be tmpfs-mounted > system. Thus I think that using this path should be preferred over > "/var/run".
Sure, I was involved when we did the /run transition, and it should certainly be used wherever possible, especially for new software. The problem with /var/run/dbus/system_bus_socket is, that it's hard-coded in so many locations (as you can see on codesearch), one could even consider it ABI, that I'm worried that we might break quite a lot of stuff by changing it. Maybe my concerns are unfounded. I definitely want to hear Simon's opinion on this matter though. If he has no objection moving the socket, I'm fine with it. > Indeed other files could be opened from /var, but in single mode that > is very limited. The only service that lock it is NFS mount (rpcbind). > And I can always stop these services, thus allowing me to unmount > /var. But that is not the case with process with PID=1. Should I just > kill it? :) In that case, systemd was holding the socket *for* dbus. The way to release it, is to run systemctl stop dbus.socket -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature