[systemd-devel] [systemd-219] Journal spamming by umount / high CPU usage

[Lennart Poettering]

On Thu, 02.04.15 11:11, Kai Krakow (hurikhan77 at gmail.com) wrote:

> Hi!
> 
> Lennart Poettering <lennart at poettering.net> schrieb am Do., 2. Apr. 2015 um
> 10:49 Uhr:
> 
> > On Sun, 29.03.15 17:12, Kai Krakow (hurikhan77 at gmail.com) wrote:
> >
> > > Hello!
> > >
> > > I've got a automount point for a daily USB backup job. Due to some
> > > instabilities of early USB3 chipsets and early USB3 devices, the mounted
> > > device sometimes wents offline and eventually comes back after a while
> > but
> > > my backup job is stuck (rsync). I configured rsync to shutdown upon
> > block io
> > > timeouts. This in turn makes the systemd automounter think (correctly)
> > that
> > > the mount point is no longer in use - but it cannot be unmounted. The
> > > problem here is, that it spams the journal with hundreds of messages per
> > > minute all day long (or as long as I don't reboot):
> >
> > Hmm? The systemd automount logic so far does not support mount
> > expiration, hence I cannot really parse what you write above?
> >
> 
> What exactly do you mean with "expiration"? Expiration by time or by
> usage?

"Expiration" is what the kernel autofs logic calls when a mount is
detected to be idle, and then after a timeout unmounted.

systemd does not support expiration right now. very recently there
have been posted patches to add this, but they have not been applied
yet, and hence on your system whatever you are running into is not
related to thus.

> To me it looks like the automounter tries to unmount unless there's still
> references open in the filesystem. It does, however, no try to do this
> after some timeout - which is fine. OTOH, this could be just an effect of
> the mount point forcibly vanishing because the USB device
> disconnected.

The kernel actually allows unmounting of mounts at any time, even if
the backing device has vanished. (In fact, it particularly allows
unmounting in that case...)

> 
> Maybe this is by kernel design? The filesystem forced itself read-only (due
> to IO errors to an offlined/disconnected device), then went offline. The
> kernel probably umounted it, and I believe that now another manual umount
> results in EPERM, tho I cannot test that now. I can test it this evening if
> it is of interested. I could also test other ideas to debug if you instruct
> me.

I am pretty sure there's something weird going on here. Any chance you
can boot with systemd.log_level=debug on the kernel cmdline, then
reproduce the issue and paste the output this generates here?

Lennart

-- 
Lennart Poettering, Red Hat