Hi, I pushed the sysvinit rc.local facility to systemd.
# cat /etc/systemd/system/multi-user.target.wants/rc-local.service [Unit] Description=/etc/rc.local Compatibility ConditionFileIsExecutable=/etc/rc.local [Service] Type=oneshot ExecStart=/usr/bin/bash /etc/rc.local TimeoutSec=0 StandardInput=tty RemainAfterExit=yes
The rc.local script displays (important) informations on the console and expects a validation with the return key.
# cat /etc/rc.local #!/bin/bash echo IMPORTANT INFORMATIONS read -s key
The informations are well displayed on console but the graphic manager starts before the keyboard confirmation...
Note that tty1 is disabled.
# ll /etc/systemd/system/getty.target.wants/ total 0 -rw-r--r-- 1 root root 0 17 mars 12:52 firstname.lastname@example.org lrwxrwxrwx 1 root root 38 2 sept. 2012 email@example.com -> /usr/lib/systemd/system/getty@.service -rw-r--r-- 1 root root 0 17 mars 12:17 firstname.lastname@example.org -rw-r--r-- 1 root root 0 17 mars 12:17 email@example.com -rw-r--r-- 1 root root 0 17 mars 12:17 firstname.lastname@example.org
How can I start the graphic manager after the keyboard confirmation?
-- Lacsap, 18 March 2013
Should the section "writing a custom .service" be expanded?
I think so.. as long as I got, this is necessary to run self-made scripts during the boot process, but this is not clear and the structure of the files is not well presented.
Moreover, when explain how to transit from the initscript, some referrals on how to move the old custom hooks in
/etc/rc.d/functions.d to be executed by systemd, should be made.
-- DarioP (talk) 12:42, 18 November 2012 (UTC)
- I think it needs to be expanded indeed. As a newbie, it is easy to grasp the concept of "put your code in rc.local", and it's not clear how to transition. Specific questions, as also mentioned by DarioP: In what directory should I place my service definition? On the examples page, there are some files named with an at-sign (
@), what difference does that make? It would be very helpful to have a complete example for running a single command at boot (my example:
echo noop > /sys/block/sdb/queue/scheduler).
- -- Fa2k (talk) 3 February 2013
- I third this motion, I had no idea what I was doing the whole time I was translating a service file. I happened to run accross this stackoverflow post that helped a lot: https://unix.stackexchange.com/questions/47695/how-to-write-startup-script-for-systemd - but I'm going to also add some edits to the section to help save other people time.
- --T.ink.er (talk) 00:42, 7 July 2014 (UTC)
Still reading up on this, so I'm not 100% solid but I discovered during the systemd transition that it defaults the / mount to rshared (see Shared subtree for definitions). Excerpted from core/mount-setup.c in systemd github:
/* Mark the root directory as shared in regards to mount * propagation. The kernel defaults to "private", but we think * it makes more sense to have a default of "shared" so that * nspawn and the container tools work out of the box. If * specific setups need other settings they can reset the * propagation mode to private if needed. */ if (detect_container(NULL) <= 0) if (mount(NULL, "/", NULL, MS_REC|MS_SHARED, NULL) < 0) log_warning("Failed to set up the root directory for shared mount propagation: %m");
This means that all bind mounts made through fstab will default to shared behavior, not private. For those users who depend on non-recursive bind mounts, this can be a very big gotcha (as the mount propagation effectively nullifies the non-recursion). I think it should be at least noted under Filesystem Mounts, since fstab bind entries definitely may not preserve behavior across the systemd transition and there are definitely some systems that would fail to start up/operate properly due to this, perhaps even silently.
As a side note, for nested bind mounts this also results in multiplicative bloat of the mount table, depending on what kind of nesting structure is used (it's actually relatively easy to construct a nesting sequence that makes 2^n mounts out of n mount calls).
Still looking into good (and easy) configuration solutions.
description of services with multiple instances (@ sign)
As a new archlinux user I found this answer on stack exchange useful for understanding what the @ sign was doing in the names of some service files.
I thought it might be a useful thing to include in the article - maybe by someone a bit more experienced than me =].
- Thanks for the suggestion, content has just been added to explain: 
- I'm closing this talk item, if something you consider important is missing, please open a new one anytime. --Indigo (talk) 16:35, 23 August 2014 (UTC)
Clarify on .service names
$ locate .service | grep /var/abs | wc -l 285
When using systemctl, you generally have to specify the complete name of the unit file, including its suffix, for example sshd.socket.
which is not very clear on names that are applicable. Adding how
.service names often match package names (unless indicated otherwise) should clarify and prevent content duplication (see e.g Talk:Tracker). -- Alad (talk) 20:37, 3 August 2014 (UTC)
- Being this issue specific to Arch, I think such a tip would fit better in a new section dedicated to services in Help:Reading as I proposed in Help talk:Style#Passing arguments to systemd units: give example commands or not?. -- Kynikos (talk) 13:38, 7 August 2014 (UTC)