- 1 Initscripts emulation
- 2 Should the section "writing a custom .service" be expanded?
- 3 Systemd defaults / to rshared, gotcha
- 4 systemd no longer supports initscripts
- 5 Duplication of content in Native configuration section
- 6 Section on Suspend/Resume Service Files
- 7 Section "Editing provided unit files"
- 8 systemd 204 and /bin/systemd
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
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.
systemd no longer supports initscripts
- Please add your signature next time by typing four tildes (
- Anyway, I think it may be worth considering to remove all initscripts related sections. Initscripts has been unsupported for almost half a year now, whoever still hasn't switched is screwed anyway. About time this article gets a little shorter. Other opinions?
- -- 65kid (talk) 10:16, 24 March 2013 (UTC)
Duplication of content in Native configuration section
I don't remember if this topic has already been discussed here, but it seems to me that systemd#Native configuration is duplicating information that IMO better belongs to other articles:
systemd#Hostname and Network Configuration#Set the hostname systemd#Locale and Locale (Locale is not yet mentioning localectl though)
- systemd#Virtual console and KEYMAP (KEYMAP is not yet mentioning localectl though)
systemd#Time zone and Time#Time Zone
- systemd#Hardware clock and Time (this would be a good chance to update Time)
- systemd#Kernel modules and Kernel modules
- systemd#Automount and fstab
- systemd#LVM and LVM
I would suggest removing all these sections or replacing them with links to the reported articles, possibly merging any information that those articles are missing.
- +1 for move them out. They are in a central page because at that time, initscripts is the only init supported. Now when a user want to know how to set up LVM, LVM is the natual target. Very few of them will ever goto Systemd and go to LVM section. -- Fengchao (talk) 12:52, 14 April 2013 (UTC)
Section on Suspend/Resume Service Files
I have the slight suspicion that the service files posted in the section Systemd#Suspend.2Fresume_service_files might not work. Has anybody tried them or is actually using them? --jakobh ✉ 03:12, 10 May 2013 (UTC)
Section "Editing provided unit files"
The Section Systemd#Editing_provided_unit_files says that drop in configuration files should be placed in /etc/systemd/system which goes in line with where all the other custom service files are put in. However, the systemd 198 announcement says they should be put in */etc/systemd/systemd*. Is that relevant/does it make a difference? This place is also repeated in the systemd 201 announcement. I don't get them recognised in any of these two places at the moment, but that's a different story... --jakobh ✉ 11:54, 10 May 2013 (UTC)
- /etc/systemd/systemd is simply a typo, this directory doesn't exist and doesn't have any relevance. 65kid (talk) 17:37, 10 May 2013 (UTC)
systemd 204 and /bin/systemd
- with systemd 204, the /bin/systemd symlink is not more installed; while this is correctly documented on this wiki page and warned in post-install message, this warning can be easily missed (my xp :-/), and the received message at the following boot is very little helpful
- the situation can be very disturbing for a one-PC owner, and quite disruptive for newbies
- may I suggest this change should be more explicitly warned, maybe with a flag message on the Arch Linux home page
- From experience, Archers tend to forget to check the front page and the info posted there goes unnoticed, thus it makes sense to use just a post-install message. Keeping your system functional boils down to doing certain things in certain order. There's no way to avoid breakage if you're not serious about updating often, reading pacman's output, dealing with .pacnew files etc.
- Keeping a liveCD / liveUSB on hand in case something breaks and you need to repair your system should be easy enough.
- -- Karol (talk) 09:39, 13 May 2013 (UTC)
- If you miss a post-install message, that's your own fault.
- That symlink was only used for the migration to systemd. Once you move over, you don't need it anymore.
- Anyone that's installed in the last 7 months would already have systemd-sysvcompat installed, so this symlink was meaningless to them.
- The Wiki has said to use /usr/lib/systemd/systemd for a long time now.
- What does this have to to with the systemd Wiki page? This talk page is to discuss changes to the Wiki page, not general gripes or suggestions about a package.