[Solved] A few more questions about systemd

ratcheer · 2012-08-02 12:38:45

I have set up my system to use systemd, natively. Over the past two days, I have resolved most of my problems and questions. However, I still have a few errors and I have been unable to find out how to resolve them.

plymouth-start.service and plymouth-quit-wait.service are in error status. But, I do not have plymouth installed. When I try to disable these services, the response is "Failed to issue method call: No such file or directory". If the service files do not exist and I do not have plymouth, why are the services in error? How do I make the errors go away?

Similarly, auditd.service, display-manager.service, rc-local.service, and syslog.service are all in error status. But if I try to disable them, I get the same message as above. I am pretty sure I don't need display-manager, rc-local, and syslog. I have no idea whether I need auditd. But I would like to know how to eliminate the error statuses.

This is the output from systemctl:

auditd.service            error  inactive dead          auditd.service
display-manager.service   error  inactive dead          display-manager.service
plymouth...t-wait.service error  inactive dead          plymouth-quit-wait.service
plymouth-start.service    error  inactive dead          plymouth-start.service
rc-local.service          error  inactive dead          rc-local.service
syslog.service            error  inactive dead          syslog.service

Tim

Last edited by ratcheer (2012-08-02 13:22:46)

65kid · 2012-08-02 12:57:36

If they are in error state but you can't disable them, this means that there are pulled in by other units.

To see which ones they are pulled in by, do:

systemctl show -p WantedBy -p RequiredBy <unit file>

To fix display-manager.service do:

systemctl reenable <your-display-manager.service>

Last edited by 65kid (2012-08-02 12:57:57)

ratcheer · 2012-08-02 13:01:52

I found in another thread that these errors probably exist because some other services "Want" them, but they do not exist. Therefore, I suppose the only thing that can be done is to ignore them.

Tim

ratcheer · 2012-08-02 13:03:20

65kid wrote:

If they are in error state but you can't disable them, this means that there are pulled in by other units.
To see which ones they are pulled in by, do:
systemctl show -p WantedBy -p RequiredBy <unit file>
To fix display-manager.service do:
systemctl reenable <your-display-manager.service>

Thanks. That agrees with what I found.

Also, I do not run a display manager. I boot to a text console, then start Openbox with startx.

Tim

PS - This reminds me of the old saying, "Round and round and round she goes. Where she stops, nobody knows."

Last edited by ratcheer (2012-08-02 13:04:41)

65kid · 2012-08-02 13:07:15

ratcheer wrote:

Also, I do not run a display manager. I boot to a text console, then start Openbox with startx.

in this case try:

systemctl mask <unit file>

although I'm not sure if this gets rid of the "error" state, haven't tested it. If this doesn't work you afaik don't have much choice but to ignore the errors.

ratcheer · 2012-08-02 13:07:36

Here is one of them. Based on the above idea, it still does not make sense:

# systemctl show -p WantedBy -p RequiredBy plymouth-start.service 
RequiredBy=
WantedBy=

Tim

65kid · 2012-08-02 13:15:26

sorry, I kind of confused "error" with "failed". I also see these "errors", but only with "systemctl --all". It simply means that these services are referenced in some other unit files (via Before= , After= or whatever) but don't actually exist. This is nothing to worry about, which is probably the reason they are only shown with "--all".

ratcheer · 2012-08-02 13:22:23

Ok, I tried your suggestion of masking them. They do not go away entirely, but at least their status shows as a white "masked" instead of a red "error". There may be no real improvement, but it is more pleasing and I am marking the thread solved.

Thank you,
Tim

greg1 · 2012-11-02 21:39:38

hi, i manually cleaned up syslog.service/socket/target - was referenced by services like: NetworkManager, dbus, nscp, snmpd, systemd-journal etc - it was referenced by After= Before= lines but also StandardOutput=syslog (i changed it to journal) - ideally by removing package syslog-ng from system all traces of syslog should disappear from files in /usr/lib/systemd/system - it is not a case though

SanskritFritz · 2012-11-05 15:27:52

greg1 wrote:

hi, i manually cleaned up syslog.service/socket/target - was referenced by services like: NetworkManager, dbus, nscp, snmpd, systemd-journal etc - it was referenced by After= Before= lines but also StandardOutput=syslog (i changed it to journal) - ideally by removing package syslog-ng from system all traces of syslog should disappear from files in /usr/lib/systemd/system - it is not a case though

Should this be reported on the bug tracker?

Leonid.I · 2012-11-05 17:57:12

SanskritFritz wrote:

greg1 wrote:
hi, i manually cleaned up syslog.service/socket/target - was referenced by services like: NetworkManager, dbus, nscp, snmpd, systemd-journal etc - it was referenced by After= Before= lines but also StandardOutput=syslog (i changed it to journal) - ideally by removing package syslog-ng from system all traces of syslog should disappear from files in /usr/lib/systemd/system - it is not a case though
Should this be reported on the bug tracker?

Please don't do that.

The above "cleaning" is totally unnecessary and harmful. Please read http://www.freedesktop.org/wiki/Software/systemd/syslog instead.

greg1 · 2013-01-07 12:01:49

hi, what is harmful about removing pointers to non-existant package/binaries? (this of course shouldnt be your job though transition from syslog-ng to journald doesnt seem to be smooth thus one may want to smooth some edges manually here) - i think that harmful would be not to replace syslog with journal in systemd files since you wouldnt see any log messages from services like alsa-store.service etc anymore - also not sure if this is related to bug about some random delay in shuting down xfce with systemd - people tried to add kill couple of times to ExecStop for slim.service with aparently no luck - i believe problem is with alsa-store and syslog reference, to me alsa-store.service gets confused about missing syslog (if you didnt do that manual cleanup) and it lags behind, in a meanwhile all filesystems are dismounted and then alsa-store wants to save state - and then there is delay - cant say for sure but i believe systemd files should be properly clean up from syslog entries either by installing journald or by removing syslog-ng package

greg1 · 2013-01-09 14:29:16

apologies i proved myself wrong, syslog.service error and other error'ed services seem not to relate to slim.service delay at shutdown, nevertheless the only solution i found to resolve errored services is to manually delete them, and for example for syslog.service replace Output=syslog with Output=journal and Before/After=syslog.target with systemd-journald.service - that would be until next systemd/journald update but hopefully next update will bring along some proper cleanup

Last edited by greg1 (2013-01-09 14:32:17)

acar_go · 2014-09-08 15:52:26

About display-manager.service

If you have a "display-manager" you must "change default target"

3 	runlevel3.target, multi-user.target 	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5 	runlevel5.target, graphical.target 	Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.

Therefore, type in the console:

# systemctl set-default -f multi-user.target

On the other, use:

systemctl show -p WantedBy -p RequiredBy <unit file>

Research if needed if not disable them.

jasonwryan · 2014-09-08 17:10:47

Please don't necrobump, especially solved threads: Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.

Closing

Arch Linux

#1 2012-08-02 12:38:45

[Solved] A few more questions about systemd

#2 2012-08-02 12:57:36

Re: [Solved] A few more questions about systemd

#3 2012-08-02 13:01:52

Re: [Solved] A few more questions about systemd

#4 2012-08-02 13:03:20

Re: [Solved] A few more questions about systemd

#5 2012-08-02 13:07:15

Re: [Solved] A few more questions about systemd

#6 2012-08-02 13:07:36

Re: [Solved] A few more questions about systemd

#7 2012-08-02 13:15:26

Re: [Solved] A few more questions about systemd

#8 2012-08-02 13:22:23

Re: [Solved] A few more questions about systemd

#9 2012-11-02 21:39:38

Re: [Solved] A few more questions about systemd

#10 2012-11-05 15:27:52

Re: [Solved] A few more questions about systemd

#11 2012-11-05 17:57:12

Re: [Solved] A few more questions about systemd

#12 2013-01-07 12:01:49

Re: [Solved] A few more questions about systemd

#13 2013-01-09 14:29:16

Re: [Solved] A few more questions about systemd

#14 2014-09-08 15:52:26

Re: [Solved] A few more questions about systemd

#15 2014-09-08 17:10:47

Re: [Solved] A few more questions about systemd

Board footer