Bugzilla – Bug 940522
/tmp is mounted as tmpfs after 5 days uptime
Last modified: 2016-03-04 15:01:57 UTC
It happened second time now. /tmp was mounted as tmpfs after some days of uptime. I don't know what exactly mounted /tmp now, but it makes whole X defunct, because /tmp/xauth* gets hidden by the new mount. Therefore, I cannot run any new X app unless I unset XAUTHORITY in some older terminal.
Oh, I see now: srp 04 15:58:01 anemoi polkitd[1040]: Registered Authentication Agent for unix-process:29263:44895259 (system bus name :1.271 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/f srp 04 15:58:01 anemoi systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway. srp 04 15:58:01 anemoi systemd[1]: Mounting Temporary Directory... srp 04 15:58:01 anemoi systemd[1]: Mounted Temporary Directory. srp 04 15:58:01 anemoi systemd[1]: Starting OpenVPN tunneling daemon instance using /etc/openvpn/SUSE.conf... vpn start is the trigger.
(In reply to Jiri Slaby from comment #1) > vpn start is the trigger. VPN does not tweak any mounts. It is using systemd-ask-password to ask for a password and this triggers the mount as the log indicate. IMO as defined in /usr/lib/systemd/system/tmp.mount: [Unit] ConditionPathIsSymbolicLink=!/tmp [Mount] What=tmpfs Where=/tmp Type=tmpfs Options=mode=1777,strictatime On my leap system (no /tmp in fstab), /tmp is a dir on /-fs ...: # df -h /tmp Filesystem Size Used Avail Use% Mounted on /dev/sda2 15G 6.3G 7.7G 46% / not a link. So something seems fishy / inconsistent here.
Never seen that. There is a unit which does trigger this on your system. The question rises, how openvpm units look like?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779902
(In reply to Dr. Werner Fink from comment #4) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779902 Yes, that's it. openvpn@.service is using PrivateTmp=true: # cat /usr/lib/systemd/system/openvpn@.service [Unit] Description=OpenVPN tunneling daemon instance using /etc/openvpn/%I.conf After=network.target PartOf=openvpn.target [Service] Type=forking PrivateTmp=true PIDFile=/var/run/openvpn/%i.pid ExecStart=/usr/sbin/openvpn --daemon --suppress-timestamps --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf ExecReload=/sbin/killproc -p /var/run/openvpn/%i.pid -HUP /usr/sbin/openvpn [Install] WantedBy=multi-user.target openvpn.target
https://git.devuan.org/jaretcantu/eudev/commit/ddaae48b0be87f54ea12c56765b20d017cff2399 ... don't know why /var/tmp is not covered by this commit and also don't know how get a private name space now ... something like /private/tmp
(In reply to Jiri Slaby from comment #1) > Oh, I see now: > srp 04 15:58:01 anemoi polkitd[1040]: Registered Authentication Agent for > unix-process:29263:44895259 (system bus name :1.271 [/usr/bin/pkttyagent > --notify-fd 5 --fallback], object path /org/f > srp 04 15:58:01 anemoi systemd[1]: tmp.mount: Directory /tmp to mount over > is not empty, mounting anyway. > srp 04 15:58:01 anemoi systemd[1]: Mounting Temporary Directory... > srp 04 15:58:01 anemoi systemd[1]: Mounted Temporary Directory. > srp 04 15:58:01 anemoi systemd[1]: Starting OpenVPN tunneling daemon > instance using /etc/openvpn/SUSE.conf... > > vpn start is the trigger. It looks like /tmp is not a mountpoint by default on your system. Is this expected or did you expect systemd to setup a tmpfs automatically for you at boot ?
I think this one is a duplicate of bnc#949574: tmp.mount should be started during boot in any cases since it's required by basic.target unit unless tmp.mount is masked. What's not clear to me is why PrivateTmp=yes adds a "require" dependency explicitely on tmp.mount... it should be assumed to be started at boot through the 'basic.target'. @Jiri: until the fix done in bnc#949574 reaches TW, I suggest 2 workarounds: - if you want systemd to setup a tmpfs on /tmp automatically on boot you can force it with "systemctl add-requires basic.target tmp.mount". That's normally the default behaviour if /tmp is not defined in /etc/fstab. - if you don't want to mount anything on /tmp, you can "systemctl mask tmp.mount". The previous workaround still applies actually since it doesn't hurt and can be useful if you change your mind and want to use tmpfs.
(In reply to Franck Bui from comment #8) > I think this one is a duplicate of bnc#949574: tmp.mount should be started > during boot in any cases since it's required by basic.target unit unless > tmp.mount is masked. Yes, this makes sense IMO. > What's not clear to me is why PrivateTmp=yes adds a "require" dependency > explicitely on tmp.mount... it should be assumed to be started at boot > through the 'basic.target'. The patch referenced in comment 6 changes this to use After ordering only. I'd say, this patch is a workaround only. But I see an ExecContext there, which is not passed to the unit_require_mounts_for. PrivateTmp=yes is supposed to create a new fs namespace + mount [/var]/tmp _inside_ this namespace only. That is, tmp.mount should be IMO executed in this context only. I mean, _something_ like this: mount -o bind / .../openvpn@foo.service/root ... mount -t tmpfs tmpfs .../openvpn@foo.service/root/tmp mount -t tmpfs tmpfs .../openvpn@foo.service/root/var/tmp A look at https://github.com/systemd/systemd/blob/master/src/core/namespace.c shows, that there is a setup_namespace(), which seems to care about all this and is also setting the PRIVATE_TMP + PRIVATE_VAR_TMP mount flags ... > @Jiri: until the fix done in bnc#949574 reaches TW, I suggest 2 workarounds: > > - if you want systemd to setup a tmpfs on /tmp automatically on boot you > can force it with "systemctl add-requires basic.target tmp.mount". That's > normally the default behaviour if /tmp is not defined in /etc/fstab. > > - if you don't want to mount anything on /tmp, you can "systemctl mask > tmp.mount". The previous workaround still applies actually since it doesn't > hurt and can be useful if you change your mind and want to use tmpfs. Or also use /etc/systemd/system/openvpn@.service to override to PrivateTmp=no in until this issue is finally resolved.
(In reply to Marius Tomaschewski from comment #9) > > Or also use /etc/systemd/system/openvpn@.service to override to PrivateTmp=no > in until this issue is finally resolved. Well, as said earlier this one is a duplicate and should be considered as solved. The fix has been submitted to factory, not sure when it will reach TW though, release updates is still a mystery to me :) *** This bug has been marked as a duplicate of bug 949574 ***
WTF? I don't want systemd to mount /tmp as tmpfs at all. /tmp is on disk, was always on disk and has to be on disk on this very machine (due to memory limits).
(In reply to Dr. Werner Fink from comment #6) > https://git.devuan.org/jaretcantu/eudev/commit/ > ddaae48b0be87f54ea12c56765b20d017cff2399 > > ... don't know why /var/tmp is not covered by this commit and also don't > know how get a private name space now ... something like /private/tmp Yay, that looks like pretty exactly it. Is this going to be fixed upstream -- IIUC this is some private tree?
(In reply to Jiri Slaby from comment #11) > WTF? I don't want systemd to mount /tmp as tmpfs at all. /tmp is on disk, > was always on disk and has to be on disk on this very machine (due to memory > limits). If /tmp was on disk by default and we want to keep it here, then we can mask the tmp.mount unit by default.
(In reply to Jiri Slaby from comment #12) > (In reply to Dr. Werner Fink from comment #6) > > https://git.devuan.org/jaretcantu/eudev/commit/ > > ddaae48b0be87f54ea12c56765b20d017cff2399 > > > > ... don't know why /var/tmp is not covered by this commit and also don't > > know how get a private name space now ... something like /private/tmp > > Yay, that looks like pretty exactly it. Is this going to be fixed upstream > -- IIUC this is some private tree? I don't see how this can be related to your issue...
(In reply to Franck Bui from comment #14) > I don't see how this can be related to your issue... Avoid /tmp being mounted as tmpfs without the user's will Ensure PrivateTmp doesn't require tmpfs through tmp.mount, but rather adds an After relationship. AND (In reply to Jiri Slaby from comment #0) > It happened second time now. /tmp was mounted as tmpfs after some days of > uptime. I don't know what exactly mounted /tmp now, but it makes whole X > defunct, do not relate?
(In reply to Jiri Slaby from comment #15) > (In reply to Franck Bui from comment #14) > > I don't see how this can be related to your issue... > > Avoid /tmp being mounted as tmpfs without the user's will > > Ensure PrivateTmp doesn't require tmpfs through tmp.mount, but rather adds > an After relationship. > > AND > > (In reply to Jiri Slaby from comment #0) > > It happened second time now. /tmp was mounted as tmpfs after some days of > > uptime. I don't know what exactly mounted /tmp now, but it makes whole X > > defunct, > > do not relate? I was somehow thinking that you were replying on the last part of comment #6 (since you kept it in your reply). But now it's clear that you were commenting the debian's patch. Replacing Require= dep by only an After= ordering one for units using PrivateTmp=yes is not going to help, since /tmp may be required by many others paths (basic.target is pulling it). You can even have one unit explicitely requiring for tmp.mount. There're 2 issues: tmp.mount is not activated at boot (this is already fixed). /tmp is on disk by default on Suse system if not configured: if it's the case then tmp.mount should be masked by default.
(In reply to Franck Bui from comment #16) > There're 2 issues: tmp.mount is not activated at boot (this is already > fixed). /tmp is on disk by default on Suse system if not configured: if it's > the case then tmp.mount should be masked by default. And a PrivateTmp=yes should setup a new fs namespace for the service with some completely other private[/var]/tmp-fs [see comment #6, comment #9 with the setup_namespace() reference and systemd.exec(5) man page].
(In reply to Marius Tomaschewski from comment #17) > (In reply to Franck Bui from comment #16) > > There're 2 issues: tmp.mount is not activated at boot (this is already > > fixed). /tmp is on disk by default on Suse system if not configured: if it's > > the case then tmp.mount should be masked by default. > > And a PrivateTmp=yes should setup a new fs namespace for the service with > some completely other private[/var]/tmp-fs [see comment #6, comment #9 > with the setup_namespace() reference and systemd.exec(5) man page]. Hi Marius, I'm not sure to understand: are you saying that the current implementation of PrivateTmp=yes is broken ? AFAICS all happen already in exec_child() and setup_namespace() independently of the dep issue or am I missing your point ? Or do you have a test case that shows that PrivateTmp=yes doesn't follow what's described in systemd.exec(5) manpage ? In that case opening a new bug report may make sense.
tmp.mount has been removed from /usr/lib/systemd/system. A copy can be found in /usr/share/systemd/. This happened in Factory so I assume TW will be fixed soon or later too. So unless this unit was manually enabled by the user, it will be removed during the next update hence preventing its activation "by mistake".
This is fixed in current TW.