When parsing and installing binaries mentioned in Exec*= lines the
5ed0dcf4d5 commit added parsing logic to drop
prefixes, including handling duplicate exclamation marks. But this did not
handle arbitrary combination of multiple prefixes, ie. StartExec=+-/bin/sh was
parsed as -/bin/sh which then would fail to install.
Instead of using egrep and shell replacements, replace both with sed command
that does it all. This sed script extract a group of characters starting with a
/ up to the first space (if any) after the equals sign. This correctly handles
existing non-prefixed, prefixed, multiple-prefixed commands.
About half commands seem to repeat themself, thus sort -u cuts the list of
binaries to install about in half.
To validate change of behaviour both old and new functions were modified to
echo parsed binaries into separate files, and then diffed. The incorrect
-/bin/sh was missing in the new output.
Without this patch tests fail on default Ubuntu installs.
That recommendation is likely to cause more trouble and for pretty
much all end-user units is not useful. Let's recommend relying on
the implicit dependency instead.
Fixes#10015.
Both SO_SNDBUFFORCE and SO_RCVBUFFORCE requires capability 'net_admin'.
If this capability is not granted to the service the first attempt to increase
the recv/snd buffers (via sd_notify()) with SO_RCVBUFFORCE/SO_SNDBUFFORCE will
fail, even if the requested size is lower than the limit enforced by the
kernel.
If apparmor is used, the DENIED logs for net_admin will show up. These log
entries are seen as red warning light, because they could indicate that a
program has been hacked and tries to compromise the system.
It would be nicer if they can be avoided without giving services (relying on
sd_notify) net_admin capability or dropping DENIED logs for all such services
via their apparmor profile.
I'm not sure if sd_notify really needs to forcibly increase the buffer sizes,
but at least if the requested size is below the kernel limit, the capability
(hence the log entries) should be avoided.
Hence let's first ask politely for increasing the buffers and only if it fails
then ignore the kernel limit if we have sufficient privileges.
Followup to commit 13cf422e04b7 ("user@.service: don't kill user manager at runlevel switch")
I think there's a general rule that units with `StopWhenUnneeded=yes` need
`IgnoreOnIsolate=yes`... But it doesn't apply to `suspend.target` and friends.
`printer.target` and friends break on isolate even if we apply the rule[1].
That just leaves `graphical-session.target`, which is a user service.
"isolate" is *mostly* a weird attempt to emulate runlevels, so I decided
not to worry about it for user services.
[1] https://github.com/systemd/systemd/issues/6505#issuecomment-320644819
Loggin in as root user and then switching the runlevel results in a
stop of the user manager, even though the user ist still logged in.
That leaves a broken user session.
Adding "IgnoreOnIsolate=true" to user@.service fixes this.
When $XDG_DATA_DIRS is unset, then, the default value
'/usr/local/share:/usr/share' is used.
When $XDG_DATA_DIRS contain the default paths but the order
is inverted: '/usr/share:/usr/local/share', then test-path-lookup fails.
Fixes#10002.