Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[6.12.3] /usr, /lib unmounting results in unavailable binaries for clean shutdown

  • Solved
  • Urgent

In previous versions of UNRAID the /usr and part of the /lib folder were a part of the root filesystem / and in the process were never unmounted because the root filesystem / persisted in RAM throughout the shutdown sequence in /etc/rc.d/rc.6. This also meant that all the binaries in /usr/sbin and /usr/local/sbin were available to the services until the system halted entirely, ensuring - for example - plugins could also run their respective shutdown sequences gracefully by utilizing their binaries in /usr/sbin (e.g. shutdown devices, stop their associated services etc.)

 

In newer versions of UNRAID (e.g. the latest 6.12.3) the /usr and entire /lib folder are no longer part of the root filesystem / and are unmounted being separate mount-points due to the mass-unmount-all command present early on in /etc/rc.d/rc.6:

 

# Unmount local file systems:
echo "Unmounting local file systems:"
/bin/umount -v -a

 

From that point on anything in the /usr and /lib folders becomes unavailable including anything in /usr/sbin or /usr/local/sbin, which is curious because the shutdown script actually proceeds to reference such an unavailable binary directly below that mass-unmount-all command:

 

# Unmount local file systems:
echo "Unmounting local file systems:"
/bin/umount -v -a

# limetech - shut down the unraid driver if started
if /bin/grep -qs 'mdState=STARTED' /proc/mdstat ; then
  echo "Stopping md/unraid driver:"
  /usr/local/sbin/mdcmd stop
  if ! /bin/grep -qs 'mdState=STOPPED' /proc/mdstat ; then
    echo "Unclean shutdown - Cannot stop md/unraid driver"
  else
    # we have to mount /boot again
    if ! /sbin/mount -v /boot ; then
      echo "Unclean shutdown - Cannot remount /boot"
    else
      /bin/rm -f /boot/config/forcesync
      /sbin/umount /boot
      echo "Clean shutdown"
    fi
  fi
fi

 

This if-clause will never be able to stop the md/unraid driver (if it is started), because the binary mdcmd at that point is already unmounted and unavailable due to the command above that if-close unmounting the entire /usr tree.

 

Another problem we're facing with this behaviour is - as an example - our NUT plugin (for UPS) being unable to shutdown the UPS inverter because the binary call to /usr/sbin/upsdrvctl is made impossible by the premature unmounting of /usr - see further details here:

 

I therefore propose the developers consider persisting the /usr and /lib mount-points until the system halts, as they should only be in RAM anyhow and their unmounting seems to be no requirement for a graceful shutdown but rather complicates such a graceful shutdown for both the plugins and the core system itself.

 

Perhaps reverting to either specifying which types of filesystems to unmount or which types of filesystems not to unmount utilizing umount -v -a -t instead of just umount -v -a could be considered, as it was done in earlier versions of UNRAID.

 

Overall, is unmounting the local filesystems on shutdown even necessary at all when they exist just in RAM?

 

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.