[systemd-devel] automount expiry breaks further automounts (was Re: why does bootctl default to /boot and not to /boot/efi?)

[Mantas Mikulėnas]

On Wed, Jun 1, 2016 at 4:51 PM, Lennart Poettering <mzerqung at 0pointer.de>
wrote:

> On Wed, 01.06.16 09:15, Mantas Mikulėnas (grawity at gmail.com) wrote:
>
> > I'd buy into it if vfat weren't so brittle – several times I had to use
> > syslinux in /boot because the ESP lost *both* kernels I had in it...
> "sync;
> > sync; unmount; mount; check" was part of my kernel update ritual for a
> > while. Maybe it's the Linux driver, maybe it's my UEFI that's bad at
> FAT, I
> > dunno.
>
> Note that in today's systemd the ESP is automounted on request, and
> unmounting when idle. This means that the FAT partition is generally
> unmounted, except when you actually invoke bootctl. This should make
> access pretty safe. (of course, this only works if the efi mount
> generator actually does its job, it's not in effect if you explicit
> mount something else into /boot).


Testing this. Looks like once systemd has idle-unmounted something, it will
actually completely ignore further automount requests (they don't even show
up in the debug log) and I have to run "systemctl daemon-reexec" to unwedge
it... I suppose that's a bug in event handling somewhere.

Post-reexec, it logs this:

Jun 02 08:01:22 radius systemd[1]: Reexecuting.
Jun 02 08:01:22 radius systemd[1]: Failed to expire automount, ignoring:
Host is down
Jun 02 08:01:22 radius systemd[1]: tmp-autotest.automount: Got automount
request for /tmp/autotest, triggered by 24024 (touch)

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160602/09621524/attachment-0001.html>