Discussion:
[ANNOUNCE] systemd v229
(too old to reply)
Lennart Poettering
2016-02-11 16:50:08 UTC
Permalink
Heya!

I just tagged the v229 release of systemd. Enjoy!

CHANGES WITH 229:

* The systemd-resolved DNS resolver service has gained a substantial
set of new features, most prominently it may now act as a DNSSEC
validating stub resolver. DNSSEC mode is currently turned off by
default, but it is expected that this is turned on by default in one
of the next releases. For now, we invite everybody to test the DNSSEC
logic by setting DNSSEC=allow-downgrade in
/etc/systemd/resolved.conf. The service also gained a full set of
D-Bus interfaces, including calls to configure DNS and DNSSEC
settings per link (for consumption by external network management
software). systemd-resolved (and systemd-networkd along with it) now
know to distinguish between "search" and "routing" domains. The
former are used to qualify single-label names, the latter are purely
used for routing lookups within certain domains to specific
links. resolved will now also synthesize RRs for all entries from
/etc/hosts.

* The systemd-resolve tool (which is a client utility for
systemd-resolved, and previously experimental) has been improved
considerably and is now fully supported and documented. Hence it has
moved from /usr/lib/systemd to /usr/bin.

* /dev/disk/by-path/ symlink support has been (re-)added for virtio
devices.

* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(including stacktrace extraction) from a new instantiated service
systemd-***@.service, instead of directly from the
/proc/sys/kernel/core_pattern hook we provide. This is beneficial as
processing large coredumps can take up a substantial amount of
resources and time, and this previously happened entirely outside of
systemd's service supervision. With the new logic the core_pattern
hook only does minimal metadata collection before passing off control
to the new instantiated service, which is configured with a time
limit, a nice level and other settings to minimize negative impact on
the rest of the system. Also note that the new logic will honour the
RLIMIT_CORE setting of the crashed process, which now allows users
and processes to turn off coredumping for their processes by setting
this limit.

* The RLIMIT_CORE resource limit now defaults to "unlimited" for PID 1
and all forked processes by default. Previously, PID 1 would leave
the setting at "0" for all processes, as set by the kernel. Note that
the resource limit traditionally has no effect on the generated
coredumps on the system if the /proc/sys/kernel/core_pattern hook
logic is used. Since the limit is now honoured (see above) its
default has been changed so that the coredumping logic is enabled by
default for all processes, while allowing specific opt-out.

* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.

* The systemd-activate socket activation testing tool gained support
for SOCK_DGRAM and SOCK_SEQPACKET sockets using the new --datagram
and --seqpacket switches. It also has been extended to support both
new-style and inetd-style file descriptor passing. Use the new
--inetd switch to request inetd-style file descriptor passing.

* Most systemd tools now honor a new $SYSTEMD_COLORS environment
variable, which takes a boolean value. If set to false, ANSI color
output is disabled in the tools even when run on a terminal that
supports it.

* The VXLAN support in networkd now supports two new settings
DestinationPort= and PortRange=.

* A new systemd.machine_id= kernel command line switch has been added,
that may be used to set the machine ID in /etc/machine-id if it is
not initialized yet. This command line option has no effect if the
file is already initialized.

* systemd-nspawn gained a new --as-pid2 switch that invokes any
specified command line as PID 2 rather than PID 1 in the
container. In this mode PID 1 will be a minimal stub init process
that implements the special POSIX and Linux semantics of PID 1
regarding signal and child process management. Note that this stub
init process is implemented in nspawn itself and requires no support
from the container image. This new logic is useful to support running
arbitrary command lines in the container, as normal processes are
generally not prepared to run as PID 1.

* systemd-nspawn gained a new --chdir= switch for setting the current
working directory for the process started in the container.

* "journalctl /dev/sda" will now output all kernel log messages from
the specified device, in addition to all devices that are parents of
it. This should make log output about devices pretty useful, as long
as kernel drivers attach enough metadata to the log messages. (The
usual SATA drivers do.)

* The sd-journal API gained two new calls
sd_journal_has_runtime_files() and sd_journal_has_persistent_files()
that report whether log data from /run or /var has been found.

* journalctl gained a new switch "--fields" that prints all journal
record field names currently in use in the journal. This is backed
by two new sd-journal API calls sd_journal_enumerate_fields() and
sd_journal_restart_fields().

* Most configurable timeouts in systemd now expect an argument of
"infinity" to turn them off, instead of "0" as before. The semantics
from now on is that a timeout of "0" means "now", and "infinity"
means "never". To maintain backwards compatibility, "0" continues to
turn off previously existing timeout settings.

* "systemctl reload-or-try-restart" has been renamed to "systemctl
try-reload-or-restart" to clarify what it actually does: the "try"
logic applies to both reloading and restarting, not just restarting.
The old name continues to be accepted for compatibility.

* On boot-up, when PID 1 detects that the system clock is behind the
release date of the systemd version in use, the clock is now set
to the latter. Previously, this was already done in timesyncd, in order
to avoid running with clocks set to the various clock epochs such as
1902, 1938 or 1970. With this change the logic is now done in PID 1
in addition to timesyncd during early boot-up, so that it is enforced
before the first process is spawned by systemd. Note that the logic
in timesyncd remains, as it is more comprehensive and ensures
montonic clocks by maintaining a persistant timestamp file in
/var. Since /var is generally not available in earliest boot or the
initrd, this part of the logic remains in timesyncd, and is not done
by PID 1.

* Support for tweaking details in net_cls.class_id through the
NetClass= configuration directive has been removed, as the kernel
people have decided to deprecate that controller in cgroup v2.
Userspace tools such as nftables are moving over to setting rules
that are specific to the full cgroup path of a task, which obsoletes
these controllers anyway. The NetClass= directive is kept around for
legacy compatibility reasons. For a more in-depth description of the
kernel change, please refer to the respective upstream commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bd1060a1d671

* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.

* A new service setting AmbientCapabilities= has been added. It allows
configuration of additional Linux process capabilities that are
passed to the activated processes. This is only available on very
recent kernels.

* The process resource limit settings in service units may now be used
to configure hard and soft limits individually.

* The various libsystemd APIs such as sd-bus or sd-event now publicly
expose support for gcc's __attribute__((cleanup())) C
extension. Specifically, for many object destructor functions
alternative versions whose names are suffixed with "p" have been
added, which take a pointer to a pointer to the object to destroy,
instead of just a pointer to the object itself. This is useful because
these destructor functions may be used directly as parameters to the
cleanup construct. Internally, systemd has been a heavy user of the
GCC extension since a long time, and with this change similar support
is now available to consumers of the library outside of systemd. Note
that by using this extension in your sources compatibility with old
and strictly ANSI compatible C compilers is lost. However, any gcc or
LLVM version of recent years have supported this extension.

* Timer units gained support for a new setting RandomizedDelaySec= that
allows configuring some additional randomized delay to the configured
time. This is useful to spread out timer events to avoid load peaks in
clusters or larger setups.

* Calendar time specifications now support sub-second accuracy.

* Socket units now support listening on SCTP and UDP-lite protocol
sockets.

* The sd-event API now comes with a full set of man pages.

* Older versions of systemd contained experimental support for
compressing journal files and coredumps with the LZ4 compressor that
was not compatible with the lz4 binary (due to API limitations of the
lz4 library). This support has been removed; only support for files
compatible with the lz4 binary remains. This LZ4 logic is now
officially supported and no longer considered experimental.

* The dkr image import logic has been removed again from importd. dkr's
micro-services focus doesn't fit into the machine image focus of
importd, and quickly got out of date with the upstream dkr API.

* Creation of the /run/lock/lockdev/ directory was dropped from
tmpfiles.d/legacy.conf. Better locking mechanisms like flock() have
been available for many years. If you still need this, you need to
create your own tmpfiles.d config file with:

d /run/lock/lockdev 0775 root lock -

Contributions from: Abdo Roig-Maranges, Alban Crequy, Aleksander
Adamowski, Alexander Kuleshov, Andreas Pokorny, Andrei Borzenkov,
Andrew Wilcox, Arthur Clement, Beniamino Galvani, Casey Schaufler,
Chris Atkinson, Chris Mayo, Christian Hesse, Damjan Georgievski, Dan
Dedrick, Daniele Medri, Daniel J Walsh, Daniel Korostil, Daniel Mack,
David Herrmann, Dimitri John Ledkov, Dominik Hannen, Douglas Christman,
Evgeny Vereshchagin, Filipe Brandenburger, Franck Bui, Gabor Kelemen,
Harald Hoyer, Hayden Walles, Helmut Grohne, Henrik Kaare Poulsen,
Hristo Venev, Hui Wang, Indrajit Raychaudhuri, Ismo Puustinen, Jakub
Wilk, Jan Alexander Steffens (heftig), Jan Engelhardt, Jan Synacek,
Joost Bremmer, Jorgen Schaefer, Karel Zak, Klearchos Chaloulos,
lc85446, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Marcel
Holtmann, Martin Pitt, Michael Biebl, Michael Olbrich, Michael Scherer,
Michał Górny, Michal Sekletar, Nicolas Cornu, Nicolas Iooss, Nils
Carlson, nmartensen, nnz1024, Patrick Ohly, Peter Hutterer, Phillip Sz,
Ronny Chevalier, Samu Kallio, Shawn Landden, Stef Walter, Susant
Sahani, Sylvain Plantefève, Tadej Janež, Thomas Hindoe Paaboel
Andersen, Tom Gundersen, Torstein Husebø, Umut Tezduyar Lindskog, Vito
Caputo, WaLyong Cho, Yu Watanabe, Zbigniew Jędrzejewski-Szmek

-- Berlin, 2016-02-11

Lennart
--
Lennart Poettering, Red Hat
Jóhann B. Guðmundsson
2016-02-11 17:32:19 UTC
Permalink
Post by Lennart Poettering
Heya!
I just tagged the v229 release of systemd. Enjoy!
* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(including stacktrace extraction) from a new instantiated service
Is it enough to disable this type service unit to completely disable
coredump or will users have to for example set Storage=none in
coredump.conf and or other tweaks and if so which ones?
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
Mikhail Kasimov
2016-02-11 17:47:34 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?
Lennart Poettering
2016-02-11 17:48:19 UTC
Permalink
Post by Mikhail Kasimov
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?
Sure, if that's how you configure things, then systemd does what you
are asking it for.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2016-02-11 18:05:46 UTC
Permalink
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?
Sure, if that's how you configure things, then systemd does what you
are asking it for
there is a difference between main-PID disappears unannounced (failure)
and "RuntimeMaxSec reached" with a clean stop
Mikhail Kasimov
2016-02-11 18:14:18 UTC
Permalink
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?
Sure, if that's how you configure things, then systemd does what you
are asking it for.
I'm staring on TimeoutStopSec= directive description and I think it's be
more logical a little bit to define RuntimeMaxSec= _only together_ with
TimeoutStopSec=.

The logic is: if unit is still active, then systemd waits for time,
defined in TimeoutStopSec=, and only after TimeoutStopSec= is hit, then
mark unit as failed. Otherwise, if unit was stopped earlier then
TimeoutStopSec=, marked as normally stopped. This looks more gentle.

So, if RuntimeMaxSec= is defined in [Service] without TimeoutStopSec=,
then systemd will ignore it. Your opinion?
Lennart Poettering
2016-02-12 20:17:33 UTC
Permalink
Post by Mikhail Kasimov
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?
Sure, if that's how you configure things, then systemd does what you
are asking it for.
I'm staring on TimeoutStopSec= directive description and I think it's be
more logical a little bit to define RuntimeMaxSec= _only together_ with
TimeoutStopSec=.
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.

Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.

Lennart
--
Lennart Poettering, Red Hat
Mikhail Kasimov
2016-02-12 20:28:31 UTC
Permalink
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an
admin specifically told the the service it could run for maximum X time
and then it should stop? ( after that time period the type unit should
be stopped cleanly basically systemctl stop foo.service and the state be
exactly the same as it yields right ? )
And if additional option Restart=on-failure is defined in [Service], the
unit will be restarted again immediately. So, user will get unit, that
will be active due to RuntimeMaxSec=, then it will be marked as "failed"
and, if additional option Restart=on-failure is defined, will be
restarted again... failed...restart and so on for eternity. Right?
Sure, if that's how you configure things, then systemd does what you
are asking it for.
I'm staring on TimeoutStopSec= directive description and I think it's be
more logical a little bit to define RuntimeMaxSec= _only together_ with
TimeoutStopSec=.
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.
Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.
So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
with RuntimeMaxSec=, which is the normal procedure to exit with
on-success exit-code, why systemd marks unit as "failed", when
RuntimeMaxSec= is hit? Can't catch the logic yet...
Post by Lennart Poettering
Either way, I am happy to take a patch that makes this
configurable.

That was one of ways to use TimeoutStopSec=, as the first idea how to
manke this mechanism more flexible.
Lennart Poettering
2016-02-12 20:57:55 UTC
Permalink
Post by Mikhail Kasimov
Post by Lennart Poettering
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.
Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.
So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
with RuntimeMaxSec=, which is the normal procedure to exit with
on-success exit-code, why systemd marks unit as "failed", when
RuntimeMaxSec= is hit? Can't catch the logic yet...
It's the same as with a daemon exiting non-zero. In that case we'll
also continue with ExecStop= and place the service in a failed state.

Lennart
--
Lennart Poettering, Red Hat
Mikhail Kasimov
2016-02-12 21:12:14 UTC
Permalink
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.
Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.
So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
with RuntimeMaxSec=, which is the normal procedure to exit with
on-success exit-code, why systemd marks unit as "failed", when
RuntimeMaxSec= is hit? Can't catch the logic yet...
It's the same as with a daemon exiting non-zero. In that case we'll
also continue with ExecStop= and place the service in a failed state.
So, if I define, for example, RuntimeMaxSec=15s, that means unit should
stop its job in the interval=[0; 14.59]s and 15.00s will be interval
overflow with exit-code 'failure'. OK. But what if unit will stop its
job on, e.g., 13th second? Exit-code=success?
Lennart Poettering
2016-02-12 21:36:20 UTC
Permalink
Post by Mikhail Kasimov
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.
Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.
So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
with RuntimeMaxSec=, which is the normal procedure to exit with
on-success exit-code, why systemd marks unit as "failed", when
RuntimeMaxSec= is hit? Can't catch the logic yet...
It's the same as with a daemon exiting non-zero. In that case we'll
also continue with ExecStop= and place the service in a failed state.
So, if I define, for example, RuntimeMaxSec=15s, that means unit should
stop its job in the interval=[0; 14.59]s and 15.00s will be interval
overflow with exit-code 'failure'. OK. But what if unit will stop its
job on, e.g., 13th second? Exit-code=success?
Yes.

RuntimeMaxSec= just says "abort this shit if it takes longer than
this". The usecase is to use it for stuff which is not supposed to
take this long, and where it's better to abort it, and complain than
to leave it running unbounded.

Lennart
--
Lennart Poettering, Red Hat
Mikhail Kasimov
2016-02-12 21:51:45 UTC
Permalink
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.
Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.
So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
with RuntimeMaxSec=, which is the normal procedure to exit with
on-success exit-code, why systemd marks unit as "failed", when
RuntimeMaxSec= is hit? Can't catch the logic yet...
It's the same as with a daemon exiting non-zero. In that case we'll
also continue with ExecStop= and place the service in a failed state.
So, if I define, for example, RuntimeMaxSec=15s, that means unit should
stop its job in the interval=[0; 14.59]s and 15.00s will be interval
overflow with exit-code 'failure'. OK. But what if unit will stop its
job on, e.g., 13th second? Exit-code=success?
Yes.
RuntimeMaxSec= just says "abort this shit if it takes longer than
this". The usecase is to use it for stuff which is not supposed to
take this long, and where it's better to abort it, and complain than
to leave it running unbounded.
Ok, got it. Thanks! And one more question -- will 'systemctl status' and
'journalctl' contain the explanation about RuntimeMaxSec= limit overflow
in logs? E.g. "[FAILED] bla-bla-bla.service. Forced exit, because
RuntimeMaxSec limit is hit". Or something around this.
Lennart Poettering
2016-02-13 10:00:58 UTC
Permalink
Post by Mikhail Kasimov
Post by Lennart Poettering
RuntimeMaxSec= just says "abort this shit if it takes longer than
this". The usecase is to use it for stuff which is not supposed to
take this long, and where it's better to abort it, and complain than
to leave it running unbounded.
Ok, got it. Thanks! And one more question -- will 'systemctl status' and
'journalctl' contain the explanation about RuntimeMaxSec= limit overflow
in logs? E.g. "[FAILED] bla-bla-bla.service. Forced exit, because
RuntimeMaxSec limit is hit". Or something around this.
So, "systemctl status" first shows you the general unit status and
then shows you recent log data from and about the unit. In the general
unit status you find a short field explaining the cause for the
failure, and for timeouts it will say "timeout" (but not be any more
specific). In the log data you'll find a longer, human readable
explanation.

Lennart
--
Lennart Poettering, Red Hat
Umut Tezduyar Lindskog
2016-02-15 08:36:33 UTC
Permalink
Hi,

On Fri, Feb 12, 2016 at 10:36 PM, Lennart Poettering
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
Post by Mikhail Kasimov
Post by Lennart Poettering
TimeoutStopSec= is set to 90s by default. Because it is opt-out and
not opt-in it's set pretty much in all cases.
Note that when the RuntimeMaxSec= timeout hits and systemd starts
terminating the service it does so by going through ExecStop= and
ExecStopPost=. The TimeoutStopSec= timeout applies to each of them
anyway.
So, if systemd is going through ExecStop= and ExecStopPost= to stop unit
with RuntimeMaxSec=, which is the normal procedure to exit with
on-success exit-code, why systemd marks unit as "failed", when
RuntimeMaxSec= is hit? Can't catch the logic yet...
It's the same as with a daemon exiting non-zero. In that case we'll
also continue with ExecStop= and place the service in a failed state.
So, if I define, for example, RuntimeMaxSec=15s, that means unit should
stop its job in the interval=[0; 14.59]s and 15.00s will be interval
overflow with exit-code 'failure'. OK. But what if unit will stop its
job on, e.g., 13th second? Exit-code=success?
Yes.
RuntimeMaxSec= just says "abort this shit if it takes longer than
this". The usecase is to use it for stuff which is not supposed to
take this long, and where it's better to abort it, and complain than
to leave it running unbounded.
What is a use case for this, can you give an example? I can make few
for a Type=oneshot service (Note that this setting does not have any
effect on Type=oneshot services) like "send this email, search this
database" but I cannot come up with something for other service types.

However I think it would be nice to extend this to terminate say a
service taking all available CPU within certain time.

Umut
Post by Lennart Poettering
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering
2016-02-15 13:20:18 UTC
Permalink
Post by Umut Tezduyar Lindskog
Post by Lennart Poettering
Post by Mikhail Kasimov
So, if I define, for example, RuntimeMaxSec=15s, that means unit should
stop its job in the interval=[0; 14.59]s and 15.00s will be interval
overflow with exit-code 'failure'. OK. But what if unit will stop its
job on, e.g., 13th second? Exit-code=success?
Yes.
RuntimeMaxSec= just says "abort this shit if it takes longer than
this". The usecase is to use it for stuff which is not supposed to
take this long, and where it's better to abort it, and complain than
to leave it running unbounded.
What is a use case for this, can you give an example? I can make few
As mentioned, coredump processing is one (see other mail in the thread).
Post by Umut Tezduyar Lindskog
for a Type=oneshot service (Note that this setting does not have any
effect on Type=oneshot services) like "send this email, search this
database" but I cannot come up with something for other service types.
However I think it would be nice to extend this to terminate say a
service taking all available CPU within certain time.
Yeah, I thought about this. But there's no nice way to do this
currently. I figure this would need some extension in the "cpu"
cgroup controller, so that we get an actionable event from the
kernel. Because currently we'd have to keep watching the cgroup
attributes in a time-based loop and that's ugly.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2016-02-11 17:47:38 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(including stacktrace extraction) from a new instantiated service
Is it enough to disable this type service unit to completely disable
coredump or will users have to for example set Storage=none in coredump.conf
and or other tweaks and if so which ones?
Try the man page systemd-coredump(8), first paragraph.
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an admin
specifically told the the service it could run for maximum X time and then
it should stop? ( after that time period the type unit should be stopped
cleanly basically systemctl stop foo.service and the state be exactly the
same as it yields right ? )
I think yours appears to be a different usecase than what
RUntimeMaxSec= currently covers.

Lennart
--
Lennart Poettering, Red Hat
Jóhann B. Guðmundsson
2016-02-11 19:08:01 UTC
Permalink
Post by Lennart Poettering
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(including stacktrace extraction) from a new instantiated service
Is it enough to disable this type service unit to completely disable
coredump or will users have to for example set Storage=none in coredump.conf
and or other tweaks and if so which ones?
Try the man page systemd-coredump(8), first paragraph.
I do believe that's not enough to completely disable this and confusing
at best I mean is the man page refering to
/usr/lib/sysctl.d/50-coredump.conf
or /etc/systemd/coredump.conf which is what the administrator would
associate this with since you know he was reading that particular man page.

There is a quite the difference of doing "ln -s /dev/null
/etc/sysctl.d/50-coredump.conf && sysctl -p or
/lib/systemd/systemd-sysctl" if systemd does not pick up the sysctl changes
vs administrators creating a symlink to /etc/systemd/coredump.conf
disable this and run systemctl daemon-reload while the former is
probably what's being refereed to.

And based on how that got implemented I have to ask cant this be disable
completely as a switch in /etc/systemd/coredump.conf without having to
have administrators jump through hoops, create symlinks and what not?
Post by Lennart Poettering
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state.
This does not sound right, why put it into failure state if I as an admin
specifically told the the service it could run for maximum X time and then
it should stop? ( after that time period the type unit should be stopped
cleanly basically systemctl stop foo.service and the state be exactly the
same as it yields right ? )
I think yours appears to be a different usecase than what
RUntimeMaxSec= currently covers.
What's the usecase you had in mind and why leave it in failed state?

jBG
Lennart Poettering
2016-02-12 20:08:56 UTC
Permalink
Post by Lennart Poettering
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
* The coredump collection logic has been reworked: when a coredump is
collected it is now written to disk, compressed and processed
(including stacktrace extraction) from a new instantiated service
Is it enough to disable this type service unit to completely disable
coredump or will users have to for example set Storage=none in coredump.conf
and or other tweaks and if so which ones?
Try the man page systemd-coredump(8), first paragraph.
I do believe that's not enough to completely disable this and confusing at
best I mean is the man page refering to /usr/lib/sysctl.d/50-coredump.conf
or /etc/systemd/coredump.conf which is what the administrator would
associate this with since you know he was reading that particular man page.
There is a quite the difference of doing "ln -s /dev/null
/etc/sysctl.d/50-coredump.conf && sysctl -p or /lib/systemd/systemd-sysctl"
if systemd does not pick up the sysctl changes
vs administrators creating a symlink to /etc/systemd/coredump.conf disable
this and run systemctl daemon-reload while the former is probably what's
being refereed to.
And based on how that got implemented I have to ask cant this be disable
completely as a switch in /etc/systemd/coredump.conf without having to have
administrators jump through hoops, create symlinks and what not?
You can also set Storage=none, if you like. In this case we'll log
about the coredump, but not store it.
What's the usecase you had in mind and why leave it in failed state?
Because something is weird about it as normally it shouldn't take that long...

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2016-02-11 18:03:29 UTC
Permalink
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state
failure state makes no sense at all here

when i say "start and stop after 20 minutes" i mean stop it not fail

usecase?

some PHP service "while (1==1)" and exclude the complete logic of "stop
after 20 minutes" and use instead the systemd-option
Jan Alexander Steffens
2016-02-11 18:20:02 UTC
Permalink
Post by Reindl Harald
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state
failure state makes no sense at all here
when i say "start and stop after 20 minutes" i mean stop it not fail
usecase?
I wanted to say "aborting Type=oneshot services," but that's what
TimeoutStartSec is for. So I was wondering what the point of this is, too.

Apparently it's for instantiated services like systemd-***@.service.
Why can't a service for an Accept=yes socket be Type=oneshot and use
TimeoutStartSec?
Lennart Poettering
2016-02-12 20:56:25 UTC
Permalink
Post by Jan Alexander Steffens
Post by Reindl Harald
when i say "start and stop after 20 minutes" i mean stop it not fail
usecase?
I wanted to say "aborting Type=oneshot services," but that's what
TimeoutStartSec is for. So I was wondering what the point of this is, too.
Why can't a service for an Accept=yes socket be Type=oneshot and use
TimeoutStartSec?
Philosophically I'd claim that Type=oneshot is supposed to be for
"short" running processes that something else waits for *to
exit*. The other types are for "long" running processes, that
nothing waits for to exit. Thus I think the coredump service is right
for Type=simple.

But yeah, the lines are blurry, and it would work with Type=oneshot too.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2016-02-12 20:13:27 UTC
Permalink
Post by Reindl Harald
Post by Lennart Poettering
* A new service setting RuntimeMaxSec= has been added that may be used
to specify a maximum runtime for a service. If the timeout is hit, the
service is terminated and put into a failure state
failure state makes no sense at all here
well, maybe you have a different usecase, but it certainly makes sense
in others.

Either way, I am happy to take a patch that makes this
configurable. One option could be to extend SuccessExitStatus= and
RestartPreventExitStatus= so that they take a special value "timeout",
or so, which disables the failure state or restart for the timeout case.

Lennart
--
Lennart Poettering, Red Hat
Dave Reisner
2016-02-11 21:19:34 UTC
Permalink
Post by Lennart Poettering
Heya!
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
Reindl Harald
2016-02-11 21:26:51 UTC
Permalink
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
Dave Reisner
2016-02-12 01:09:03 UTC
Permalink
Post by Reindl Harald
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
Colin Guthrie
2016-02-12 09:54:13 UTC
Permalink
Post by Dave Reisner
Post by Reindl Harald
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
Seems odd indeed. It's perhaps because the user needs to own directories
that are packaged (e.g. in /var) which is somewhat tricky with sysusers
- you need to have the user available before the package is installed -
i.e. an RPM %pre script. Just a guess at why it was left out.

Personally, I'd just make such folders ghosts and them have them created
by tmpfiles after package install (and thus after sysusers has run to
create the user who will own the folders)

This is something that I think should be automated in RPM packaging
(i.e. the creation of ghosts automatically by parsing packaged tmpfiles
snippets), but this is off-topic.

Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Armin K.
2016-02-12 09:56:29 UTC
Permalink
Post by Colin Guthrie
Post by Dave Reisner
Post by Reindl Harald
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
Seems odd indeed. It's perhaps because the user needs to own directories
that are packaged (e.g. in /var) which is somewhat tricky with sysusers
- you need to have the user available before the package is installed -
i.e. an RPM %pre script. Just a guess at why it was left out.
Personally, I'd just make such folders ghosts and them have them created
by tmpfiles after package install (and thus after sysusers has run to
create the user who will own the folders)
This is something that I think should be automated in RPM packaging
(i.e. the creation of ghosts automatically by parsing packaged tmpfiles
snippets), but this is off-topic.
Col
I don't see the problem. The user is already in sysusers.d/systemd.conf.m4

https://github.com/systemd/systemd/blob/master/sysusers.d/systemd.conf.m4

I do appreciate that he mentioned a new user had to be created, because,
you know, not everyone uses systemd-sysusers.
Colin Guthrie
2016-02-12 11:40:34 UTC
Permalink
Post by Armin K.
Post by Colin Guthrie
Post by Dave Reisner
Post by Reindl Harald
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
Seems odd indeed. It's perhaps because the user needs to own directories
that are packaged (e.g. in /var) which is somewhat tricky with sysusers
- you need to have the user available before the package is installed -
i.e. an RPM %pre script. Just a guess at why it was left out.
Personally, I'd just make such folders ghosts and them have them created
by tmpfiles after package install (and thus after sysusers has run to
create the user who will own the folders)
This is something that I think should be automated in RPM packaging
(i.e. the creation of ghosts automatically by parsing packaged tmpfiles
snippets), but this is off-topic.
Col
I don't see the problem. The user is already in sysusers.d/systemd.conf.m4
https://github.com/systemd/systemd/blob/master/sysusers.d/systemd.conf.m4
I do appreciate that he mentioned a new user had to be created, because,
you know, not everyone uses systemd-sysusers.
Indeed. In my package here, it successfully created the user via
sysusers on update. I should have double checked rather than blindly
believing Dave's statement which, as it turns out, is incorrect (tho' I
can see why he make the assumption due to the original wording).

Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Dave Reisner
2016-02-12 12:46:46 UTC
Permalink
Post by Armin K.
Post by Colin Guthrie
Post by Dave Reisner
Post by Reindl Harald
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
Seems odd indeed. It's perhaps because the user needs to own directories
that are packaged (e.g. in /var) which is somewhat tricky with sysusers
- you need to have the user available before the package is installed -
i.e. an RPM %pre script. Just a guess at why it was left out.
Personally, I'd just make such folders ghosts and them have them created
by tmpfiles after package install (and thus after sysusers has run to
create the user who will own the folders)
This is something that I think should be automated in RPM packaging
(i.e. the creation of ghosts automatically by parsing packaged tmpfiles
snippets), but this is off-topic.
Col
I don't see the problem. The user is already in sysusers.d/systemd.conf.m4
https://github.com/systemd/systemd/blob/master/sysusers.d/systemd.conf.m4
I do appreciate that he mentioned a new user had to be created, because,
you know, not everyone uses systemd-sysusers.
Ah, this is all I was looking for. Sorry, should have looked a bit more
closely.
Lennart Poettering
2016-02-12 20:05:18 UTC
Permalink
Post by Reindl Harald
Post by Dave Reisner
Post by Lennart Poettering
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
systemd don't create any user. nowhere, rpm-scritrs downstream does
Not true. See sysusers.d.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2016-02-12 20:04:50 UTC
Permalink
Post by Dave Reisner
Post by Lennart Poettering
Heya!
I just tagged the v229 release of systemd. Enjoy!
<snip>
* When the stacktrace is extracted from processes of system users, this
is now done as "systemd-coredump" user, in order to sandbox this
potentially security sensitive parsing operation. (Note that when
processing coredumps of normal users this is done under the user ID
of process that crashed, as before.) Packagers should take notice
that it is now necessary to create the "systemd-coredump" system user
and group at package installation time.
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
The user is handled exactly the same way as the other 4 users. It's
listed in the sysusers fragment, but for packages which use
distro-specific adduser/useradd tools from their scripts this is
irrelevant, and the packagers need to be aware of this. This is why I
am mentioning this.

I can only recommend distros to use sysusers to manage their system
users, to enable full stateless operation in a distro-independent
way. But I know that many do not, that's all.

Lennart
--
Lennart Poettering, Red Hat
Loading...