[solved] errors in systemctl output

karol · 2013-07-19 19:54:54

$ sudo systemctl --all --no-pager | grep error
auditd.service             error  inactive dead      auditd.service
syslog.target              error  inactive dead      syslog.target

$ pkgfile auditd.service 
community/audit
$ pkgfile syslog.target
$

$ cat /usr/lib/systemd/system/systemd-update-utmp.service
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Update UTMP about System Reboot/Shutdown
Documentation=man:systemd-update-utmp.service(8) man:utmp(5)
DefaultDependencies=no
RequiresMountsFor=/var/log/wtmp
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service systemd-remount-fs.service systemd-tmpfiles-setup.service auditd.service
Before=sysinit.target shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-update-utmp reboot
ExecStop=/usr/lib/systemd/systemd-update-utmp shutdown

There are some services that have

After=syslog.target

dbus.service, nscd.service, lm_sensors.service, svnserve.service.

Should I do anything about these errors? syslog.target doesn't seem to exist at all ...

Last edited by karol (2013-07-29 18:24:36)

WonderWoofy · 2013-07-19 20:11:48

I think the auditd.target is not terribly worrying. I have kind of wondered about the syslog.target though. What goes through my mind is that the syslog.target gets orderd that way so that these things will actually be logged (obviously). But the journal on its own is very robust, is ordered into the boot process nicely since it is part of systemd, and collects all the logging that has been sent to the socket before it has started anyway. So I think that if you are using just the journal it shouldn't really matter.

But this is just presumptions based on the bits I know about systemd.

karol · 2013-07-19 20:16:16

Installing audit and enabling the service makes the error go away, but what about syslog.target?

Edit: There are some other errors on both my computers and none of these files seems to be provided by any package:

display-manager.service
plymouth-quit-wait.service
plymouth-start.service
syslog.service

There's syslog-ng.service in syslog-ng.

Can someone check if they get these errors too or are my 2 computers acting up?

Last edited by karol (2013-07-19 20:20:44)

WonderWoofy · 2013-07-19 20:22:35

No I get all these as well. It is because you don't actually have those things running on your machine. I know for certain that all of them are harmless except for the syslog.target (which I suspect is harmless). I remember this coming up somewhere before and the advice was to simply ignore them as they are just there as information. Though I am not entirely sure where I had seen this. But I vaguely recall that the answer came from someone reliable.

Since they do nothing anyway, you could always mask them.

karol · 2013-07-19 20:24:56

WonderWoofy wrote:

Since they do nothing anyway, you could always mask them.

That's why I didn't post the other errors in the first post - because I forgot I masked them ;P

WonderWoofy · 2013-07-19 20:29:43

Yeah, I did that too a while back. It just bothered me seeing red.

cfr · 2013-07-19 23:31:50

I get

$ systemctl --all --no-pager | grep -i error
auditd.service             error  inactive dead      auditd.service
plymouth-quit-wait.service error  inactive dead      plymouth-quit-wait.service
plymouth-start.service     error  inactive dead      plymouth-start.service
syslog.target              error  inactive dead      syslog.target

If you boot to a display manager, I think you don't get the error for that one because enabling the relevant service sets up a symbolic link. For example:

lrwxrwxrwx 1 root root 31 Aws  26  2012 /etc/systemd/system/display-manager.service -> /etc/systemd/system/kdm.service

I remember reading complaints that systemd hard-coded dependencies on distro-specific stuff and that it shouldn't. (This was about the plymouth failures.) I tend to agree it is badly behaved in this respect. (As I've said before, I find the logging the biggest downside with systemd. It is the only thing which really bothers me and this, like journal, is part of that.) However, I believe it is harmless.

Does anybody know what audit is good for or what the syslog.target is important for? I actually use syslog-ng and I still get this error.

I take it that "masking" just involves the standard symlinking to /dev/null? I should probably do that for plymouth - the lack of a splash screen should not be highlighted as a boot error! I'd like to know more about the others, though...

karol · 2013-07-19 23:38:49

Yeah, it's just symlinking to /dev/null. You can mask and unmask stuff if you want to try it out:

$ sudo systemctl mask plymouth-start.service
ln -s '/dev/null' '/etc/systemd/system/plymouth-start.service'
$ sudo systemctl unmask plymouth-start.service
rm '/etc/systemd/system/plymouth-start.service'

cfr · 2013-07-19 23:50:30

Oh, right. Thanks. I didn't realise there was a command for it - I thought by "masking" you just meant install the symlinks.

karol · 2013-07-19 23:52:36

Read 'systemctl -h' before going to bed :-)

cfr · 2013-07-20 00:01:48

Cure for insomnia? I tend to have the opposite issue but thanks!

I have a feeling this has changed and that the recommendation used to be to make the symlinks. Anybody know if I'm imagining that?

Re. syslog.target: appears to be deprecated according to http://www.freedesktop.org/wiki/Softwar … md/syslog/ so I guess that the errors should gradually disappear as unit files (hopefully) adopt the new recommendations?

WonderWoofy · 2013-07-20 00:14:38

Yes teh recommendation used to be to create the symlinks, but systemctl has had the mask functioanlity for quite some time now.

cfr · 2013-07-20 00:25:39

Good. At least I'm in touch with a reality, even if not a current one.

karol · 2013-07-29 18:24:15

https://bbs.archlinux.org/viewtopic.php … 3#p1303083

falconindy wrote:

just ignore them... they're ephemeral deps created on the fly to fulfill the dependency graph.

I'm masking marking this thread as solved.

Arch Linux

#1 2013-07-19 19:54:54

[solved] errors in systemctl output

#2 2013-07-19 20:11:48

Re: [solved] errors in systemctl output

#3 2013-07-19 20:16:16

Re: [solved] errors in systemctl output

#4 2013-07-19 20:22:35

Re: [solved] errors in systemctl output

#5 2013-07-19 20:24:56

Re: [solved] errors in systemctl output

#6 2013-07-19 20:29:43

Re: [solved] errors in systemctl output

#7 2013-07-19 23:31:50

Re: [solved] errors in systemctl output

#8 2013-07-19 23:38:49

Re: [solved] errors in systemctl output

#9 2013-07-19 23:50:30

Re: [solved] errors in systemctl output

#10 2013-07-19 23:52:36

Re: [solved] errors in systemctl output

#11 2013-07-20 00:01:48

Re: [solved] errors in systemctl output

#12 2013-07-20 00:14:38

Re: [solved] errors in systemctl output

#13 2013-07-20 00:25:39

Re: [solved] errors in systemctl output

#14 2013-07-29 18:24:15

Re: [solved] errors in systemctl output

Board footer