Difference between revisions of "Talk:Systemd"

From ArchWiki
Jump to: navigation, search
m (Should the section "writing a custom .service" be expanded?: improve formatting)
(Re: talk...)
 
(137 intermediate revisions by 31 users not shown)
Line 1: Line 1:
== LVM2 section ==
 
The section on LVM is incorrect. There is no lvm-monitoring.service. The proper way to enable LVM2 is through systemctl enable lvm.
 
[[User:Theking2|Theking2]] ([[User talk:Theking2|talk]]) 19:15, 13 December 2012 (UTC)
 
 
== Should the section "writing a custom .service" be expanded? ==
 
== Should the section "writing a custom .service" be expanded? ==
  
Line 12: Line 9:
 
:-- [[User:Fa2k|Fa2k]] ([[User talk:Fa2k|talk]]) 3 February 2013
 
:-- [[User:Fa2k|Fa2k]] ([[User talk:Fa2k|talk]]) 3 February 2013
  
== Display manager fails to load with fast SSD ==
+
::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.
 +
::--[[User:T.ink.er|T.ink.er]] ([[User talk:T.ink.er|talk]]) 00:42, 7 July 2014 (UTC)
  
I was having a problem with my display manager (LXDM) not loading on my laptop, which has a Sandisk Extreme SSD.
+
:::There's actually no template in the Wiki for a basic ''.service'' file. --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 12:54, 23 July 2015 (UTC)
Xorg.log would show errors like "No screens found."
+
  
I eventually figured out that the problem was that my computer was booting so fast that KMS didn't have enough time to kick in before X was started. I solved by adding the KMS driver (i915 in my case) to the initramfs.
+
::::What is a "basic" service file anyway? Since {{ic|systemd.service(5)}} contains an entire section with examples, I think that we can leave it that way. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:35, 23 July 2015 (UTC)
  
Just a tip for SSD users, not sure if it should be added to the page or not.<br> --[[User:Steev|Steev]] ([[User talk:Steev|talk]]) 16:59, 2 September 2012 (UTC)
+
:::::The [http://0pointer.de/public/systemd-man/systemd.service.html#Examples Example 1. Simple service] in there ({{ic|Description}}/{{ic|ExecStart}}/{{ic|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 [[Systemd#Service types|#Service types]]. I'd still be in favor of directly linking to the examples section. --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 06:37, 24 July 2015 (UTC)
:This is a general problem that needs to be solved in the display manager. GDM already implements the bits for the [http://cgit.freedesktop.org/systemd/systemd/commit/?id=f1a8e221ecacea23 CanGraphical] flag.
+
:-- [[User:Falconindy|Falconindy]] ([[User talk:Falconindy|talk]]) 21:34, 2 September 2012 (UTC)
+
  
== Should we add a note about CUPS under 'Transitioning from initscripts to systemd'? ==
+
::::::Good idea. That manpage itself is so huge, it sure is helpful to point to the example section explicitly. Added an earlier-on link to it with [https://wiki.archlinux.org/index.php?title=Systemd&type=revision&diff=387706&oldid=387219]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:21, 24 July 2015 (UTC)
Are there any more sockets that change?
+
  
Copied from the CUPS wiki:
+
:::::::Very nice. What about that second mention under [[systemd#Service types|#Service types]]? It starts sounding kind of "duh". --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 22:30, 24 July 2015 (UTC)
  
...
+
::::::::I've added a link also to the second section, or have you had something more radical in mind? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 25 July 2015 (UTC)
  
Systemd uses a different CUPS socket file located at:
+
:::::::::No, I meant why need a man mention there at all? Isn't it obvious from the link in the intro that all the sub-section details are also located there? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 21:12, 26 July 2015 (UTC)
  
/usr/lib/systemd/system/cups.socket
+
::::::::::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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:16, 27 July 2015 (UTC)
  
The default CUPS socket file is located at:
+
:::::::::::I agree on systemic references to the manuals. Where possible, wiki pages should introduce to the upstream documentation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:48, 27 July 2015 (UTC)
  
/var/run/cups/cups.sock
+
::::::::::::Oh, it links to [http://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= #Type]. Shouldn't it at least talk about the ''type section'' like the one in the [[systemd#Writing unit files|intro]]? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 00:38, 28 July 2015 (UTC)
  
Edit {{ic|/etc/cups/cupsd.conf}} and {{ic|/etc/cups/client.conf}} as root to use the systemd socket instead of the default.  Make sure to restart CUPS when you are done:
 
  
# systemctl restart cups
+
:::::::::::::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 [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Structure this section of the RedHat portal] could also be a useful addition. [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 22:01, 9 December 2015 (UTC)
 
+
...
+
<br>
+
-- [[User:JKAbrams|JKAbrams]] 5 November 2012
+
:This sounds more like a {{pkg|cups}} packaging bug that should just be fixed.
+
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 01:11, 8 November 2012 (UTC)
+
::It sounds like someone who doesn't have a clue about systemd. That cups.socket file is a systemd unit file of type socket, which contains the location of the socket file for CUPS (and that is still /var/run/cups/cups.sock).
+
::[[User:Raynman|Raynman]] ([[User talk:Raynman|talk]]) 22:49, 9 November 2012 (UTC)
+
  
 
== Systemd defaults / to rshared, gotcha  ==
 
== Systemd defaults / to rshared, gotcha  ==
Line 73: Line 58:
 
:You may find [http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0 this commit] useful. --[[User:David Strauss|David Strauss]] ([[User talk:David Strauss|talk]]) 22:58, 13 December 2012 (UTC)
 
:You may find [http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0 this commit] useful. --[[User:David Strauss|David Strauss]] ([[User talk:David Strauss|talk]]) 22:58, 13 December 2012 (UTC)
  
== "Error: No space left on device" when trying to start/restart a service" ==
+
== 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.
 +
 
 +
[[User:Xry|Xry]] ([[User talk:Xry|talk]]) 16:06, 9 September 2015 (UTC)
 +
 
 +
== 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>.
 +
 
 +
{{unsigned|17:48, 30 November 2015‎|Bwe}}
 +
 
 +
: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'''.
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. [[User:Silverhammermba|Silverhammermba]] ([[User talk: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.
 +
 
 +
{{unsigned|09:01, 19 May 2016‎|Vtanger}}
 +
 
 +
:As per [[Libvirt#Daemon]] for a manual start of libvird, you should also start {{ic|virtlogd.service}}. It may be non-intuitive, but have a reason upstream split it like that. Personally, I think upstream should package an alternative {{ic|libvirtd.socket}} unit which starts all requires. See also [https://bugzilla.redhat.com/show_bug.cgi?id=1290357 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? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:17, 19 May 2016 (UTC)
 +
 
 +
== <s>Journald in conjunction with syslog</s> ==
 +
 
 +
The socket described for syslog forwarding does not exist, is not created and I have no idea how to change this. --[[User:Bachsau|Bachsau]] ([[User talk:Bachsau|talk]]) 04:30, 9 December 2016 (UTC)
 +
 
 +
:As described, the {{ic|ForwardToSyslog}} option in {{ic|journald.conf}} is responsible for this. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:31, 9 December 2016 (UTC)
 +
 
 +
::Which I set to yes, then restarted journald, even rebootet the system, but there's still no socket file. --[[User:Bachsau|Bachsau]] ([[User talk:Bachsau|talk]]) 09:11, 9 December 2016 (UTC)
 +
 
 +
::Fixed it: https://bbs.archlinux.org/viewtopic.php?pid=1675288#p1675288 --[[User:Bachsau|Bachsau]] ([[User talk:Bachsau|talk]]) 06:25, 10 December 2016 (UTC)
 +
 
 +
== Removal consideration: Sandboxing application environments ==
 +
There has been systemd upstream talk: [https://lwn.net/Articles/709759/ LWN: CVE-2016-8655] and [https://lwn.net/Articles/709755/ LWN: Re: CVE-2016-8655]. Poettering discusses the same [http://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html here]. I was considering dropping this section into [[Security]] but deferred to the ''tips and tricks'' section here. If the concern is that the content is not officially enabled upstream, the counterargument is that 1. the directives used in the sandbox are provided by official systemd upstream documentation 2. the unbound.service file is an Arch-specific creation. The new [[OpenVPN]] unit files are using environment directives, but those are provided by OpenVPN upstream.  I see the section as a ''tip'' which attempts to improve upon defaults that could be of benefit to others (particularly those with long-running, network-bound services). But I am not opposed to it being moved to [[Security]] or under a more appropriate sub here (preferred). Thoughts?  -- [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 06:41, 18 January 2017 (UTC)
 +
 
 +
:File a bug against the {{Pkg|unbound}} package then? An updated service can then be linked to from here as illustration of the various directives. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:23, 18 January 2017 (UTC)
 +
 
 +
::Updated service would be neat, yes. Yet, it would miss the verbose. How about moving it to [[Capabilities]] and crosslink back? That article only has utterly simple examples so far. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:20, 19 January 2017 (UTC)
 +
 
 +
:::I was thinking on keeping the explanations, but not the code block, because more users would benefit from an updated service (at least downstream in Arch) than a diff copied in this article. I'm not sure if the scope fits within [[Capabilities]], but I leave that up to you guys. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:30, 19 January 2017 (UTC)
  
This troubleshooting section was removed because it was "totally irrelevant. Why is this irrelevant?<br>
+
::::Relocating to [[Capabilities]] will work so long as the example provides additional focus with respect to the capability directive. systemd unit files are able to provide breadth of isolation mechanisms including namespaces, overlays and seccomp. Though Unbound is but one example, I plan to add a few more including hardened unit files for dhcpcd and nftables.  Figuring out where unit file sandboxing discussion should go is up to you two. I figure that its proper location within the Wiki will become clearer as the topic is expanded upon. Move it to where you will and I will follow :) -- [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 03:50, 20 January 2017 (UTC)
--[[User:Skiguy0123|Skiguy0123]] ([[User talk:Skiguy0123|talk]]) 00:35, 11 February 2013 (UTC)
+
  
:Because that error is caused by excessive inode usage, which has nothing to do with systemd.
+
:::::You noting you want to add further examples, made me come up with an even different approach:
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 23:24, 11 February 2013 (UTC)
+
:::::# I moved the example to [[Unbound#Sandboxing]]. Note I left the remove template for the unit itself in, please consider adding a FS# for it.[https://wiki.archlinux.org/index.php?title=Unbound&type=revision&diff=465991&oldid=465990]
 +
:::::# I initialized a bullet list in [[Systemd#Sandboxing application environments]] [https://wiki.archlinux.org/index.php?title=Systemd&type=revision&diff=465996&oldid=465708]. This could be gradually expanded, be it for restricting capabilities or other related systemd features, or pinpoint also individual options (e.g. {{ic|1=ProtectSystem=strict}}).
 +
:::::What's going amiss is expanding [[capabilities]] itself a little. For {{ic|1=CapabilityBoundingSet=}} it seems more useful to to have it here really on second thought. Yet, we don't want to duplicate elaborations on capabilities themselves like you do in explaining the unbound example. Perhaps shorten it and reference capabilities(7)?
 +
:::::What do you two think about this approach? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 20 January 2017 (UTC)
 +
::::::Sounds good to me. I'll rework an example for [[capabilities]] and expand it accordingly. -- [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 04:35, 23 January 2017 (UTC)

Latest revision as of 04:35, 23 January 2017

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)
There's actually no template in the Wiki for a basic .service file. --Dettalk 12:54, 23 July 2015 (UTC)
What is a "basic" service file anyway? Since systemd.service(5) contains an entire section with examples, I think that we can leave it that way. -- Lahwaacz (talk) 15:35, 23 July 2015 (UTC)
The Example 1. Simple service in there (Description/ExecStart/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)
Good idea. That manpage itself is so huge, it sure is helpful to point to the example section explicitly. Added an earlier-on link to it with [1]. --Indigo (talk) 22:21, 24 July 2015 (UTC)
Very nice. What about that second mention under #Service types? It starts sounding kind of "duh". --Dettalk 22:30, 24 July 2015 (UTC)
I've added a link also to the second section, or have you had something more radical in mind? -- Lahwaacz (talk) 09:36, 25 July 2015 (UTC)
No, I meant why need a man mention there at all? Isn't it obvious from the link in the intro that all the sub-section details are also located there? --Dettalk 21:12, 26 July 2015 (UTC)
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)
I agree on systemic references to the manuals. Where possible, wiki pages should introduce to the upstream documentation. -- Alad (talk) 13:48, 27 July 2015 (UTC)
Oh, it links to #Type. Shouldn't it at least talk about the type section like the one in the intro? --Dettalk 00:38, 28 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)

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)

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.

Xry (talk) 16:06, 9 September 2015 (UTC)

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>.

—This unsigned comment is by Bwe (talk) 17:48, 30 November 2015‎. Please sign your posts with ~~~~!

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.

—This unsigned comment is by Vtanger (talk) 09:01, 19 May 2016‎. Please sign your posts with ~~~~!

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.socket unit 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)

Journald in conjunction with syslog

The socket described for syslog forwarding does not exist, is not created and I have no idea how to change this. --Bachsau (talk) 04:30, 9 December 2016 (UTC)

As described, the ForwardToSyslog option in journald.conf is responsible for this. -- Lahwaacz (talk) 08:31, 9 December 2016 (UTC)
Which I set to yes, then restarted journald, even rebootet the system, but there's still no socket file. --Bachsau (talk) 09:11, 9 December 2016 (UTC)
Fixed it: https://bbs.archlinux.org/viewtopic.php?pid=1675288#p1675288 --Bachsau (talk) 06:25, 10 December 2016 (UTC)

Removal consideration: Sandboxing application environments

There has been systemd upstream talk: LWN: CVE-2016-8655 and LWN: Re: CVE-2016-8655. Poettering discusses the same here. I was considering dropping this section into Security but deferred to the tips and tricks section here. If the concern is that the content is not officially enabled upstream, the counterargument is that 1. the directives used in the sandbox are provided by official systemd upstream documentation 2. the unbound.service file is an Arch-specific creation. The new OpenVPN unit files are using environment directives, but those are provided by OpenVPN upstream. I see the section as a tip which attempts to improve upon defaults that could be of benefit to others (particularly those with long-running, network-bound services). But I am not opposed to it being moved to Security or under a more appropriate sub here (preferred). Thoughts? -- Adamlau (talk) 06:41, 18 January 2017 (UTC)

File a bug against the unbound package then? An updated service can then be linked to from here as illustration of the various directives. -- Alad (talk) 07:23, 18 January 2017 (UTC)
Updated service would be neat, yes. Yet, it would miss the verbose. How about moving it to Capabilities and crosslink back? That article only has utterly simple examples so far. --Indigo (talk) 20:20, 19 January 2017 (UTC)
I was thinking on keeping the explanations, but not the code block, because more users would benefit from an updated service (at least downstream in Arch) than a diff copied in this article. I'm not sure if the scope fits within Capabilities, but I leave that up to you guys. -- Alad (talk) 20:30, 19 January 2017 (UTC)
Relocating to Capabilities will work so long as the example provides additional focus with respect to the capability directive. systemd unit files are able to provide breadth of isolation mechanisms including namespaces, overlays and seccomp. Though Unbound is but one example, I plan to add a few more including hardened unit files for dhcpcd and nftables. Figuring out where unit file sandboxing discussion should go is up to you two. I figure that its proper location within the Wiki will become clearer as the topic is expanded upon. Move it to where you will and I will follow :) -- Adamlau (talk) 03:50, 20 January 2017 (UTC)
You noting you want to add further examples, made me come up with an even different approach:
  1. I moved the example to Unbound#Sandboxing. Note I left the remove template for the unit itself in, please consider adding a FS# for it.[2]
  2. I initialized a bullet list in Systemd#Sandboxing application environments [3]. This could be gradually expanded, be it for restricting capabilities or other related systemd features, or pinpoint also individual options (e.g. ProtectSystem=strict).
What's going amiss is expanding capabilities itself a little. For CapabilityBoundingSet= it seems more useful to to have it here really on second thought. Yet, we don't want to duplicate elaborations on capabilities themselves like you do in explaining the unbound example. Perhaps shorten it and reference capabilities(7)?
What do you two think about this approach? --Indigo (talk) 19:07, 20 January 2017 (UTC)
Sounds good to me. I'll rework an example for capabilities and expand it accordingly. -- Adamlau (talk) 04:35, 23 January 2017 (UTC)