Le 06/03/2015 16:04, Michael Biebl a écrit :
Am 06.03.2015 um 10:10 schrieb Martin Pitt:
Control: found -1 215-12
Control: tag -1 confirmed
Ça va Didier,
Didier Roche [2015-03-06 9:36 +0100]:
In debian, tmp.mount is disabled through a distro-patch by default. It means
we don't want user's system to get /tmp on tmpfs without explicit enablement
(either by enabling tmp.mount unit or via fstab).
We noticed that starting an unit using "PrivateTmp=yes" will pull tmp.mount
(which mounts /tmp on tmpfs) in its requirements chain (even if this unit is
condition fail).
Confirmed. "systemctl start colord" or "systemd-timesyncd" will start
tmp.mount and thus overmount the existing /tmp in the running system.
I reproduced that in a clean sid VM (with LXDE, but I suppose that
doesn't matter much).
The odd thing though is, that PrivateTmp=yes does not trigger the start
of tmp.mount during boot at least on all the test systems I have.
Do we know, why that is? A Required=tmp.mount should always start the
referenced unit, but it seemingly doesn't.
For reference, I dig a little bit into it and asked on the upstream ML:
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029072.html
Let's see if the bug we are seeing is really due to tmp.mount not being
explicitly referenced anywhere.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
