Difference between revisions of "Talk:Systemd"

From ArchWiki
Jump to: navigation, search
m (Initscripts emulation: add user's signature)
(Should the section "writing a custom .service" be expanded?: - proposal to add extra detail to the Service Types section.)
 
(93 intermediate revisions by 21 users not shown)
Line 1: Line 1:
== Initscripts emulation ==
+
== Should the section "writing a custom .service" be expanded? ==
  
Hi, I pushed the sysvinit rc.local facility to systemd.
+
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.
  
# cat /etc/systemd/system/multi-user.target.wants/rc-local.service
+
Moreover, when explain how to transit from the initscript, some referrals on how to move the old custom hooks in {{ic|/etc/rc.d/functions.d}} to be executed by systemd, should be made.<br>
[Unit]
+
-- [[User:DarioP|DarioP]] ([[User talk:DarioP|talk]]) 12:42, 18 November 2012 (UTC)
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.
+
: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 ({{ic|@}}), what difference does that make? It would be very helpful to have a complete example for running a single command at boot (my example: {{ic|echo noop > /sys/block/sdb/queue/scheduler}}).
 +
:-- [[User:Fa2k|Fa2k]] ([[User talk:Fa2k|talk]]) 3 February 2013
  
# cat /etc/rc.local
+
::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.
#!/bin/bash
+
::--[[User:T.ink.er|T.ink.er]] ([[User talk:T.ink.er|talk]]) 00:42, 7 July 2014 (UTC)
echo IMPORTANT INFORMATIONS
+
read -s key
+
  
The informations are well displayed on console but the graphic manager starts before the keyboard confirmation...
+
:::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)
  
Note that tty1 is disabled.
+
::::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)
# 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? <br>
+
:::::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)
-- [[User:Lacsap|Lacsap]], 18 March 2013
+
  
== Should the section "writing a custom .service" be expanded? ==
+
::::::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)
  
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.
+
:::::::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)
  
Moreover, when explain how to transit from the initscript, some referrals on how to move the old custom hooks in {{ic|/etc/rc.d/functions.d}} to be executed by systemd, should be made.<br>
+
::::::::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)
-- [[User:DarioP|DarioP]] ([[User talk: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 ({{ic|@}}), what difference does that make? It would be very helpful to have a complete example for running a single command at boot (my example: {{ic|echo noop > /sys/block/sdb/queue/scheduler}}).
+
:::::::::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)
:-- [[User:Fa2k|Fa2k]] ([[User talk:Fa2k|talk]]) 3 February 2013
+
 
 +
::::::::::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)
 +
 
 +
:::::::::::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)
 +
 
 +
::::::::::::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)
 +
 
 +
 
 +
:::::::::::::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)
  
 
== Systemd defaults / to rshared, gotcha  ==
 
== Systemd defaults / to rshared, gotcha  ==
Line 68: 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)
  
== <s>Disputed groups section</s> ==
+
== Make section "Targets" more clearly ==
This template/warning should be removed. If there is a genuine dispute, then there should be accompanying material, ie., arguments and evidence, on this page.
+
 
+
[[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 23:02, 18 March 2013 (UTC)
+
 
+
: Done. [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 22:20, 23 March 2013 (UTC)
+
  
::Closing.
+
In general, the introductory paragraph does not explain the concept enough (it seems like one sentence is missing explaning what a target ''is'').
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 18:35, 22 April 2013 (UTC)
+
  
==systemd no longer supports initscripts==
+
Then there are some occurences of words (first in the article) which might confuse unexperienced users:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=53d05b44f17db67d644069600e4b5bbca88d21e7 <br>
+
* "runlevel" - Link to Wikipedia?
-- [[User:D garbage|D garbage]]
+
* 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.
  
: Please add your signature next time by typing four tildes ({{ic|<nowiki>~~~~</nowiki>}})
+
[[User:Xry|Xry]] ([[User talk:Xry|talk]]) 16:06, 9 September 2015 (UTC)
: 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?
+
:-- [[User:65kid|65kid]] ([[User talk:65kid|talk]]) 10:16, 24 March 2013 (UTC)
+
  
::Considering that, on multiple occasions, I've seen people come into the #archlinux channel on IRC and state that they haven't updated their systems for almost a year, I think we should keep this info in the wiki for a couple more months at least.
+
== Section "Writing unit files" does not distinguish between overrides and new files ==
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 19:53, 24 March 2013 (UTC)
+
  
:::To clarify what I said previously, I mean that we should keep the "migrating from initscripts to systemd" information around for a while. I have no problem with removing information about initscripts that is not in the context of migrating to systemd.
+
If you want to override a unit, create /etc/systemd/<unit>.service.d/override.conf. (.d directories are for overriding a unit.)
:::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 18:39, 22 April 2013 (UTC)
+
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>.
  
==Duplication of content in Native configuration section==
+
{{unsigned|17:48, 30 November 2015‎|Bwe}}
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:
+
*<s>[[systemd#Hostname]] and [[Network Configuration#Set the hostname]]</s>
+
*[[systemd#Locale]] and [[Locale]] ([[Locale]] is not yet mentioning ''localectl'' though)
+
*[[systemd#Virtual console]] and [[KEYMAP]] ([[KEYMAP]] is not yet mentioning ''localectl'' though)
+
*<s>[[systemd#Time zone]] and [[Time#Time Zone]]</s>
+
*[[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.
+
: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)
  
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 13 April 2013 (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)
: +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. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 12:52, 14 April 2013 (UTC)
+
::Thanks, started with [[systemd#Hostname]], any help will be appreciated of course, I think there are also other sections that can be moved out. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:15, 15 April 2013 (UTC)
+

Latest revision as of 22:02, 9 December 2015

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)