coding errors in update-motd-fsck-at-reboot script

Bug #1957863 reported by Ian! D. Allen
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
update-notifier (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

The script /usr/lib/update-notifier/update-motd-fsck-at-reboot contains some coding errors.
One of the errors hides the other error:

1. It sets two variables NEEDS_FSCK_CHECK and NEED_FSCK_CHECK (missing 'S') but only checks one of them (NEEDS_FSCK_CHECK). Because of this error, the script doesn't always initialize the value of NEEDS_FSCK_CHECK at the start of the script, so whatever value might happen to be passed in from the environment of the script could force a check even if the script would not itself do so.

Rename variable NEED_FSCK_CHECK to NEEDS_FSCK_CHECK and always run your Bourne shell scripts with the "-u" (check for undefined variables) option enabled: #!/bin/sh -u

2. It sets the variables with values "no" and "yes", but *any* value set in the variables means "yes". (It doesn't check that the value is actually "yes", so even "no" means "yes".) Because of coding error #1, this coding error #2 has no effect on the script operation, so if you fix coding error #1 without fixing this one, the script will incorrectly always run. You have to fix both.
Change:

    if [ -n "$NEEDS_FSCK_CHECK" ]; then

to actually check for a "yes":

    if [ "$NEEDS_FSCK_CHECK" = 'yes' ]; then

P.S. This script uses dumpe2fs that waits for all the disks on your system to spin up, which can significantly delay an ssh login to your system, as well as cause unnecessary wear on all your normally idle disks since the script seems to run frequently. If you don't like this behaviour (and don't need the fsck information it generates), you can render the script inactive by adding this line to /etc/crontab:

    01 * * * * root f=/var/lib/update-notifier/fsck-at-reboot ; test -e $f && touch $f

It would be nice if there were a cleaner way (perhaps something in /etc/default/?) to disable all this disk-spin-up activity, but that would be a different bug report.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: update-notifier-common 3.192.30.10
ProcVersionSignature: Ubuntu 5.11.0-46.51~20.04.1-generic 5.11.22
Uname: Linux 5.11.0-46-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Jan 13 23:40:37 2022
EcryptfsInUse: Yes
InstallationDate: Installed on 2020-10-07 (463 days ago)
InstallationMedia: Lubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
PackageArchitecture: all
SourcePackage: update-notifier
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.apt.apt.conf.d.10periodic: [modified]
mtime.conffile..etc.apt.apt.conf.d.10periodic: 2020-10-08T05:49:47.646282

Revision history for this message
Ian! D. Allen (idallen) wrote :
Revision history for this message
madigal (osse7) wrote :

Wonder if Brian is able to test its own fine art coding style !!! An other coding style is about 'apport' too, with its redundant popping boxes (what a mess)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in update-notifier (Ubuntu):
status: New → Confirmed
Revision history for this message
Brendan Lewis (sirblew) wrote :

This bug has still not been fixed in 22.04 as of 13/12/2022.

I run Ubuntu on a SSD and mount four spindle drives in a RAID 5. So, this bug wakes up my RAID array every time I SSH in. The workaround suggested here causes wear on the SSD. So, unless I completely disable this script or fix the bug myself, I'm faced with a choice of it either causing wear and tear on my spindle drives or wear and tear on my SSD.

I'm sure I'm not the only one with this problem and I wonder how many spindle drives around the world are being unnecessarily woken up by this easily fixable bug.

tags: added: rls-jj-incoming
Lukas Märdian (slyon)
tags: removed: rls-jj-incoming
Revision history for this message
Brendan Lewis (sirblew) wrote :

While this bug still exists I've enabled a workaround. I only want to know about fsck checks when the system boots, not when I SSH in. So I disable the fsck checks for interactive logins by adding the following to to the top of /usr/lib/update-notifier/update-motd-fsck-at-reboot.

# Disable if interactive user login to avoid spinning up drives on login
tty -s && exit

tags: added: desktop-lts-wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.