You are not logged in.
Pages: 1
# systemctl --all | grep error
arch-per...ttings.service error inactive dead arch-persistent-settings.service
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
I never installed audit, plymouth. I don't use rc-local, syslog and arch-persistent-settings.
I have a pure systemd installation.
Nothing seems broken due to this mistake.
Help me please.
Offline
Its not a problem and doesn't cause any trouble AFAIK
The only weird thing in this output is that the display-manager.service is not active.
Offline
The only weird thing in this output is that the display-manager.service is not active.
# systemctl enable display-manager.service
Failed to issue method call: No such file or directory
Offline
which display manager do you use??
Also if you don't like seeing errors you can mask the services.
Offline
" This is a bit of a hidden feature in systemd, since it is not commonly useful and might be confusing the user. " from http://0pointer.de/blog/projects/three- … f-off.html
Tell me this: why are inactive services show up as errors. Thats more of a bug then a feature.
Offline
they are in "error" state because they are referenced in other unit files (via After= Before= etc.) but don't actually exist. This is perfectly normal and nothing to worry about, but I see your point that "error" is kind of a "strong" word for this.
display-manager.service is pulled in by graphical.target . All display manager units have been changed to create an alias for this service instead of being grouped into graphical.target. If it isn't, try "systemctl reenable <your-display-manager>.service".
Offline
they are in "error" state because they are referenced in other unit files (via After= Before= etc.) but don't actually exist. This is perfectly normal and nothing to worry about, but I see your point that "error" is kind of a "strong" word for this.
display-manager.service is pulled in by graphical.target . All display manager units have been changed to create an alias for this service instead of being grouped into graphical.target. If it isn't, try "systemctl reenable <your-display-manager>.service".
Thanks for explanatations. I'm no longer in anxious!
For display-manager.service a
systemctl reenable kdm.service
solves the situation
Thanks guys!!!
Offline
I never installed audit, plymouth. I don't use rc-local, syslog and arch-persistent-settings.
I have a pure systemd installation.
Nothing seems broken due to this mistake.
Help me please.
Some of these (plymouth, auditd) are show up because other services reference them (After=) and the files do not exist. I think this should be possible to deal with better so they don't show up at all.
As to rc-local.service and arch-persistant-settings.service, these seem like leftovers from some old package. Could there be that you have some stray symlinks in /etc/systemd/system?
Offline
I also have rc-local.service and no symlinks related to it in /etc/systemd/system.
The only thing that seems to refer to it is Before=getty@tty1.service
Last edited by 89c51 (2012-08-25 18:20:29)
Offline
I also have rc-local.service and no symlinks related to it in /etc/systemd/system.
The only thing that seems to refer to it is Before=getty@tty1.service
This file is part of initscripts (merged from the former initscripts-systemd) So it only exists if you have a hybrid system.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
The file does not exist. I meant i have it appear as an error when i
systemctl --all | grep error
I never had a hybrid system. I went systemd from the beginning.
Offline
The file does not exist. I meant i have it appear as an error when i
systemctl --all | grep error
I never had a hybrid system. I went systemd from the beginning.
I thought you had the unit file but no symlinks. If you want to find the units referencing it, use:
grep rc-local `find /usr/lib/systemd/system -not -type d`
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
ambro wrote:I never installed audit, plymouth. I don't use rc-local, syslog and arch-persistent-settings.
I have a pure systemd installation.
Nothing seems broken due to this mistake.
Help me please.Some of these (plymouth, auditd) are show up because other services reference them (After=) and the files do not exist. I think this should be possible to deal with better so they don't show up at all.
As to rc-local.service and arch-persistant-settings.service, these seem like leftovers from some old package. Could there be that you have some stray symlinks in /etc/systemd/system?
No symlinks related in /etc/systems/system for me, too.
$ ls -l /etc/systemd/system
totale 24
lrwxrwxrwx 1 root root 35 25 ago 17.37 display-manager.service -> /usr/lib/systemd/system/kdm.service
drwxr-xr-x 2 root root 4096 2 giu 09.17 getty.target.wants
drwxr-xr-x 2 root root 4096 11 ago 01.17 local-fs.target.wants
drwxr-xr-x 2 root root 4096 13 ago 17.37 multi-user.target.wants
-rw-r--r-- 1 root root 498 11 ago 00.03 networkstatic.service
drwxr-xr-x 2 root root 4096 13 ott 2011 shutdown.target.wants
drwxr-xr-x 2 root root 4096 11 ago 01.17 sysinit.target.wants
I started with mixed installation with old arch-persistent-settings, but now I'm in a pure installation
# pacman -Qs systemd
local/libsystemd 188-2
systemd client libraries
local/systemd 188-2
system and service manager
local/systemd-arch-units 20120704-2
Arch specific Systemd unit files
local/systemd-sysvcompat 188-2
sysvinit compat for systemd
local/systemd-tools 188-2
standalone tools from systemd
Offline
89c51 wrote:The file does not exist. I meant i have it appear as an error when i
systemctl --all | grep error
I never had a hybrid system. I went systemd from the beginning.
I thought you had the unit file but no symlinks. If you want to find the units referencing it, use:
grep rc-local `find /usr/lib/systemd/system -not -type d`
Indeed , I got this by entering the command above:
$ grep rc-local `find /usr/lib/systemd/system -not -type d`
/usr/lib/systemd/system/getty@.service:After=rc-local.service
/usr/lib/systemd/system/serial-getty@.service:After=rc-local.service
/usr/lib/systemd/system/console-getty.service:After=rc-local.service
/usr/lib/systemd/system/console-shell.service:After=rc-local.service
/usr/lib/systemd/system/autovt@.service:After=rc-local.service
what should I do next ? could I remove them ?
Offline
progandy wrote:89c51 wrote:The file does not exist. I meant i have it appear as an error when i
systemctl --all | grep error
I never had a hybrid system. I went systemd from the beginning.
I thought you had the unit file but no symlinks. If you want to find the units referencing it, use:
grep rc-local `find /usr/lib/systemd/system -not -type d`
Indeed , I got this by entering the command above:
$ grep rc-local `find /usr/lib/systemd/system -not -type d` /usr/lib/systemd/system/getty@.service:After=rc-local.service /usr/lib/systemd/system/serial-getty@.service:After=rc-local.service /usr/lib/systemd/system/console-getty.service:After=rc-local.service /usr/lib/systemd/system/console-shell.service:After=rc-local.service /usr/lib/systemd/system/autovt@.service:After=rc-local.service
what should I do next ? could I remove them ?
Sorry I think I cannot remove them , but could I modify it a little ? As the real service "rc-local" does not exist , is there any danger to modify the service's (e.g. getty@.service) parameter "After" ? If could , how ?
Offline
Sorry I think I cannot remove them , but could I modify it a little ? As the real service "rc-local" does not exist , is there any danger to modify the service's (e.g. getty@.service) parameter "After" ? If could , how ?
you could override the files and remove the references, yes, but you also would have to make sure that the units are still up to date everytime the corresponding package is updated.
but this is imho totally pointless, just ignore the "errors", they don't even show up unless you specify "--all".
Offline
Shirui wrote:Sorry I think I cannot remove them , but could I modify it a little ? As the real service "rc-local" does not exist , is there any danger to modify the service's (e.g. getty@.service) parameter "After" ? If could , how ?
you could override the files and remove the references, yes, but you also would have to make sure that the units are still up to date everytime the corresponding package is updated.
but this is imho totally pointless, just ignore the "errors", they don't even show up unless you specify "--all".
Thank you very much , I just masked them , no "error" on the screen , world is wonderful ~~
Offline
Pages: 1