Has anyone else tried systemd + systemd-sysv with SLiM? Did it work for you? (It failed for me.)
@Super-Nathan: I assume you're either using a different login manager or invoking startx directly?
@pvsage, I use systemd with SLiM. One of the things you might look into is if you're still trying to start SLiM with inittab. You are going to have to use systemd to start the slim daemon at boot time to get them to play with each other. If I remember correctly, the command is
sudo systemctl enable slim.service
EDIT: In fear of the furious retribution that could strike at random should I not really take the time to fully address all possibilities. There are a few things that can cause SLiM to not work at boot. If you've successfully migrated to systemd for boot, use
systemctl status slim
To see if the service has been correctly loaded. If not, it should provide you with hints as to why. You can also use
ls /usr/lib/systemd/system/ |grep slim
to make sure that the service itself is available. SLiM (much like everything else) wasn't originally created with a service file as it came out before systemd was implemented on most systems. If you have an older packaged version of SLiM, then there may not be a slim.service to start. This is corrected in newer releases of SLiM.
Last edited by DebianJoe (2013-05-07 08:51:43)
Anyone try using netctl on debian? I've been using it on arch but I can't get it to run after my computer starts up. If I could get that working (or just disabled netctl alltogether) could seriously get my boot time under half a second. It's still worth it though, super tired of messing with network-manager and wicd just to get a wired connection.
(daniel@delphiarch)(1358/pts/2)(10:23am:05/07/13)- (%:/)- systemd-analyze time Startup finished in 1.566s (kernel) + 581ms (userspace) = 2.148s (daniel@delphiarch)(1359/pts/2)(10:24am:05/07/13)- (%:/)- systemd-analyze blame 1.909s netctl@ethernet\x2dstatic.service 127ms httpd.service 94ms systemd-logind.service 66ms console-kit-log-system-start.service 66ms console-kit-daemon.service 56ms alsa-restore.service 53ms systemd-udev-trigger.service 49ms systemd-modules-load.service 49ms systemd-sysctl.service 40ms udisks2.service 40ms dev-hugepages.mount 39ms systemd-remount-fs.service 39ms systemd-fsck@dev-disk-by\x2duuid-08BA\x2dE656.service 36ms dev-mqueue.mount 36ms systemd-vconsole-setup.service 33ms sys-kernel-debug.mount 32ms polkit.service 30ms systemd-static-nodes.service 29ms rc-local.service 26ms systemd-tmpfiles-setup.service 23ms systemd-journal-flush.service 9ms systemd-tmpfiles-clean.service 6ms systemd-random-seed-load.service 6ms systemd-user-sessions.service 5ms upower.service 3ms sys-kernel-config.mount 3ms tmp.mount 3ms systemd-udevd.service 2ms boot-efi.mount 1ms boot.mount 634us sys-fs-fuse-connections.mount
Edit: Tried disabling netctl all together (before I had it disabled but set to start 5 seconds after boot with a cron job) and starting netctl manually after boot, this is what I got:
(daniel@delphiarch)(1404/pts/0)(10:38am:05/07/13)- (%:/)- syssystemd-analyze time Startup finished in 1.587s (kernel) + 610ms (userspace) = 2.197s (daniel@delphiarch)(1405/pts/0)(10:38am:05/07/13)- (%:/)- systemd-analyze blame 120ms systemd-logind.service 69ms console-kit-daemon.service 60ms systemd-udev-trigger.service 53ms systemd-modules-load.service 50ms systemd-remount-fs.service 46ms alsa-restore.service 46ms sys-kernel-debug.mount 46ms systemd-sysctl.service 43ms dev-hugepages.mount 43ms rc-local.service 40ms dev-mqueue.mount 39ms console-kit-log-system-start.service 37ms systemd-fsck@dev-disk-by\x2duuid-08BA\x2dE656.service 36ms systemd-vconsole-setup.service 32ms polkit.service 30ms systemd-static-nodes.service 29ms systemd-user-sessions.service 26ms systemd-tmpfiles-setup.service 9ms upower.service 6ms systemd-random-seed-load.service 6ms systemd-journal-flush.service 6ms tmp.mount 3ms sys-kernel-config.mount 3ms boot.mount 3ms systemd-udevd.service 2ms boot-efi.mount 1ms sys-fs-fuse-connections.mount
So it isn't showing as taking 2 seconds at startup anymore, but the boot time hasn't changed significantly. I actually started 0.049 seconds faster with netctl enabled, who knew? Kinda scratching my head at why stuff that is started via cron shows up in systemd-analyze, but whatever. I can deal with a two second boot.
Last edited by mynis01 (2013-05-07 14:46:35)
Does anyone know, how well this works with encryption and lvm?
@MrPink. I can't comment on encryption, but I have it working with LVM without any issues other than the slim problem detailed above.
Just want to thank Super Nathan for this - up and running speedily on 4 machines, now: netbook, q9550 and q6600 desktops, and Turion 64x2 laptop. All fine. Sweet!
Hello, I just tried this on my old pentium 4. It didn't do anything to the boot time (a monstreous 50 sec.), but it did halved the shutdown time (from 7 to nearly 3 sec.)
Now I'll just try to compile that kernel with localemod to see if that will change anything. Thanks anyway for the tip!
echo systemd-sysv hold | dpkg --set-selections
"dpkg: error: operation requires read/write access to dpkg status area"
^ That's one command with which I had no problem. Rather than entering a root shell, I used sudo with all the commands; in this case, insert sudo after the pipe.
Root shell, and no root shell....same dpkg: error.
sudo echo systemd-sysv hold | sudo dpkg --set-selections
"Do or do not. There is no try." ~ Master Jedi Yoda
Yes, systemd in Debian is working with unstable (sid). No unusual issues specifically with systemd (presently), though sid has some quirks at the moment... Running LVM, LUKS, and NFS bits without issue, though LUKS somewhat mitigates the boot speed enhancements of systemd over sysvinit.
One thing to note, if one is running /var/log in tmpfs, then ConsoleKit throws an error, a solution is:
systemctl status console-kit-log-system-start.service
To check for an error starting the service.
mkdir -p /etc/tmpfiles.d echo 'D /var/log/ConsoleKit/ 0755 root root' > /etc/tmpfiles.d/console-kit.conf
This tells console-kit-log-system-start.service to delay starting until the tmpfs is established.
Will be systemd program added in Jessie? And how it will perform on a new hardware? If you put your HDD on another PC?
Dried frog pills
As their name suggests, these are pills made chiefly from frogs, specifically the extremely poisonous ones that live in the vivarium at Unseen University and handled by the first-year students, so that if they kill one of them, not too much education has been wasted.
I use them daily!