1

This question is about a script which holds a lock to prevent multiple simultaneously executed instances of itself, which is executed at certain times by various processes and which sends reboot commands in certain situations.

Lets assume a reboot is requested and the script sleeps for some seconds (to prevent releasing the lock before the reboot kicks in). The script will then receive a signal and end itself (and by this, release the lock).

Question: Is there a possible time window, where this script is already stopped by the reboot event and still some other processes are running which manage to start the script again?

My personal feeling is that Linux systems first switch into some state in which execution of new processes is prevented in general, and after that running processes are halted. But this is only wishful thinking as I cannot find documentation about it.

Some clarifications:

a) It's not about the lock file not being removed properly. As I use flock, the lock is gone at that moment the script ends, even in case of crashes.

b) In most cases, script is started with root permissions by the at deamon.

1 Answer 1

0

Your personal feelings has some truth to it.

I won't go too much into details, but a linux boot process can be summarized as follows. (Subject to change, as init isn't always default anymore).

  1. The bootloader hands control over to the linux kernel and init.
  2. init then goes through its checklists and starts traversing its runmodes
  3. init goes into runlevel 1. This is also called Single User Mode, and this is where it starts the essential services for a functioning system. Only processes belonging to root can be started.
  4. init goes into runlevel 2. Similar to the above, but multiuser mode. Processes from other users join the party.
  5. Runlevel 3 initiates network.
  6. 4 is skipped (I never understood why. Perpetually reserved for future use I guess). init instead goes directly to 5, which is where xorg is started. Many userspace services (webservers, mail, etc etc) are commonly started here.

Now, to answer your question, I find it very unlikely that the script is able to start during the process of shutting down the system. If I remember correctly, it's not possible to launch new processes the normal way during this process. From what I understood, the main concern is that the script would start and leave a lockfile that'd be left during the reboot, thus preventing the script from ever running, am I correct? What I would do in this case is to have a small startup scrip, maybe on runlevel 3, that would delete this lockfile if found.

2
  • Thanks! I added some clarifications. It not about the lock being removed properly, its about the script is started again (by root) while another version has just been killed due to reboot.
    – philipp
    Jun 1, 2016 at 10:31
  • That's not really how runlevels work in SysVinit – at least, not the "regular" 2–5 ones. On most systems, they're not really "levels" but entirely separate modes, and a booting system goes straight to runlevel 5 after finishing the 'sysinit' script. (Or 2. Or 3. Often they have identical configurations.) Jun 1, 2016 at 11:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .