[systemd-devel] [PATCH v3] systemd.service(5): add some simple examples
Christian Seiler
christian at iwakd.de
Tue Jan 27 13:10:44 PST 2015
Am 27.01.2015 um 21:45 schrieb Lennart Poettering:
> On Tue, 27.01.15 17:45, Christian Seiler (christian at iwakd.de) wrote:
>> + <para>Note that systemd assumes here that the
>> + program will continue running in the foreground
>> + as long as it's active. If the program
>
> I think "foreground" vs. "background" here is probably something to
> avoid. These are services after all, and hence kinda "background" in
> all cases. I am not sure how to explain this better though... Maybe
> clarify that the program does not fork on its own, and that the
> process systemd starts stays running until the very end of the
> daemon, or so.
Yes, you are completely right. I've kept the use of 'background' at some
places, but specifically avoided foreground, since that is really,
really misleading. I've also rephrased the paragraph in question. I hope
that's better.
>> + <para>Note that systemd will consider the unit
>> + to be in the state 'starting' until the program
>> + has terminated, so ordered dependencies will
>> + wait for the program to finish before starting
>> + themselves. The unit will revert to the
>> + 'inactive' state after the execution is
>> + done. That means another request to start the
>> + unit will perform the action again.</para>
>
> It might be worth also mentioning here that the the unit this way will
> never actually be "active". It will go directly from "activating" to
> "inactive", which might be surprising!
Thanks for the pointer, done!
Now I also mentioned something about multiple ExecStart= for oneshot
units, which might be useful there.
>> + <para>Similarly to the oneshot services, there
>> + are sometimes units that need to execute a
>> + program to set up something and then execute
>> + another to shut it down, but no process remains
>> + active while they are considered
>> + 'started'. Network configuration can sometimes
>> + fall into this category.</para>
>
> Another reason to use RemainAfterExit= are services that shall not
> execute again and again when they are pulled in, but only the first
> time...
Mentioned that, thanks!
>> <varname>RemainAfterExit=</varname><option>dbus</option>
>
> Typo. Should be Type=, not RemainAfterExit=
*hehe* fixed.
>> + <example>
>> + <title>Deferred (idle) services</title>
>
> Hmm, I wonder if we maybe should remove this part. Idle services are
> kinda exotic, and I figure people might be tempted to misuse them. I
> think this might be something to document at the description of Type=,
> but not push people towards using this beyond that.
When I started writing this, I didn't just want to copy the getty
service (people can look that up anyway), so I decided to come up with
something else. However, once I wrote that unit, I realized that this
could have easily just been a Type=oneshot, RemainAfterExit=yes,
After=multi-user.target unit and have the same effect, and be a lot more
consistent with the rest of the way of doing things...
Type=idle is basically really just for gettys or something extremely
similar (like other interactive apps on VTs) that also get automatically
restarted.
Since these examples are supposed to provide a starting point for people
on how to write services, I've removed the section completely, and I
think this kind of special internal thing should remain in the reference
documentation.
v3 attached, I also fixed one or two other minor typos I noticed.
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-systemd.service-5-add-some-simple-examples.patch
Type: text/x-patch
Size: 15384 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150127/d3c07ca4/attachment-0001.bin>
More information about the systemd-devel
mailing list