[systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
lennart at poettering.net
Wed Mar 4 06:41:37 PST 2015
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:
> >>>>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:
> >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
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
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
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
Yes, don't do this crazy overflow thing. And certainly don't assume
"disabling" is sufficient...
Lennart Poettering, Red Hat
More information about the systemd-devel