2

I'm working on a script that is supposed to execute on startup, but the problem is that the script requires some files that are on a shared drive that is automatically mounted via fstab and at the time of it's execution the drive isn't mounted yet.

I've tried using cron @reboot and init.d route but they both execute too early. I also considered adding mount -a to the script, but I would rather avoid having to sudo it. For now I just added a delay to make it work, but that feels a bit hacky.

Is there a way to ensure that a startup script runs after fstab has been processed? Or force the mounts to be processed without using sudo?

Maxim
  • 728
  • You are using Ubuntu, an operating system that has been a systemd operating system since 2016 and was an Upstart operating system for a decade before that, since 2006. van Smoorenburg rc scripts have not been a "route" for a long time on your operating system. The systemd version of this question has already been asked and answered here at https://unix.stackexchange.com/questions/246935/ . – JdeBP Jul 19 '18 at 15:38

2 Answers2

3

For that you have to run your script as a systemd unit (assuming you have systemd) where you could define dependency...

If you want to stick with cron @reboot (what sounds the simple choice) you have to make your script a bit smarter (or start cron after fs mounts... what change I wouldn't suggest). Instead of a simple delay, you can check if the required filesystem is mounted (in bash):

while ! mount | awk '{print $3}' | grep -qx /the/mountpoint; do
    sleep 1
done

Or you can check if the file is there what you need:

while ! [ -f /that/file ] ; do
    sleep 1
done
redseven
  • 592
0

I'm going to assume you're on a relatively new Linux distro, so you may need to check systemd manual since SysV is no longer being used in the default distro installations and that is most probably your problem. systemd allows for startup dependencies where you specify what scripts run before others.

Check the next link

YoMismo
  • 4,015