Bug 728955

This bug causes the lvm2-monitor SysV init script to behave incorrectly because it relies on proper $runlevel variable to be set (to detect whether we're rebooting or shutting down or if this is just a user calling the script directly). See also bug #681582.

Also, when running the "runlevel" command directly either in command line or in the script (and trying to use its output), I sometimes get:

  [0] rawhide/~ # runlevel
  unkown

When running multiple times:

  [0] rawhide/~ # runlevel
  unknown
  [0] rawhide/~ # runlevel
  unknown
  [0] rawhide/~ # runlevel
  N 3

Sometimes, after a reboot, I always get the "N 3", sometimes I always get the "unknown". So it's quite nondeterministic and it can't be used either.

(In reply to comment #2)
> Also, when running the "runlevel" command directly either in command line or in
> the script (and trying to use its output)

(I haven't hit this problem with 'runlevel' command in F15 so far, only in rawhide.)

The runlevel information is written to utmp only after the boot completed. That means if you log in early (i.e. while some parts of the OS are still starting) and type in "runlevel" you will not have an runlevel information.

Hmm, then practically making it useless for use in legacy init scripts. Is there any alternative that could be used instead? (btw, the "runlevel" command is used in /etc/init.d/sshd init script as well in F15)

Would it be possible to set the $runlevel variable instead or is this deprecated totally?

The thing is that we do not really know anything like runlevels in systemd, and just have a very thin compat layer, mostly towards the user interface to support them.

Services should not rely on runlevels to be set, or that the machine is in a runlevel, since with systemd you can define arbitrary boot targets which might or might not respond with traditional SysV runlevels. If you check against these levels then you make your code incompatible with systems where these generic boot targets are used.

So inside a script, we can't decide whether we're rebooting/shutting down or in another "target" either? IOW, can we detect a reboot/shutdown target inside a script then? Or is this totally transparent to scripts?

No, you can't really detect this. Use command line arguments to your scripts to tell them whether they are called for starting or for stopping a service.

Well, thing is that we tried to discourage a user from stopping the service directly on command line unless a "force-stop" is called. However, it's OK for reboot and shutdown to call only the "stop" (and so we checked the $runlevel variable/runlevel output).

OK, it seems, that I'll just change the "stop" to be equal to "force-stop" as a quick patch for the problem reported in bug #681582 as it seems from what I'm reading here that we can't rely on runlevel info anymore and there's no alternative.

We already use systemd units in F16, this is just for legacy SysV init script we have in F15.

Sigh. At least I tried :)

There's RefuseManualStop= and RefuseManualStart=. If you set these you can make sure the user never can manually start/stop your service, unless this is done indirectly being pulled in by some other operation, such as a shutdown request.

See systemd.unit(5).

(In reply to comment #11)
> There's RefuseManualStop= and RefuseManualStart=. If you set these you can make
...
> 
> See systemd.unit(5).

But based on this: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript: 

"Packages are strictly forbidden from migrating to systemd within updates to a Fedora release. The migration is only allowed between Fedora releases."

I can't migrate to systemd when we still use SysV init script in F15 (unless we do an exception).

Anyway, thanks for the tip, I'll probably add that to existing lvm2 systemd units we already have in F16.