You are not logged in.
Hi,
I've tried to set up systemd. It is quite fast, but sometimes after booting the graphical target isn't loaded, slim doesn't starts. In the file /usr/lib/systemd/system/graphical.target is no content, it is empty. I don't know if this should be so. Here are some debug messages that maybe useful for you:
$ systemctl list-units --type=target
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
basic.target loaded active active Basic System
cryptsetup.target loaded active active Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target masked active active graphical.target
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User
network.target loaded active active Network
remote-fs.target loaded active active Remote File Systems
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
syslog.target loaded active active Syslog
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
JOB = Pending job for the unit.
14 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
$ systemctl status slim.service
slim.service - SLiM Simple Login Manager
Loaded: loaded (/usr/lib/systemd/system/slim.service; enabled)
Active: failed (Result: exit-code) since Fri, 28 Sep 2012 11:00:32 +0200; 28min ago
Main PID: 398 (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/slim.service
Sep 28 11:00:32 archlinux kill[416]: usage: kill [ -s signal | -p ] [ -a ] pid ...
Sep 28 11:00:32 archlinux kill[416]: kill -l [ signal ]
$ systemd-analyze blame
16256ms psd.service
2905ms dhcpcd@eth0.service
146ms systemd-remount-fs.service
143ms dev-hugepages.mount
140ms console-kit-log-system-start.service
139ms systemd-udev-trigger.service
109ms systemd-udevd.service
83ms dev-mqueue.mount
77ms sys-kernel-debug.mount
76ms console-kit-daemon.service
73ms systemd-sysctl.service
71ms systemd-logind.service
66ms systemd-vconsole-setup.service
48ms slim.service
41ms boot-efi.mount
27ms udisks2.service
27ms home.mount
20ms tmp.mount
11ms upower.service
9ms systemd-user-sessions.service
$ cat /var/log/slim.log
slim: waiting for X server to begin accepting connections
Giving up.
slim: unable to connect to X server
slim: waiting for X server to begin accepting connections
Giving up.
slim: unable to connect to X server
slim: waiting for X server to begin accepting connections
Giving up.
slim: unable to connect to X server
$ systemctl --failed
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
iptables.service loaded failed failed Packet Filtering Framework
slim.service loaded failed failed SLiM Simple Login Manager
systemd-tmpfiles-clean.service loaded failed failed Cleanup of Temporary Directories
systemd-tmpfiles-setup.service loaded failed failed Recreate Volatile Files and Directories
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
JOB = Pending job for the unit.
4 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Last edited by Paloran (2012-09-28 16:42:11)
Offline
Maybe there's nothing wrong with systemd's behaviour and the slim.service, since you get the following message:
slim: waiting for X server to begin accepting connections
Giving up.
slim: unable to connect to X server
Have you checked the xorg log? Maybe X isn't able to load some drivers or something?
Offline
maybe your system boots so fast that X is started before your video kernel driver is loaded (KMS). This is a known problem and actually has to be fixed in the display manager. A workaround is to add the kernel module for your video card (nouveau, i915 or whatever) to the MODULES array in /etc/mkinitcpio.conf and rebuild your initramfs with "mkinitcpio -p linux".
You should also have a look at the status of iptables and systemd-tmpfiles-clean/-setup, although this may not be related to your problem.
Offline
I've checked the xorg log, i haven't found anything suspicious. Falconindy, how do i fix the masked unit?
//edit I mean, when i have symlinked it to /dev/null that the file is unrecoverable. Could anyone please post the content of his graphical.target?
//@65kid i'm looking at the other errors after I've fixed this issue.
Last edited by Paloran (2012-09-28 10:29:18)
Offline
I've checked the xorg log, i haven't found anything suspicious. Falconindy, how do i fix the masked unit?
//edit I mean, when i have symlinked it to /dev/null that the file is unrecoverable. Could anyone please post the content of his graphical.target?
//@65kid i'm looking at the other errors after I've fixed this issue.
systemctl unmask graphical.target
Offline
...with
# systemctl unmask <name-of-unit.service>
... you may then want to check the status and "enable" if necessary...
systemctl --help
lists all the options at your disposal
Offline
cat /usr/lib/systemd/system/graphical.target
# 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=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yes
[Install]
Alias=default.target
Offline
Thanks for all your help!
Offline