On Wed, 04.03.15 15:25, Didier Roche (didro...@ubuntu.com) wrote: > Le 04/03/2015 13:40, Lennart Poettering a écrit : > >On Wed, 04.03.15 13:19, Didier Roche (didro...@ubuntu.com) wrote: > > > >>Le 04/03/2015 12:49, Lennart Poettering a écrit : > >>>On Wed, 04.03.15 09:21, Didier Roche (didro...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
