Bug#783321: systemd opens file in /var/run and not in /run

[Michael Biebl]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150426/2ebb4be8/attachment-0002.sig>