Bug 728955 - Systemd not setting the $runlevel variable for SysV init scripts
Summary: Systemd not setting the $runlevel variable for SysV init scripts
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-08 13:24 UTC by Peter Rajnoha
Modified: 2011-08-31 14:35 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-31 11:50:59 UTC


Attachments (Terms of Use)

Description Peter Rajnoha 2011-08-08 13:24:08 UTC
Description of problem:
Systemd does not set $runlevel variable for old sysvinit scripts (when running them in the sysvinit compatibility mode). For example, when rebooting or shutting down the machine, $runlevel should be set to 6 or 0 respectively.

Steps to Reproduce:
Use old SysV init script and test for the $runlevel variable during
shutdown or reboot.
  
Actual results:
$runlevel variable not set for old SysV init scripts.

Expected results:
$runlevel should be set since systemd claims to support old SysV init scripts.

Comment 1 Peter Rajnoha 2011-08-08 13:27:21 UTC
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.

Comment 2 Peter Rajnoha 2011-08-09 09:26:18 UTC
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.

Comment 3 Peter Rajnoha 2011-08-09 09:31:19 UTC
(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.)

Comment 4 Lennart Poettering 2011-08-21 12:22:40 UTC
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.

Comment 5 Peter Rajnoha 2011-08-25 11:34:46 UTC
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)

Comment 6 Peter Rajnoha 2011-08-25 11:39:02 UTC
Would it be possible to set the $runlevel variable instead or is this deprecated totally?

Comment 7 Lennart Poettering 2011-08-29 14:56:09 UTC
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.

Comment 8 Peter Rajnoha 2011-08-30 11:26:51 UTC
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?

Comment 9 Lennart Poettering 2011-08-30 23:26:59 UTC
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.

Comment 10 Peter Rajnoha 2011-08-31 11:50:59 UTC
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 :)

Comment 11 Lennart Poettering 2011-08-31 13:21:33 UTC
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).

Comment 12 Peter Rajnoha 2011-08-31 14:33:42 UTC
(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).

Comment 13 Peter Rajnoha 2011-08-31 14:35:03 UTC
Anyway, thanks for the tip, I'll probably add that to existing lvm2 systemd units we already have in F16.


Note You need to log in before you can comment on or make changes to this bug.