[systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Lennart Poettering]

On Wed, 04.03.15 15:25, Didier Roche (didrocks at ubuntu.com) wrote:

> Le 04/03/2015 13:40, Lennart Poettering a écrit :
> >On Wed, 04.03.15 13:19, Didier Roche (didrocks at ubuntu.com) wrote:
> >
> >>Le 04/03/2015 12:49, Lennart Poettering a écrit :
> >>>On Wed, 04.03.15 09:21, Didier Roche (didrocks at ubuntu.com) wrote:
> >>>
> >>>>Hey,
> >>>>
> >>>>It seems that we discovered an issue if a service declares some relationship
> >>>>with a .mount unit.
> >>>>For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
> >>>>in fstab):
> >>>tmp.mount is enabled statically via the
> >>>/usr/lib/systemd/system/local-fs.target.wants/tmp.mount symlink.
> >>We have a distro-patched in debian to remove this symlink. Note that
> >>otherwise, it wouldn't be started only on some boots and not on others,
> >>which shows that there is an erratic behavior.
> >Well, it's affected by jobs later queued in. You are using "Conflicts"
> >against the unit, apparently. Now, conflicts has different effects for
> >later queued jobs. depending on the "mode" setting the conflicting job
> >is either removed, or the unit stopped or the job fails.
> >
> >>>Use "systemctl show tmp.mount" to see by which dependencies it was
> >>>pulled in.
> >>Nice hint! So, on boots where tmp.mount is enabled, here is what systemctl
> >>show on the unit gives:
> >>RequiredBy=systemd-timesyncd.service
> >>Conflicts=umount.target
> >>ConflictedBy=foo.service
> >What is this ConflictedBy actually about? Why?
> >
> >Ihave the suspicion you assume conflicts= has different behaviour that
> >it actually means.
> 
> Ok, giving a little bit more context. So, we don't enable /tmp on tmpfs in
> debian/ubuntu (the symlink is removed as a distro patch). 

Well, just removing the symlink is kinda pointless. It might still be pulled
in by anything else that implicitly depepends on /tmp. 

There are two ways to disable tmp-on-tmpfs: 

a) mask it
b) override it by adding an explicit mount for it in /etc/fstab

Also see:

https://fedoraproject.org/wiki/Features/tmp-on-tmpfs#Release_Notes

Just disabling it is a pointless excercise.

> We had with
> sysvinit and upstart a failsafe mechanism if / is nearly full:
> in that case /tmp is mounted as tmpfs and marked as "overflow" (some scripts
> in ubuntu looks for that name and warn the user), trying to boot the system
> as far as we can. The idea was to recreate this functionality under systemd
> (bug:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1392637).

Frankly, that sounds like a crazy idea. 

My recommendation would be to default to /tmp-on-tmpfs and be done
with it. We have been defaulting to this since 3 years now in
Fedora. Everything that broke in this case should be fixed by now...

Such an automatism is really weird, since you cannot really replace
/tmp during runtime, and in what is this worth if you have to reboot
first?

Such a behaviour is really hard to grok for users, and the execution
environment changes in weird ways depending on non-obvious criteria.

THis just adds complexity for no good purpsoe...

> * I was first proposing a generator for that: https://launchpadlibrarian.net/199267346/0001-Add-systemd-emergency-tmpfs-to-force-tmpfs-on-tmp.patch
> which would enable unconditionally (even if manually enabled by the
> sysadmin) the tmp.mount unit and add the "overflow" tag.
> * Martin (see bug comments) thinks that the check is too early (on the ro
> filesystem as our root filesystem is mounted as read only) and maybe there
> is a fstab mount for /tmp with more spaces. There is also the issue that we
> are maybe on permanent read only images (like with snappy) and so, no free
> space, (and then /tmp would be mounted as tmpfs via enabling tmp.mount, but
> we don't want to mark is as "overflow").
> * For those reasons, we tried  to rather go with a service started later at
> boot time doing that check. I tried to do a quick one:
> http://paste.ubuntu.com/10523961/, and that's where we started to see
> tmp.mount being activated at some boots, and not on others (which triggered
> that email).
> 
> Any suggestion on how we should tackle this? (I don't really like the
> additional service approach and way more prefer the first declarative
> approach).

Yes, don't do this crazy overflow thing. And certainly don't assume
"disabling" is sufficient...

Lennart

-- 
Lennart Poettering, Red Hat