Difference between revisions of "Talk:Systemd"

From ArchWiki
Jump to navigation Jump to search
m (Clarify on .service names: indent Template:App for better readability)
(Clarify on .service names: re)
Line 109: Line 109:
 
:::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 5 October 2014 (UTC)
 
:::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 5 October 2014 (UTC)
  
:::::I don't think that 2 and 3 are a good idea. Telling the user how to find the information is far more robust and dynamic than constantly trying to keep a list up-to-date. Further, I see this as no different than executables. We don't attempt to keep a list of the executable names for people to run, why keep a list of service names?
+
::::::::I don't think that 2 and 3 are a good idea. Telling the user how to find the information is far more robust and dynamic than constantly trying to keep a list up-to-date. Further, I see this as no different than executables. We don't attempt to keep a list of the executable names for people to run, why keep a list of service names?
:::::-- [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 16:38, 5 October 2014 (UTC)
+
::::::::-- [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 16:38, 5 October 2014 (UTC)
 +
 
 +
:::::::::@Indigo: I would keep the packages argument as simple as possible, so I'd prefer your second option, although comparing it with my version there's only a difference in wording over which we'd have little control in practice, if any at all, and we'd never be able to write a style rule about it.
 +
:::::::::@Scimmia: Maybe we can be liberal and simply "allow" mentioning the service names (not "encourage") when an editor feels it's convenient? The alternative would be forbidding it, but then wouldn't we be too discriminatory? Should we maintain a list of the details that shouldn't be fit into descriptions? There's already a lot of info that goes beyond a simple description of the functionality of the listed programs: '''sxlock''' is already mentioning a service; '''p7zip''' is mentioning an executable in its first entry, and an optional dependency in a duplicated entry; then I see lists of supported file formats, etc. (I've only done a quick search).
 +
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:11, 11 October 2014 (UTC)

Revision as of 05:11, 11 October 2014

Initscripts emulation

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 getty@tty1.service
lrwxrwxrwx 1 root root 38  2 sept.  2012 getty@tty2.service -> /usr/lib/systemd/system/getty@.service
-rw-r--r-- 1 root root  0 17 mars  12:17 getty@tty4.service
-rw-r--r-- 1 root root  0 17 mars  12:17 getty@tty5.service
-rw-r--r-- 1 root root  0 17 mars  12:17 getty@tty6.service

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)

Systemd defaults / to rshared, gotcha

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.

Compgamer89 (talk) 07:16, 4 December 2012 (UTC)

You may find this commit useful. --David Strauss (talk) 22:58, 13 December 2012 (UTC)

Clarify on .service names

$ locate .service | grep /var/abs | wc -l
285

Applications in List of applications implicitely assume the user knows on using units; arpwatch (arpwatch.service) to name one example. However, in Using units:

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)

That seems completely reasonable, I see no issue. --Pyroh (talk) 04:05, 4 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)
systemctl list-unit-files | grep keyword should be as folkish as pacman -Ss keyword. When the package name is already known, pacman -Ql package | grep service can be used as alternative. Perhaps this could be part of the note, but I don't think Help:Reading is the best place for it because the issue is specific only to some pages like List of applications, "normal" pages mention the service names explicitly. -- Lahwaacz (talk) 19:54, 29 September 2014 (UTC)
I concur, so I see 3 possibilities now:
1. Add a note with those commands at the top of List of applications
2. Allow/encourage indicating the service(s) name(s) directly in the list entries' descriptions, where applicable, for example:
  • Arpwatch — Provides arpwatch@.service, which monitors ethernet activity and keeps a database of Ethernet/IP address pairings.
http://ee.lbl.gov/ || arpwatch
3. Encourage to add the service(s) to Daemons List.
I think I like 2 the most.
-- Kynikos (talk) 03:03, 1 October 2014 (UTC)
I vote for (1.). While (2.) may be helpful, I think it is too static and make maintaining a short description in one sentence cumbersome. For example, maybe next week an arpwatch.socket unit is packaged as well with arpwatch or the package comes with a number (non-/instantiated, oneshot) of services already.
I'd also vote for adding a general sentence about (1.) to the Help:Reading#Control of systemd units section, clarifying the services either come with vanilla units or specific systemd services for Arch and how to find them (with above pacman command). I don't think it hurts to have it in that general help document already. --Indigo (talk) 07:14, 1 October 2014 (UTC)
Well, if something like that happened to arpwatch, it would probably make it worth to create a dedicated article explaining all that. I think that in practice (1.) would be ignored by many, and it would be ineffective at preventing the creation (or facilitating the merge) of short stubs with just the service name as useful content.
I agree that (1.) could be already applied to Help:Reading#Control of systemd units instead.
-- Kynikos (talk) 03:18, 5 October 2014 (UTC)
Hm, true, it would probably be ignored. Maybe (1.) should be helpful guidance and (2.) for specifics at the same time. If we go for (2.) though, maybe the service could be placed a little more in the background. In the end it is the tool that is important for the description and not that it comes packaged with a systemd unit. Plus, the first link in template App makes internal links (to existing articles) and external (wikipedia for arpwatch) look alike; mentioning a service right after it might be confusing. Maybe we could use for (2.) either:
  • Arpwatch — Tool that monitors ethernet activity and keeps a database of Ethernet/IP address pairings.
http://ee.lbl.gov/ || arpwatch provides arpwatch@.service
(which might lead to unnecessary unit additions for packages which have a dedicated article), or
  • Arpwatch — Tool that monitors ethernet activity and keeps a database of Ethernet/IP address pairings (provides arpwatch@.service).
http://ee.lbl.gov/ || arpwatch
--Indigo (talk) 09:57, 5 October 2014 (UTC)
I don't think that 2 and 3 are a good idea. Telling the user how to find the information is far more robust and dynamic than constantly trying to keep a list up-to-date. Further, I see this as no different than executables. We don't attempt to keep a list of the executable names for people to run, why keep a list of service names?
-- Scimmia (talk) 16:38, 5 October 2014 (UTC)
@Indigo: I would keep the packages argument as simple as possible, so I'd prefer your second option, although comparing it with my version there's only a difference in wording over which we'd have little control in practice, if any at all, and we'd never be able to write a style rule about it.
@Scimmia: Maybe we can be liberal and simply "allow" mentioning the service names (not "encourage") when an editor feels it's convenient? The alternative would be forbidding it, but then wouldn't we be too discriminatory? Should we maintain a list of the details that shouldn't be fit into descriptions? There's already a lot of info that goes beyond a simple description of the functionality of the listed programs: sxlock is already mentioning a service; p7zip is mentioning an executable in its first entry, and an optional dependency in a duplicated entry; then I see lists of supported file formats, etc. (I've only done a quick search).
-- Kynikos (talk) 05:11, 11 October 2014 (UTC)