[Bug 1983588] [NEW] update-motd-fsck-at-reboot stalls ssh logins for minutes if there is a slow/busy USB disk attached

Peter Maydell 1983588 at bugs.launchpad.net
Thu Aug 4 13:46:56 UTC 2022


Public bug reported:

I found recently that some ssh logins to my machine could stall for
minutes, and tracked this down to the update-motd-fsck-at-reboot hook.

Here's the relevant bit of 'ps wafux' output:

root     3659433  0.0  0.0  56920 14836 ?        Ss   14:29   0:00  \_ sshd: petmay01 [priv]
root     3659435  0.0  0.0   2608   592 ?        S    14:29   0:00      \_ sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
root     3659437  0.0  0.0   2496  1400 ?        S    14:29   0:00          \_ run-parts --lsbsysinit /etc/update-motd.d
root     3659488  0.0  0.0   2608  1824 ?        S    14:29   0:00              \_ /bin/sh /usr/lib/update-notifier/update-motd-fsck-at-reboot
root     3659535  0.0  0.0   3480   896 ?        D    14:29   0:00                  \_ dumpe2fs -h /dev/mapper/backup2

It's currently 14:40 and the 'dumpe2fs -h' has been stalled in the D
state for 10 minutes; the ssh login is blocked by this. (In fact, as I
was writing up this bug report the dumpe2fs finished at 14:42 and the
ssh login completed successfully.)

The 'backup2' disk, as the name suggests, is a backup disk, and it's an
external USB disk. The backups are currently running, so the disk is
currently busy doing a lot of I/O, which is why the dumpe2fs command
blocks for ages.

I think that anything like this that gets run during logins should not
be performing operations which could potentially take a long time to
complete. I don't know if there's some mechanism for identifying "fast
disks" and only looking at those.

The workaround is to add an "exit 0" to "/etc/update-motd.d/98-fsck-at-
reboot", disabling the hook.

This is with Ubuntu 20.04, and update-notifier-common version
3.192.30.11.

** Affects: update-notifier (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-notifier in Ubuntu.
https://bugs.launchpad.net/bugs/1983588

Title:
  update-motd-fsck-at-reboot stalls ssh logins for minutes if there is a
  slow/busy USB disk attached

Status in update-notifier package in Ubuntu:
  New

Bug description:
  I found recently that some ssh logins to my machine could stall for
  minutes, and tracked this down to the update-motd-fsck-at-reboot hook.

  Here's the relevant bit of 'ps wafux' output:

  root     3659433  0.0  0.0  56920 14836 ?        Ss   14:29   0:00  \_ sshd: petmay01 [priv]
  root     3659435  0.0  0.0   2608   592 ?        S    14:29   0:00      \_ sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
  root     3659437  0.0  0.0   2496  1400 ?        S    14:29   0:00          \_ run-parts --lsbsysinit /etc/update-motd.d
  root     3659488  0.0  0.0   2608  1824 ?        S    14:29   0:00              \_ /bin/sh /usr/lib/update-notifier/update-motd-fsck-at-reboot
  root     3659535  0.0  0.0   3480   896 ?        D    14:29   0:00                  \_ dumpe2fs -h /dev/mapper/backup2

  It's currently 14:40 and the 'dumpe2fs -h' has been stalled in the D
  state for 10 minutes; the ssh login is blocked by this. (In fact, as I
  was writing up this bug report the dumpe2fs finished at 14:42 and the
  ssh login completed successfully.)

  The 'backup2' disk, as the name suggests, is a backup disk, and it's
  an external USB disk. The backups are currently running, so the disk
  is currently busy doing a lot of I/O, which is why the dumpe2fs
  command blocks for ages.

  I think that anything like this that gets run during logins should not
  be performing operations which could potentially take a long time to
  complete. I don't know if there's some mechanism for identifying "fast
  disks" and only looking at those.

  The workaround is to add an "exit 0" to "/etc/update-motd.d/98-fsck-
  at-reboot", disabling the hook.

  This is with Ubuntu 20.04, and update-notifier-common version
  3.192.30.11.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1983588/+subscriptions




More information about the foundations-bugs mailing list