- 1 Should the section "writing a custom .service" be expanded?
- 2 Systemd defaults / to rshared, gotcha
- 3 Make section "Targets" more clearly
- 4 Section "Writing unit files" does not distinguish between overrides and new files
- 5 Subsection "dependent services are not started when starting a service manually"
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)
- The Example 1. Simple service in there (
WantedBy, where each would be explained). If we're just going to leave that to a manpage or copying a "finished" .service, the link should at least be moved to the top of the section from under #Service types. I'd still be in favor of directly linking to the examples section. --Dettalk 06:37, 24 July 2015 (UTC)
- The Example 1. Simple service in there (
- Ok, yes. Could do without. Though the last man reference is way up in another section and ending a section with a bullet always looks incomplete for my reading habit. Then ending a topic with a man reference also implies "That's all we got here and the next section is another topic". So it's a bit of a phrase, but has a good didactic purpose in my view. --Indigo (talk) 09:16, 27 July 2015 (UTC)
- The Service Types section is certainly a good comprehensive overview of the options available when writing a unit file but it may help those newer to systemd if we highlighted a little more why 'simple' is the default and that they will likely only need that option, 'oneshot' or possibly 'forking' at least to get started. Perhaps expanding on 'forking' that it is specifically for launching services that background themselves (i.e. where the parent launches a child process and terminates) might be helpful too. Table 8.10 under this section of the RedHat portal could also be a useful addition. Kal (talk) 22:01, 9 December 2015 (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.
Make section "Targets" more clearly
In general, the introductory paragraph does not explain the concept enough (it seems like one sentence is missing explaning what a target is).
Then there are some occurences of words (first in the article) which might confuse unexperienced users:
- "runlevel" - Link to Wikipedia?
- In subsection "Create custom target" Fedora is mentioned: "The runlevels that are assigned a specific purpose on vanilla Fedora installs"; This adds confusion to the first point.
Section "Writing unit files" does not distinguish between overrides and new files
If you want to override a unit, create /etc/systemd/<unit>.service.d/override.conf. (.d directories are for overriding a unit.) A new service created as override will *not* be found by systemctl daemon-reload! (Not knowing this did cost me some hours of frustration.) Instead if you want to add a new service, you need it to go straight into /etc/systemd/system. After systemctl daemon-reload you can do systemctl enable <service> or systemctl start <service>.
- And which part of Systemd#Writing_unit_files is inaccurate? Systemd#Editing_provided_unit_files says (emphasis mine):
- There are two ways to edit a unit file provided by a package: replace the entire unit file with a new one or create drop-in snippets which are applied on top of the existing unit file.
- -- Lahwaacz (talk) 19:08, 30 November 2015 (UTC)
- Nowhere in that section does it claim that a new service will be created for the override. I've tweaked the language a little bit to emphasize that both methods edit the original unit, even when you create a new file. Silverhammermba (talk) 16:45, 1 December 2015 (UTC)
Subsection "dependent services are not started when starting a service manually"
As far as I know the systemd behaviour for dependent services is a design ... decision (I'd call it a design error, but that's just me). Thus I documented the nonintuitive behaviour in the wiki instead of reporting it as bug.
Maybe the unit file for libvirtd is not correct and needs additional Wants/Requires lines. If that solves the problem, I'll update the entry and place it as clarification for writing own systemd unit files. Until then I'd suggest to keep the entry as it is.
- As per Libvirt#Daemon for a manual start of libvird, you should also start
virtlogd.service. It may be non-intuitive, but have a reason upstream split it like that. Personally, I think upstream should package an alternative
libvirtd.socketunit which starts all requires. See also redhat bug I find it non-intuitive if a .service automatically starts a socket by itself. I'd rather control such myself.
- In any case it seems the wrong example for the systemd article because of existing Libvirt#Daemon instructions in my view.
- . You still disagree? --Indigo (talk) 10:17, 19 May 2016 (UTC)