Systemd 212 Brings Remote Journals, Other New Features

[Rexilion]

The /dev/dm-X is for consistant device nameing. You should still have a /dev/vgX/lvX that are soft link pointing back to dev/dm-X. Similar to how hard drives are mapped to /dev/sdX and all the items under /dev/disk are soft links back to the /dev/sdX nodes. If that is not happening, then I suspect the udev rules are incorrect, or something isn't installed correctly.

Yeah, I think it has something to do with systemD not being a first class init in Gentoo.

[FishB8]

Anyway, personal experience: I installed systemd on my Gentoo box to get back consolekit functionality. I tried to use it as init system, but once it mounted my LVM devices as /dev/dm-X it was quickly reduced to just udev/logind provider. I don't care who is responsible for the mess (systemd devs or gentoo maintainers). Such idiocies have no place in a modern system (why the hell does LVM have a vg/lv naming option if nto for clarity ? /dev/dm-X is not clear at all).

The /dev/dm-X is for consistant device nameing. You should still have a /dev/vgX/lvX that are soft link pointing back to dev/dm-X. Similar to how hard drives are mapped to /dev/sdX and all the items under /dev/disk are soft links back to the /dev/sdX nodes. If that is not happening, then I suspect the udev rules are incorrect, or something isn't installed correctly.

[Rexilion]

Thanks for the tip, but it is a systemd thing. When I boot the exact same system with OpenRC, I get proper LVM names. I simply change the int/real_init parameter between systemd and OpenRC and the device names changed. Nothing else changed.

Also once I mounted something manually (i.e. mount /boot) after login, the device name was correct. So the service that mounts fstab at startup does some extra processing bullshit that should not be there.

My guess would be that the seperate udev for openrc is using different rulesets than the systemd installation. But that would be a guess, I'm not sure.

It's odd though, you can configure this with the files in rules.d. Your observations are contradicting my statement, but are indeed 'remarkable'.

[haplo602]

+1

So, it's not a systemd thing. You can probably get rid of this behaviour by emerging lvm2 without the udev useflag.

Thanks for the tip, but it is a systemd thing. When I boot the exact same system with OpenRC, I get proper LVM names. I simply change the int/real_init parameter between systemd and OpenRC and the device names changed. Nothing else changed.

Also once I mounted something manually (i.e. mount /boot) after login, the device name was correct. So the service that mounts fstab at startup does some extra processing bullshit that should not be there.

[Rexilion]

One very simple reason: SINGLE POINT OF FAILURE !!!!

The classic Unix approach eliminates SPOFs and gives you a wide choice of tools to use. Systemd is the exact opposite (I'd call it the Microsoft way of doing things).

+1

Anyway, personal experience: I installed systemd on my Gentoo box to get back consolekit functionality. I tried to use it as init system, but once it mounted my LVM devices as /dev/dm-X it was quickly reduced to just udev/logind provider.

SystemD is not a first class init in Gentoo.

I don't care who is responsible for the mess (systemd devs or gentoo maintainers). Such idiocies have no place in a modern system (why the hell does LVM have a vg/lv naming option if nto for clarity ? /dev/dm-X is not clear at all).

I have 13-dm-disk.rules in udev's rules.d which does something like this:

[gebruiker@delta rules.d]$ find /dev/disk
/dev/disk
/dev/disk/by-path
/dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:3
/dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:2
/dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:1
/dev/disk/by-path/pci-0000:00:10.3-usb-0:5:1.0-scsi-0:0:0:0
/dev/disk/by-uuid
/dev/disk/by-uuid/9f405c34-354a-4be4-8075-ff23bd04915e
/dev/disk/by-uuid/ac570999-667e-498c-93d1-410bf87f09be
/dev/disk/by-uuid/d2b6004b-3195-4923-a803-67cac80e7d91
/dev/disk/by-uuid/04bca290-b4c2-4af6-bbf0-3738a066f501
/dev/disk/by-uuid/ec88f772-09cc-4fd7-8220-51e8fcab8152
/dev/disk/by-uuid/bc20c5fa-8463-487f-ba81-aefa0a97f06d
/dev/disk/by-uuid/6cc7990a-8185-441a-b90d-c73a25f7d4cc
/dev/disk/by-uuid/a681d6e9-ba0b-473f-80df-5f355f155272
/dev/disk/by-id
/dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:3
/dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:2
/dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:1
/dev/disk/by-id/usb-_USB_2.0_Reader_1936120000D9-0:0
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkIWLSk8BehahDfcoSTbtXW8eNIZGtGq1o
/dev/disk/by-id/dm-name-main-swap
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkWUCHMRwC2pV88D50ntqFodI6nePy8ba4
/dev/disk/by-id/dm-name-main-home
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkk53pzq4IRrxYD114GQOBJeTvBxEVw3br
/dev/disk/by-id/dm-name-main-linux--src
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkApMkELF1wFMhFyd2Irr1u916JXgjMhVM
/dev/disk/by-id/dm-name-main-opt
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDktIgtT0Fhft2tYl7cJmKBO5Xm6rV0efdr
/dev/disk/by-id/dm-name-main-etc
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkaUDjXh317t3AVfLZxkmktuVw8YZYXPiZ
/dev/disk/by-id/dm-name-main-usr
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDks1awxSE20rxvSNNv8RQZY1NWLBFwfNLa
/dev/disk/by-id/dm-name-main-boot
/dev/disk/by-id/dm-uuid-LVM-Wy8pjpX6RWUI2GdTbSrc2UIMtPkUAYDkSrDfoUpX3EyLQJHQuI1GnlVc0C45Etjw
/dev/disk/by-id/dm-name-main-var
/dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610-part1
/dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610-part3
/dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610-part2
/dev/disk/by-id/ata-WDC_WD800BB-00DKA0_WD-WCAHL2411610
/dev/disk/by-id/ata-PHILIPS_CDRWDVD3210_AH510308012818

And it's ./10-dm.rules which creates the /dev/dm-* nodes:

# Udev rules for device-mapper devices.
#
# These rules create a DM control node in /dev/mapper directory.
# The rules also create nodes named dm-x (x is a number) in /dev
# directory and symlinks to these nodes with names given by
# the actual DM names.

[gebruiker@delta rules.d]$ pacman -Q -o ./13-dm-disk.rules
./13-dm-disk.rules is owned by device-mapper 2.02.105-2
[gebruiker@delta rules.d]$ pacman -Q -o ./10-dm.rules
./10-dm.rules is owned by device-mapper 2.02.105-2

In Arch, these are part of the device-mapper package. In Gentoo, these are part of the lvm2 ebuild. Inside the lvm2 tarball they are located under the udev directory.

So, it's not a systemd thing. You can probably get rid of this behaviour by emerging lvm2 without the udev useflag.

[haplo602]

Consider it this way - on classic Unix, you have a variety of different daemons (e.g inetd, crond, atd) running at all times, all of them with the exact same job, that of starting other processes in response to some event.

In systemd, we have one daemon that's designed for the task of starting other processes in response to various events - all that's happened here is that it's gained support for a new type of event (i.e time-based). Why would you want separate daemons for each event (e.g connection, recurring timer, one-short timer), when the core function of each of them is identical?

One very simple reason: SINGLE POINT OF FAILURE !!!!

The classic Unix approach eliminates SPOFs and gives you a wide choice of tools to use. Systemd is the exact opposite (I'd call it the Microsoft way of doing things).

Anyway, personal experience: I installed systemd on my Gentoo box to get back consolekit functionality. I tried to use it as init system, but once it mounted my LVM devices as /dev/dm-X it was quickly reduced to just udev/logind provider. I don't care who is responsible for the mess (systemd devs or gentoo maintainers). Such idiocies have no place in a modern system (why the hell does LVM have a vg/lv naming option if nto for clarity ? /dev/dm-X is not clear at all).

[Delgarde]

So, it just assimilated anacron and any syslog daemon with a network broadcast option. I do like systemD, but why the duplication? What can systemD do better than anacron?

Consider it this way - on classic Unix, you have a variety of different daemons (e.g inetd, crond, atd) running at all times, all of them with the exact same job, that of starting other processes in response to some event.

In systemd, we have one daemon that's designed for the task of starting other processes in response to various events - all that's happened here is that it's gained support for a new type of event (i.e time-based). Why would you want separate daemons for each event (e.g connection, recurring timer, one-short timer), when the core function of each of them is identical?

[Teho]

But yeah, these are just some of the things. I can probably think of more if I read every single systemd manpage

Here's Lennart's take on the subject:

So, here's why you want systemd time events:

*systemd timer events allow you to make use of the same execution parameters of any other systemd service, which means you can limit resources, change users/group ids, set nice values, oom score, IO scheduling class, IO scheduling priority, CPU scheduling policy, CPU scheduling priority, CPU affinity, umask, timer slack, capabilities, secure bits, control group memberships, control group attributes, network access, private /tmp, namespaces, system call filters, ... individually for each job.

*As the services started by a timer unit is a normal service it can pull in arbitrary dependencies on activation. That means you can actually sanely write cron jobs that depend on what they need.

*As timer events are just one way to activate a unit you can actually combine that, so that you can spawn a service triggered by different events. Think: there's now a sane way to invoke something on the command line + at boot + if hw is plugged in + on a time event or if the user starts it explicitly, and the service will be executed in the exact same environment.

*As timer events are just like any other units you now have a sane way to enable and disable them: "systemctl enable" and "systemctl disable".

*All output of systemd timer events ends up in the logs, and is indexed by the event.

*systemd can schedule time events both on monotonic times (think: run something every so and so often regardless of timzones, DST, the user mucking with the clock, broken clock, clock battery gone...) and on calendar times.

*systemd calendar time events are more fine grained than cron (1s precision)

*systemd calendar time events are more expressive (you can have repetitive and non-repetitive events, you can match on years, and you can actually match a week day at the same time as a day of month). And also I'd claim they are easier to write and especially read than cron time events. (See the lower part of http://www.freedesktop.org/software/...temd.time.html[1] for details)
the systemd timer scheduling is a bit more energy efficient as systemd wakes up the CPU only when the timer elapsed, and not repeatedly as cron does

*In cron if you wanted to avoid that slow running services are spawned multiple times you had to invent your own locking in the job. In systemd that's implicit, as the trigger is just a trigger, and the service will never be started at once.

*You can even express timer events that are scheduled based on the finish time of the previous execution, i.e. for example to say that there should always be 1h between executions, even if each of them takes 2h.

*You can combine timer events easily. e.g. "5 min after bootup + every day at 6am".

*You now have a nice way to stop/kill a cronjob (and all its children), and only that one cron job, with "systemctl stop" and "systemctl start"

*You now have a nice way how you can figure out to which cronjob a process belongs to, "ps xawf -eo pid,user,cgroup,args".

*External programs can query all details about timers and the jobs. Execution status, when they ran the last time, and so on. There's a pretty complete, documented API for that exposed on the bus.

*We now track failed cron jobs nicely, and just typing "systemctl show" will show them to you.

*You now can establish cronjobs only in certain system states. For example, you can queue a cronjob only if the network is up, or suchlike. Think of cronjobs that are pulled in by the equivalent of classic sysv runlevels, only.

*And yeah, the scheme makes timer events uniform with other triggers, so it's simpler to understand for newcomers...

The interesting bit about all of this is that the code necessary for implementing all of this is pretty short, since all the complex bits (spawning/supervising a process in a precisely defined execution environment, pulling in deps...) is just the stuff we do anyway for normal services. The only additions for supporting timer events, was basically a parser for the timer expression language and a bit of code to tell the kernel to actually wake up systemd when the timer triggers.
So, yeah, the code we had to write was small, the benefits gained throught it are substantial, so we did it.
I figure embedded people will start making use of all of this first.

-Source

[renkin]

So, it just assimilated anacron and any syslog daemon with a network broadcast optionfio like systemD, but why the duplication? What can systemD do better than anacron?

Things systemd timers do better than anacron would be that they're part of systemd and thus share all the benefits of systemd units. That is to say that in addition to being a timer (anacron functionality) they have the benefit of systemd logging, process management, resource management, dependency tracking, activation conditions (ConditionPathExists, ConditionACPower and so on), actions to take on failure or different actions based on exit code. timers not only activate service files, but can also activate targets which in turn activate all the enabled units associated with that target so you can have timers activating a suite of services and jobs.

But yeah, these are just some of the things. I can probably think of more if I read every single systemd manpage

[BSDude]

I was hoping for systemd-pacmand. Last year the Arch Linux Team made a pretty funny April fools joke about how they envision pacman to integrate with systemd.

It would be funny if they'd do another one this year also based on SystemD!