Bug 728955 - Systemd not setting the $runlevel variable for SysV init scripts
Systemd not setting the $runlevel variable for SysV init scripts
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
15
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-08 09:24 EDT by Peter Rajnoha
Modified: 2011-08-31 10:35 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-31 07:50:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Rajnoha 2011-08-08 09:24:08 EDT
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 09:27:21 EDT
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 05:26:18 EDT
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 05:31:19 EDT
(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 08:22:40 EDT
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 07:34:46 EDT
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 07:39:02 EDT
Would it be possible to set the $runlevel variable instead or is this deprecated totally?
Comment 7 Lennart Poettering 2011-08-29 10:56:09 EDT
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 07:26:51 EDT
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 19:26:59 EDT
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 07:50:59 EDT
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 09:21:33 EDT
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 10:33:42 EDT
(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 10:35:03 EDT
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.