| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
# Conflicts:
# src/libbasic/Makefile
|
|
|
|
# Conflicts:
# src/libsystemd/src/sd-journal/Makefile
|
|
|
|
# Conflicts:
# src/libshared/Makefile
# src/libsystemd/src/Makefile
# src/libsystemd/src/sd-journal/Makefile
|
|
|
|
|
|
# Conflicts:
# src/libsystemd/src/Makefile
|
|
|
|
|
|
|
|
Id128 fixes and more
|
|
Systemctl more cleanup
|
|
Accept both files with and without trailing newlines. Apparently some rkt
releases generated them incorrectly, missing the trailing newlines, and we
shouldn't break that.
|
|
We can make this smarter one day, to honour $TMPDIR and friends, but for now,
let's just use /tmp.
|
|
All pending tokens are already serialized correctly and will be handled
when the mount unit is done.
Without this a 'daemon-reload' cancels all pending tokens. Any process
waiting for the mount will continue with EHOSTDOWN.
This can happen when the mount unit waits for it's dependencies, e.g.
network, devices, fsck, etc.
|
|
This is important if a job was queued for a unit but not yet started.
Without this, the job will be canceled and is never executed even though
IgnoreOnIsolate it set to 'true'.
|
|
|
|
It is only used with info allocated on the stack, so the pointer cannot be
NULL.
|
|
journald crashes (#3799)
As suggested:
https://github.com/systemd/systemd/pull/3783/files/5157879b757bffce3da0a68ca207753569e8627d#r71906971
|
|
% valgrind --leak-check=full systemctl status multipathd.service --no-pager -n0
...
==431== 16 bytes in 2 blocks are definitely lost in loss record 1 of 2
==431== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==431== by 0x534AF19: strdup (in /usr/lib64/libc-2.23.so)
==431== by 0x4E81AEE: free_and_strdup (string-util.c:794)
==431== by 0x4EF66C1: map_basic (bus-util.c:1030)
==431== by 0x4EF6A8E: bus_message_map_all_properties (bus-util.c:1153)
==431== by 0x120487: show_one (systemctl.c:4672)
==431== by 0x1218F3: show (systemctl.c:4990)
==431== by 0x4EC359E: dispatch_verb (verbs.c:92)
==431== by 0x12A3AE: systemctl_main (systemctl.c:7742)
==431== by 0x12B1A8: main (systemctl.c:8011)
==431==
==431== LEAK SUMMARY:
==431== definitely lost: 16 bytes in 2 blocks
This happens because map_basic() strdups the strings. Other code in systemctl
assigns strings to UnitStatusInfo without copying them, relying on the fact
that the message is longer lived than UnitStatusInfo. Add a helper function
that is similar to map_basic, but only accepts strings and does not copy them.
The alternative of continuing to use map_basic() but adding proper cleanup
to free fields in UnitStatusInfo seems less attractive because it'd require
changing a lot of code and doing a lot of more allocations for little gain.
(I put "leaking" in quotes, because systemctl is short lived anyway.)
|
|
There is no functional change, but clarity of the code is increased
by splitting out the cleanup part and putting it next to the structure
definition.
|
|
|
|
|
|
As suggested by @mbiebl we already use the "!" special char in unit file
assignments for negation, hence we should not use it in a different context for
privileged execution. Let's use "+" instead.
|
|
User expectations are broken when "systemctl enable /some/path/service.service"
behaves differently to "systemctl link ..." followed by "systemctl enable".
From user's POV, "enable" with the full path just combines the two steps into
one.
Fixes #3010.
|
|
documentation, NEWS and mailmap fixes
|
|
Before this patch, a service file with ReadWriteDirectories=/file...
could fail if the file exists but is not a mountpoint, despite being
listed in /proc/self/mountinfo. It could happen with masked mounts.
Fixes https://github.com/systemd/systemd/issues/3793
|
|
"systemctl enable"
Clarify that "systemctl enable" can operate either on unit names or on unit
file paths (also, adjust the --help text to clarify this). Say that "systemctl
enable" on unit file paths also links the unit into the search path.
Many other fixes.
This should improve the documentation to avoid further confusion around #3706.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
uuid/id128 code rework
|
|
Safe is safe, let's turn off the whole logic if we can, after all it is
unlikely we'll be able to process further crashes in a reasonable way.
|
|
Fixes: #3285
|
|
Add support for relative TasksMax= specifications, and bump default for services
|
|
Fixes: #3573
Replaces: #3588
|
|
Don't check inhibitors when operating remotely. The interactivity inhibitors
imply can#t be provided anyway, and the current code checks for local sessions
directly, via various sd_session_xyz() APIs, hence bypass it entirely if we
operate on remote systems.
Fixes: #3476
|
|
https://github.com/systemd/systemd/pull/3685 introduced
/run/systemd/inaccessible/{chr,blk} to map inacessible devices,
this patch allows systemd running inside a nspawn container to create
/run/systemd/inaccessible/{chr,blk}.
|
|
|
|
Because /run/systemd/inaccessible/{chr,blk} are devices with
major=0 and minor=0 it might be possible that these devices cannot be created
so we use /run/systemd/inaccessible/sock instead to map them.
|
|
Just in case...
|
|
To remove the hard dependency on systemd, for packages, which function
without a running systemd the %systemd_ordering macro can be used to
ensure ordering in the rpm transaction. %systemd_ordering makes sure,
the systemd rpm is installed prior to the package, so the %pre/%post
scripts can execute the systemd parts.
Installing systemd afterwards though, does not result in the same outcome.
|
|
As it turns out 512 is max number of tasks per service is hit by too many
applications, hence let's bump it a bit, and make it relative to the system's
maximum number of PIDs. With this change the new default is 15%. At the
kernel's default pids_max value of 32768 this translates to 4915. At machined's
default TasksMax= setting of 16384 this translates to 2457.
Why 15%? Because it sounds like a round number and is close enough to 4096
which I was going for, i.e. an eight-fold increase over the old 512
Summary:
| on the host | in a container
old default | 512 | 512
new default | 4915 | 2457
|
