Bug 619931 - systemd is confusingly verbose when starting SysV initscripts
systemd is confusingly verbose when starting SysV initscripts
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-30 18:12 EDT by Michal Jaegermann
Modified: 2010-08-19 21:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-19 21:34:25 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 Michal Jaegermann 2010-07-30 18:12:20 EDT
Description of problem:

On a test system one can see that I have NetworkManager and wpa_supplicant turned off on all levels (with good reasons for such configuration).  Despite of that after a boot with systemd one can see that these services are running.  Also watching startup messages one can notice that systemd attempts to start up various other services nobody asked for but it fails to do that for assorted reasons.

After a reboot with "init=/sbin/upstart" services which were configured off indeed do not run.

Version-Release number of selected component (if applicable):
systemd-4-4.fc14

How reproducible:
always
Comment 1 Michal Schmidt 2010-08-01 07:56:38 EDT

*** This bug has been marked as a duplicate of bug 615293 ***
Comment 2 Michal Jaegermann 2010-08-01 10:23:27 EDT
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of bug 615293 ***    

I wonder if this is not a bit hasty.  NetworkManager, which bug 615293 specifically talks about, provides the most obvious instance of the problem.  OTOH I see also attempts to start other uncalled for services ending in failures for whatever reasons.  One would expect that this will be not happening.
Comment 3 Michal Schmidt 2010-08-01 10:25:19 EDT
(In reply to comment #2)
> OTOH I see also attempts to start other uncalled for services ending in
> failures for whatever reasons.

In that case please be more specific. What services? What failures? Could you boot with systemd.log_level=debug and attach the resulting dmesg?
Comment 4 Michal Jaegermann 2010-08-01 13:18:30 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > OTOH I see also attempts to start other uncalled for services ending in
> > failures for whatever reasons.
> 
> In that case please be more specific. What services? What failures? Could you
> boot with systemd.log_level=debug and attach the resulting dmesg?    

As I wrote in the original report "... watching startup messages one can notice that systemd attempts to start up various other services nobody asked for ...".
grep through /var/log/boot.log on my test system gives:

Starting start and stop ip6tables firewall failed.
Starting restorecond uses inotify to look for creation of new files listed in the /etc/selinux/restorecond.conf file, and restores the correct security context. failed.
Starting processor frequency scaling support failed.
Starting Start and stop the MD software RAID monitor failed.
Starting Starts the RPCSEC GSS client daemon failed.
Starting Starts the RPCSEC GSS server daemon failed.
Starting Initialize SCSI tape drives with /sbin/stinit failed.

All these startup scripts terminate with a status 6 or 7 because one or another config file is missing.  Up to now they were just quietly exiting. In a systemd context one gets a red "failed".  True in a strict sense but from a sysadmin point of view a spurious noise which may mask real troubles.

One can indeed do 'chkconfig stinit off' and this will remove, for example, the last of these messages but up to now this was not a requirement and it was enough to provide a config file to have such service running. Just a question of back compatibility.
Comment 5 Michal Schmidt 2010-08-01 13:46:55 EDT
What does, for example, "chkconfig --list mdmonitor" say?
Comment 6 Michal Jaegermann 2010-08-01 14:13:15 EDT
(In reply to comment #5)
> What does, for example, "chkconfig --list mdmonitor" say?    

It is in a default "on" state while booting, which certainly makes easier to add a RAID storage to a long running system and conforms to long established expectations, but neverthless is inactive due to a line:

    [ -f /etc/mdadm.conf ] || return 6

in /etc/init.d/mdmonitor with /etc/mdadm.conf absent.

Before you will tell me that I can do "chkconfig rpcgssd off" and
"chkconfig rpcsvcgssd off" to shut off some of quoted complaints, which I certainly can do, please take into account that if in a year or two I decide to make "SECURE_NFS=yes" in /etc/sysconfig/nfs then I will have to do "O, yeah! Something was turned off here. I wonder what that could be?".  Hopefuly my memory will be good enough for that but I cannot be sure.
Comment 7 Michal Schmidt 2010-08-02 06:51:40 EDT
Finally I understand what you mean.

Compared to upstart, systemd seems to be more talkative during boot. It always announces which SysV service it is about to start (with the text taken from the initscript's "Short-Description:"), upstart does not do that.

Systemd also says "failed" if the service is not configured and returns 6 immediately. Upstart keeps quiet in this case.

But they both really run the scripts of the same services, so it's not like systemd starts something that upstart would not (except for the separate issue with starting NM). It's just an issue of being overly verbose.
Comment 8 Michal Jaegermann 2010-08-02 13:52:38 EDT
(In reply to comment #7)
> Finally I understand what you mean.

I possibly conflated two issues but with systemd I got services which were starting even if configured "off", like NetworkManager AND wpa_supplicant, and also complaints about services which should not be starting for other reasons where neither upstart nor earlier SysVinit were fazed.  Presumably exit codes like 6 or 7 are there for a reason, unless I am reading into that too much, but maybe this was never spelled out.
Comment 9 Lennart Poettering 2010-08-19 21:34:25 EDT
Note that most of the time systemd is actually quieter then traditional sysv boots, i.e. if "quiet" is passed on the kernel command line. If you remove the option, then systemd becomes quite a bit more chatty.

I have now changed systemd in git master to ignore the LSB exit codes 5 and 6 as clean exit codes for Sysv scripts. That should make those "failed" lines for the mentioned services go away, and the services won't be put in "maintenance" mode anymore. I'll close this bug now, and will upload a new systemd snapshot with this shortly.

The user issues (i.e. NM being started even though disabled) is already fixed as per bug 615293.

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