Right now gpt-auto-generator will iterate through all mount entries, and
silently ignore failure to check if the mount point target is empty.
This can hide real errors (in particular from MAC), so instead let's warn
and return failure at the end if this happens. We will still iterate
over other candidates, so there should be no change in behaviour.
Logging is moved into path_is_busy() to avoid the duplication of the same
logging code in the two callers.
A regression was introduced that caused the mtime of /etc/.updated
and /var/.updated to be the current time when systemd-update-done
ran instead of being copied from /usr.
This was nearly fixed, but due to fflush being called after mtime
was carefully set, it was overwritten with the current time.
Regression introduced in 872c403963
A fix was just missed in 39c38d773fFixes#8806
With the recent terminal_urlify() APIs we'll now sometimes generate
clickable link CSO sequences. Hence we should also be able to remove
them again from strings. This beefs up the logic to do so.
Follow-up for: 23b27b39d2
Quoting https://github.com/systemd/systemd/pull/8760#discussion_r183321060:
> When we originally added the errno patching we went for a "best of both
> worlds" approach, i.e. that we override errno if an error is specified, but
> if no error is specified (i.e. 0 is passed as error code) then we use the
> previously set errno, similar in style how plain `printf()` would do it. In
> retrospect I think we almost never purposefully made use of the second,
> i.e. the plain `printf()` logic, but we multiple times ran into this case
> accidentally and introduced a bug. Hence yes, it probably makes sense to
> switch this over, and consistently ignore the `errno` already set and always
> override it with the error passed in. The only problem I see with that is: I
> wonder if there might be a case or two lurking somewhere where we actually
> made use of the "best of both worlds" approach, and if so, if we can detect
> where... (But then again, even if there is, and we fail to find those cases,
> maybe that's not all bad, as it's just a few new bugs against probably fixing
> many more old and future bugs, if you follow what I mean).
I scanned our codebase, and found some bugs in the value passed to log_*_errno,
but no intentional cases of error=0 being passed.
I'm not sure if I understand the original code. AFAICS, errno does not
have to be set at all in this callback.
ratelimit_test() returns positive if we are under limit. The code would only
log if the condition happened very often, which I assume is not inteded, and
this check was supposed to prevent too much logging.
Those are quite similar to %i/%I, but refer to the last dash-separated
component of the name prefix.
The new functionality of dash-dropins could largely supersede the template
functionality, so it would be tempting to overload %i/%I. But that would
not be backwards compatible. So let's add the two new letters instead.
The description in the man page disagreed with the code. Let the code win,
since if anybody is using this, they are more likely to depend on actual
behaviour rather than the docs. (In Fedora workstation installation there's
only one use, and it doesn't make much sense either way: SyslogIdentifier=%N
in xfs_scrub@.service.)
Also adds dots at the end everywhere, because we have multiple sentences in
some explanations, so we need dots.
Once the seat is acquired, gnome-settings-daemon (GSD) takes full
control of rfkill by sending RFKILL_IOCTL_NOINPUT ioctl to disable
rfkill control in kernel.
Since GSD expects wlan keycode when the hotkey gets pressed, we should
change the "unknown" to "wlan" accordingly.
Tested under both GNOME and KDE.
- Add a new flag --strict to tell systemd-hwdb to return a
non-zero code on error.
- Make systemd-hwdb update return an error when any parsing
error occurs (only if strict flag is set).
- Add a new flag --strict to tell udevadm hwdb to return a
non-zero code on error.
- Make udevadm hwdb --update return an error when any parsing
error occurs (only if strict flag is set).
Ultimately we should replace the relevant wiki texts with documentation
maintained as part of our project tree. This is a start. It can't
replace the wiki documentation in full yet, but I think it's already
very useful.