systemd: Yet Another Init Replacement

skodabenz · 2011-08-14 19:27:18

I have a minor issue with systemd. I use both sysvinit ans systemd parallelly in my system (mostly of the time booting with systemd as the init though). I use rsyslog and cronie, and have rsyslogd and crond in the daemons array of /etc/rc.conf (for sysvinit). I also enabled rsyslog.service and cronie.service.

Since systemd tries loading legacy units for rc.conf deamons, it fails to load crond.service (cronie.service is loaded successfully). When it comes to rsyslog, it always loads rsyslogd.service (legacy unit) and fails for rsyslog.service (actual systemd unit file).

How to make sure

1. Systemd always uses rsyslog.service instead of rsyslogd.service taken from rc.conf ?
2. Make sure crond.service is not even started if any one of the cron unit files are started (in this case cronie.service)?

Overall how to make sure systemd uses native unit files first, before fall back to rc.conf parsed legacy unit files? I understand that both these warning are non-fatal . Its just that I want to know how to make this work.

FWIW this is the error shown for rsyslog.service (taken from dmesg | grep -i rsyslog)

[   14.350358] systemd[1]: Cannot add dependency job for unit rsyslog.socket, ignoring: Unit rsyslog.socket failed to load: No such file or directory. See system logs and 'systemctl status rsyslog.socket' for details.
[   33.737915] systemd[1]: rsyslog.service: main process exited, code=exited, status=1
[   33.760044] systemd[1]: Unit rsyslog.service entered failed state.
[  572.286993] systemd[1]: Cannot add dependency job for unit rsyslog.socket, ignoring: Unit rsyslog.socket failed to load: No such file or directory. See system logs and 'systemctl status rsyslog.socket' for details.
[  572.598635] systemd[1]: rsyslog.service: main process exited, code=exited, status=1
[  572.630017] systemd[1]: Unit rsyslog.service entered failed state.
[ 1127.597579] systemd[1]: Cannot add dependency job for unit rsyslog.socket, ignoring: Unit rsyslog.socket failed to load: No such file or directory. See system logs and 'systemctl status rsyslog.socket' for details.

Thanks in advance.

Last edited by skodabenz (2011-08-14 19:29:02)

falconindy · 2011-08-14 19:57:36

systemd will use native files first but only when the names clash. In this case there is no name clash so systemd has no idea that rsyslogd.service isn't the same as rsyslog.service.

Solution to all your problems: do not use arch-daemons.target. As mentioned in the wiki, this is not meant to be a sustainable solution. If you must, use it to create unit files for which you have no native unit file and then disable it.

tomegun · 2011-08-14 21:58:47

@skodabenz: in addition to what falconindy said, I think there is some value in making the arch-daemons.target work well (some might find it simpler to enable this before all their daemons have native service files). Actually, I don't think we should expect people to be making / copying .service files at all, unless they are helping with the systemd packages (but that's just my opinion).

I think a way of making it work is to add a symlink in /etc/systemd/system from rsyslogd.service to /lib/systemd/system/rsyslog.service (and similar for cronied). This means that systemd will realise that the legacy daemon and the native service are the same thing.

Viper_Scull · 2011-08-16 18:31:34

I've been out for almost two weeks. With the latest updates (udev, systemd, etc), now i get a line in red while booting:

Failed to open /dev/kmsg for logging: No such file or directory.

I have syslog-ng.service disabled (it was disabled before the updates as well).

Last edited by Viper_Scull (2011-08-16 18:32:27)

falconindy · 2011-08-16 20:51:05

Viper_Scull wrote:

I've been out for almost two weeks. With the latest updates (udev, systemd, etc), now i get a line in red while booting:
Failed to open /dev/kmsg for logging: No such file or directory.
I have syslog-ng.service disabled (it was disabled before the updates as well).

Sounds like you're using a custom kernel without an initramfs. You must make sure that /dev is mounted by the kernel in this case (CONFIG_DEVTMPFS_MOUNT=y).

framas · 2011-08-19 10:44:18

I need some help,

systemd mounts my /media/ fstab entrys always with the noexec flag even though I put exec in the fstab entry

cat /etc/fstab| grep media
/dev/mapper/arch_lvm-data /media/work btrfs rw,suid,exec,auto,user,async,compress=lzo,ssd 0 0

mount | grep media
dev/mapper/arch_lvm-data on /media/work type btrfs (rw,noexec,nosuid,nodev,compress=lzo,ssd)

This also happens on my other pc (also arch with systemd) with a "normal" /media/ partition (non lvm).

Where can I change this behavior?

Fackamato · 2011-08-19 10:59:56

framas wrote:

I need some help,
systemd mounts my /media/ fstab entrys always with the noexec flag even though I put exec in the fstab entry
cat /etc/fstab| grep media
/dev/mapper/arch_lvm-data /media/work btrfs rw,suid,exec,auto,user,async,compress=lzo,ssd 0 0

mount | grep media
dev/mapper/arch_lvm-data on /media/work type btrfs (rw,noexec,nosuid,nodev,compress=lzo,ssd)
This also happens on my other pc (also arch with systemd) with a "normal" /media/ partition (non lvm).
Where can I change this behavior?

systemd does mounting? I thought it was an init system?

falconindy · 2011-08-19 12:57:01

framas wrote:

I need some help,
systemd mounts my /media/ fstab entrys always with the noexec flag even though I put exec in the fstab entry
cat /etc/fstab| grep media
/dev/mapper/arch_lvm-data /media/work btrfs rw,suid,exec,auto,user,async,compress=lzo,ssd 0 0

mount | grep media
dev/mapper/arch_lvm-data on /media/work type btrfs (rw,noexec,nosuid,nodev,compress=lzo,ssd)
This also happens on my other pc (also arch with systemd) with a "normal" /media/ partition (non lvm).
Where can I change this behavior?

Not a systemd-specific behavior. You can change it in your fstab. 'user' implies 'noexec', and ordering prevails. 'user' should be first, if you're going to have it at all.

Aside, systemd creates a tmpfs on top of /media so that udisks can create directories and mount devices even when / is read only. If you have automounted partitions, I suggest mounting your static partitions in /mnt, not /media.

Fackamato wrote:

systemd does mounting? I thought it was an init system?

An init system reading /etc/fstab? Heresy. We definitely don't do this in /etc/rc.sysinit ........

Fackamato · 2011-08-19 13:04:34

HEh.

I thought it was hotpluggish, hence my question. Of course the init stuff reads fstab. Jesus.

falconindy · 2011-08-19 13:52:33

Your post came off sounding a bit trollish given the history of systemd in the arch community, hence my trollish response.

Yes, systemd offers on-demand mounting for any filesystem, whether it be local or remote. Adding 'noauto,x-systemd-automount' to the options of any drive in fstab will trigger creation of an automount unit, which sits watch on top of the mountpoint until first access, when its fsck'd (if its local) and mounted. Alternatively, you can create and start the automount unit on the fly for a path such as /mnt/nfs/joe just by running 'systemctl start mnt-nfs-joe.automount'.

Glaucous · 2011-08-19 21:20:23

Is it recommended (seems like systemd supports both) to use x-systemd-automount or comment=systemd.mount? In case one them is deprecated.

falconindy · 2011-08-19 21:57:47

I only saw x-systemd-automount because I was diving through sourcecode looking for something else. Grepping through the repo shows that its undocumented, but this may just be an oversight. I base that on the commit message tied to the addition of those names:

http://cgit.freedesktop.org/systemd/com … 54cfb37992

Based on the fact that both comment=systemd.automount and x-systemd-automount are undocumented, I'd say they're both equally safe to use. I'll pick the latter since its fewer keystrokes.

Last edited by falconindy (2011-08-19 21:59:12)

zephyr · 2011-08-20 15:45:26

Thanks to falconindy and everyone involved in bringing systemd to Arch!!

I switched yesterday to it and since I have quite a simple setup, native systemd was not a problem.
Though I haven't uninstalled sysvinit or initscripts, I use them for fallback

I have been trying to get the Plymouth to DM smooth transition working and I have made some interesting findings.
Apparently X does not need any patches and for KDM, which is the DM I use, patching is optional. LXDM has upstream support for plymouth and I suppose GDM could also be used unpatched.
So essentially the only packages that need changes are systemd and plymouth. Once I nail all the pieces I will post instrunctions if anyone is interested.

I recompiled systemd adding the "--enable-plymouth" configure line. Checking with namcap and with ldd /bin/systemd, plymouth is not listed.
So I believe the --enable-plymouth option only adds the plymouth*.service files in the package without making plymouth a hard dependency.

Could that option be included in the community/systemd package?

falconindy · 2011-08-20 16:05:15

You are correct, --enable-plymouth only adds in the .service files. No, I won't add them. They belong in the Plymouth package, not with systemd. I've heard that this will eventually happen...

zephyr · 2011-08-20 16:16:23

I see, thanks falconindy!
If this is what upstream will do, short term should be adding them in the AUR plymouth package.

zephyr · 2011-08-21 23:40:12

If anyone that uses plymouth with systemd, wants to try the smooth transition from plymouth to X, I have uploaded plymouth-systemd-git to AUR.

Also see the post at the plymouth thread below for some crude intructions:

https://bbs.archlinux.org/viewtopic.php … 40#p979940

diac · 2011-08-22 10:39:44

Hi,

I have try systemd on my laptop but I have one isue I can't solve.

When I boot with Systemd, I can't use my Ethernet card.
I have a interface in ifconfig but ethtool or mii-tool don't see the card.

When I start with iniV the card work correctly.
The log don't give me any information.

I don't now where I can look to have more information ?

falconindy · 2011-08-22 13:29:21

udev will tag your network device with a systemd tag when booting with systemd (and alias it for dependency purposes), but I can't see why this would affect ethtool. Example..

$ udevadm info --query=all -p /class/net/eth0
P: /devices/pci0000:00/0000:00:19.0/net/eth0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:19.0/net/eth0
E: INTERFACE=eth0
E: IFINDEX=2
E: SUBSYSTEM=net
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=82578DM Gigabit Network Connection
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x10ef
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:

Note the last two items...

$ sudo ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000001 (1)
                               drv
        Link detected: yes

diac · 2011-08-22 16:20:44

thanks for your answer, udev seems to tags the interface correctly :

$ udevadm info --query=all -p /class/net/eth0
P: /devices/pci0000:00/0000:00:19.0/net/eth0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:19.0/net/eth0
E: INTERFACE=eth0
E: IFINDEX=2
E: SUBSYSTEM=net
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=82577LC Gigabit Network Connection
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x10eb
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:

but I can't see eth0 with ethtool :

$ sudo ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available

but I see the interface in ifconfig :

$ ifconfig eth0
eth0   Link encap:Ethernet  HWaddr 00:23:18:06:1D:93  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:20 Memory:d4600000-d4620000

but of course completely unusable :

$ sudo dhcpcd eth0
dhcpcd[2139]: version 5.2.12 starting
dhcpcd[2139]: eth0: waiting for carrier
dhcpcd[2139]: timed out

I have probably miss something. Maybe a missing '*.devices' file in systemd ?

falconindy · 2011-08-22 17:16:13

Well, clearly something isn't right. I wouldn't be concerned about a missing device file, it's created implicitly:

$ systemctl status sys-subsystem-net-devices-eth0.device
sys-devices-pci0000:00-0000:00:19.0-net-eth0.device - 82578DM Gigabit Network Connection
          Loaded: loaded
          Active: active (plugged) since Mon, 22 Aug 2011 08:05:08 -0400; 5h 8min ago
          Device: /sys/devices/pci0000:00/0000:00:19.0/net/eth0

Notice that the file has no listed source except sysfs.

diac · 2011-08-22 19:09:27

ok thank you, I have exactly the same .device file

$ systemctl status sys-subsystem-net-devices-eth0.device
sys-devices-pci0000:00-0000:00:19.0-net-eth0.device - 82577LC Gigabit Network Connection
          Loaded: loaded
          Active: active (plugged) since Mon, 22 Aug 2011 17:42:57 +0100; 2h 10min ago
          Device: /sys/devices/pci0000:00/0000:00:19.0/net/eth0

Have you any idea of something else I can look ?
Note that systemd have not make my PC faster to start, I have a black screen during few seconds before any thing is print on the screen. (Maybe there is no link ...).

falconindy · 2011-08-22 19:27:53

Can you post the output of 'systemctl -t service' after booting? Seems like maybe something is tripping up during the boot process...

tomegun · 2011-08-22 19:37:04

diac wrote:

ok thank you, I have exactly the same .device file

$ systemctl status sys-subsystem-net-devices-eth0.device
sys-devices-pci0000:00-0000:00:19.0-net-eth0.device - 82577LC Gigabit Network Connection
          Loaded: loaded
          Active: active (plugged) since Mon, 22 Aug 2011 17:42:57 +0100; 2h 10min ago
          Device: /sys/devices/pci0000:00/0000:00:19.0/net/eth0

Have you any idea of something else I can look ?

Could you compare udevadm info with systemd and sysvinit? There should not be a difference (except for the last two systemd lines of course).

diac · 2011-08-22 21:26:36

After boot for 'systemctl -t service' I have :

$ systemctl -t service
UNIT                      LOAD   ACTIVE SUB     JOB DESCRIPTION
acpid.service             loaded active running     ACPI event daemon
console-...daemon.service loaded active running     Console Manager
console-...-start.service loaded active exited      Console System Startup Logging
cronie.service            loaded active running     Periodic Command Scheduler
dbus.service              loaded active running     D-Bus System Message Bus
getty@tty1.service        loaded active running     Getty on tty1
ip6tables.service         loaded active exited      IPv6 Packet Filtering Framework
iptables.service          loaded active exited      Packet Filtering Framework
kdm.service               loaded active running     K Display Manager
laptop-mode-tools.service loaded active exited      Laptop Power Saving Tools
lm_sensors.service        loaded active exited      Initialize hardware monitoring sensors
ntpd.service              loaded active running     Network Time Service
rc-local.service          loaded active exited      /etc/rc.local Compatibility
remount-rootfs.service    loaded active exited      Remount Root FS
rsyslog.service           loaded active running     System Logging Service
sshd.service              loaded active running     OpenSSH Daemon
systemd-logger.service    loaded active running     Stdio Syslog Bridge
systemd-logind.service    loaded active running     Login Service
systemd-...s-load.service loaded active exited      Load Kernel Modules
systemd-...ollect.service loaded active exited      Collect Read-Ahead Data
systemd-...replay.service loaded active exited      Replay Read-Ahead Data
systemd-...pi-vfs.service loaded active exited      Remount API VFS
systemd-sysctl.service    loaded active exited      Apply Kernel Variables
systemd-...-setup.service loaded active exited      Recreate Volatile Files and Directories
systemd-...ssions.service loaded active exited      Permit User Sessions
systemd-...-setup.service loaded active exited      Setup Virtual Console
udev-trigger.service      loaded active exited      udev Coldplug all Devices
udev.service              loaded active running     udev Kernel Device Manager
wicd.service              loaded active running     Wicd Network Manager

For the comparison of the udevadm it's very strange ! I have make the test twice for each(sysV et systemd) and the every time the interface is tagged :

E: TAGS=:systemd:

Is it normal ?

The complet comparaison :

#Systemd
P: /devices/pci0000:00/0000:00:19.0/net/eth0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:19.0/net/eth0
E: INTERFACE=eth0
E: IFINDEX=2
E: SUBSYSTEM=net
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=82577LC Gigabit Network Connection
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x10eb
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:

#Sys V
P: /devices/pci0000:00/0000:00:19.0/net/eth0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:19.0/net/eth0
E: INTERFACE=eth0
E: IFINDEX=3
E: SUBSYSTEM=net
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=82577LC Gigabit Network Connection
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x10eb
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:

Thank you for your help

tomegun · 2011-08-22 21:45:29

diac wrote:

For the comparison of the udevadm it's very strange ! I have make the test twice for each(sysV et systemd) and the every time the interface is tagged :
E: TAGS=:systemd:
Is it normal ?

Ah, my bad. This is expected (I just got myself confused). The systemd udev rules are of course applied regardless of systemd running.

I really don't get what is going on here, but I don't think udev is the one causing problems...

Arch Linux

#901 2011-08-14 19:27:18

Re: systemd: Yet Another Init Replacement

#902 2011-08-14 19:57:36

Re: systemd: Yet Another Init Replacement

#903 2011-08-14 21:58:47

Re: systemd: Yet Another Init Replacement

#904 2011-08-16 18:31:34

Re: systemd: Yet Another Init Replacement

#905 2011-08-16 20:51:05

Re: systemd: Yet Another Init Replacement

#906 2011-08-19 10:44:18

Re: systemd: Yet Another Init Replacement

#907 2011-08-19 10:59:56

Re: systemd: Yet Another Init Replacement

#908 2011-08-19 12:57:01

Re: systemd: Yet Another Init Replacement

#909 2011-08-19 13:04:34

Re: systemd: Yet Another Init Replacement

#910 2011-08-19 13:52:33

Re: systemd: Yet Another Init Replacement

#911 2011-08-19 21:20:23

Re: systemd: Yet Another Init Replacement

#912 2011-08-19 21:57:47

Re: systemd: Yet Another Init Replacement

#913 2011-08-20 15:45:26

Re: systemd: Yet Another Init Replacement

#914 2011-08-20 16:05:15

Re: systemd: Yet Another Init Replacement

#915 2011-08-20 16:16:23

Re: systemd: Yet Another Init Replacement

#916 2011-08-21 23:40:12

Re: systemd: Yet Another Init Replacement

#917 2011-08-22 10:39:44

Re: systemd: Yet Another Init Replacement

#918 2011-08-22 13:29:21

Re: systemd: Yet Another Init Replacement

#919 2011-08-22 16:20:44

Re: systemd: Yet Another Init Replacement

#920 2011-08-22 17:16:13

Re: systemd: Yet Another Init Replacement

#921 2011-08-22 19:09:27

Re: systemd: Yet Another Init Replacement

#922 2011-08-22 19:27:53

Re: systemd: Yet Another Init Replacement

#923 2011-08-22 19:37:04

Re: systemd: Yet Another Init Replacement

#924 2011-08-22 21:26:36

Re: systemd: Yet Another Init Replacement

#925 2011-08-22 21:45:29

Re: systemd: Yet Another Init Replacement

Board footer