Home / server / Questions / 80912
In Process
quack quixote
Asked: 2009-11-04 04:08:16 +0800 CST

Understanding the Linux boot process, subsystem initialization, & udev rules?

  • 772

I'm creating UDEV rules for automounting external drives on a headless server, much in the same way as Gnome-VFS does automounting during a user session.

I'm concerned with the rule's behavior at boot-time. There's a good chance one of these drives will be connected during a boot, and I'd prefer any connected drives get mounted in the right place. The drives might be either USB or Firewire, and they are mounted from a shell script fired off by UDEV on detecting an "add".

Here are my questions:

  1. When UDEV runs the mount for these devices at boot, will the system be ready to mount it? Or will the script get triggered too early?

  2. If it's too early, what's a good way for a script to tell that the system isn't ready yet (so sleep a while before checking again)?

  3. The UDEV rule matches ACTION=="add". Does this event even fire at system boot?

linux

4 Answers

  1. Having just crammed up on udev to get USB stick to automount when not running a gui, (and not using autofs.)

    1. Yes veronica, udev does run awfully early.

      agent scripts can happily fork off and run after a sleep.

    2. udevadm settle might help you out here in addition to checking runlevel.

    3. action="Add" is run at boot, not just hotplug.

    Whether action="remove" is run at shutdown, now that's a fish of a different colour.

    • 2

  2. You're conflating two concepts. You should use UDEV to assign persistent device names to the drives that will be permanent no matter the order in which they are connected. You can then use the autofs to mount them on demand in the place(s) you want them to be available.

    • 1

  3. I don't think udev rules are the preferred solution for this. I think you would be much better served with autofs or maybe ivman once the system is booted, udev is a very low level at which to hook into and there are many tools built on top of it like Gnome-VFS in your post that are easier to use and manage. Ultimately you are concerned about mounting on access (i.e. autofs) and having predictable high level mechanisms to detect or respond to failure. If you work at the udev level you will have to address all of those concerns yourself, again.

    • 0

    1. No, UDEV will kick this script off (if at all) long before the system is ready for mounts; UDEV starts at /etc/rcS.d/S03udev, and standard fstab mounts happen at /etc/rcS.d/S35mountall.sh.

    2. Better than just guessing; check /bin/runlevel (thanks Brent & rh0dium):

      # at boot, system runs /etc/rcS.d/S* scripts, 
#                 then /etc/rcN.d/S* scripts, N is destination runlevel
# runlevel not set at least until we're running /etc/rcN.d scripts

RUNLEVEL=`/sbin/runlevel | cut -d " " -f 2`
until [ $RUNLEVEL -ge 1 ] && [ $RUNLEVEL -le 6 ]; do
      sleep 10
      RUNLEVEL=`/sbin/runlevel | cut -d " " -f 2`
done

## run the action i want here

    3. Not sure.

    • 0