You are not logged in.
Hello I've just successfully (hope so) changed init system to systemd, but I'm little worried about some services with error status:
auditd.service error inactive dead auditd.service
display-manager.service error inactive dead display-manager.service
plymouth-quit-wait.service error inactive dead plymouth-quit-wait.service
plymouth-start.service error inactive dead plymouth-start.service
runlevel1.target error inactive dead runlevel1.target
runlevel2.target error inactive dead runlevel2.target
runlevel3.target error inactive dead runlevel3.target
runlevel4.target error inactive dead runlevel4.target
runlevel5.target error inactive dead runlevel5.target
syslog.target error inactive dead syslog.target
I've searched for similar issues and I understood that some of these errors are caused because of After/Before dependencies.
I found out that because I'm not using any login manager display-manager is in error state -> but where can I find such information?
I'm really worried about runlevels. Why runlevel5 is in error when graphical.target is OK? What with the rest of targets.
Last edited by patseb (2013-03-23 19:32:38)
Offline
These are not really "errors", systemd just complains because these units are referenced by other units (by After/Before, as you said), but don't actually exist. This is nothing to worry about, which is also why you don't even see those unless you pass "--all" to systemctl. The runlevel targets are probably just leftovers from the sysvinit compatibility. display-manager.service is pulled in by graphical.target ("systemctl show -p WantedBy display-manager.service" would have told you that). If you don't have a display manager, you might just as well make multi-user.target the default, so this error would disappear (systemctl enable multi-user.target).
Offline
Thank you for explanation.
Offline
Just to chime in here:
I found that an annoying glitch in my systemd boot sequence was solved by creating symlinks to graphical.target from runlevel5.target, runlevel4.target and runlevel3.target. Also, I created a symlink to multi-user.target from runlevel2.target.
I placed these symlinks in /usr/lib/systemd/system.
Last edited by dhave (2013-03-30 04:50:01)
Offline
Just to chime in here:
I found that an annoying glitch in my systemd boot sequence was solved by creating symlinks to graphical.target from runlevel5.target, runlevel4.target and runlevel3.target. Also, I created a symlink to multi-user.target from runlevel2.target.
I placed these symlinks in /usr/lib/systemd/system.
I didn't even notice that those had disappeared. I am not sure what effect this might actually have, but if it works for you, awesome! But I might recommend putting these in /etc instead of /usr. It just seems like that would be the better place for them, and would have the same effect.
Offline
dhave wrote:Just to chime in here:
I found that an annoying glitch in my systemd boot sequence was solved by creating symlinks to graphical.target from runlevel5.target, runlevel4.target and runlevel3.target. Also, I created a symlink to multi-user.target from runlevel2.target.
I placed these symlinks in /usr/lib/systemd/system.
I didn't even notice that those had disappeared. I am not sure what effect this might actually have, but if it works for you, awesome! But I might recommend putting these in /etc instead of /usr. It just seems like that would be the better place for them, and would have the same effect.
I can see why you might want to have user-created links in a separate subdirectory, but I think I prefer to have all the systemd target files in the same place. I periodically back up my /usr and /etc, so if I needed to restore my system as configured, I'd get these links back either way.
Offline