This closes an important gap: so far we would reexecute the system manager and
restart system services that were configured to do so, but we wouldn't do the
same for user managers or user services.
The scheme used for user managers is very similar to the system one, except
that there can be multiple user managers running, so we query the system
manager to get a list of them, and then tell each one to do the equivalent
operations: daemon-reload, disable --now, set-property Markers=+needs-restart,
reload-or-restart --marked.
The total time that can be spend on this is bounded: we execute the commands in
parallel over user managers and units, and additionally set SYSTEMD_BUS_TIMEOUT
to a lower value (15 s by default). User managers should not have too many
units running, and they should be able to do all those operations very
quickly (<< 1s). The final restart operation may take longer, but it's done
asynchronously, so we only wait for the queuing to happen.
The advantage of doing this synchronously is that we can wait for each step to
happen, and for example daemon-reloads can finish before we execute the service
restarts, etc. We can also order various steps wrt. to the phases in the rpm
transaction.
When this was initially proposed, we discussed a more relaxed scheme with bus
property notifications. Such an approach would be more complex because a bunch
of infrastructure would have to be added to system manager to propagate
appropriate notifications to the user managers, and then the user managers
would have to wait for them. Instead, now there is no new code in the managers,
all new functionality is contained in src/rpm/. The ability to call 'systemctl
--user user@' makes this approach very easy. Also, it would be very hard to
order the user manager steps and the rpm transaction steps.
Note: 'systemctl --user disable' is only called for a user managers that are
running. I don't see a nice way around this, and it shouldn't matter too much:
we'll just leave a dangling symlink in the case where the user enabled the
service manually.
A follow-up for https://bugzilla.redhat.com/show_bug.cgi?id=1792468 and
fa97d2fcf6.
Some rpms install a bunch of units… It seems nicer to invoke them all in
parallel. In particular, timeouts in systemctl also run in parallel, so if
there's some communication mishap, we will wait less.
Instead of embedding the commands to invoke directly in the macros,
let's use a helper script as indirection. This has a couple of advantages:
- the macro language is awkward, we need to suffix most commands by "|| :"
and "\", which is easy to get wrong. In the new scheme, the macro becomes
a single simple command.
- in the script we can use normal syntax highlighting, shellcheck, etc.
- it's also easier to test the invoked commands by invoking the helper
manually.
- most importantly, the logic is contained in the helper, i.e. we can
update systemd rpm and everything uses the new helper. Before, we would
have to rebuild all packages to update the macro definition.
This raises the question whether it makes sense to use the lua scriptlets when
the real work is done in a bash script. I think it's OK: we still have the
efficient lua scripts that do the short scripts, and we use a single shared
implementation in bash to do the more complex stuff.
The meson version is raised to 0.47 because that's needed for install_mode.
We were planning to raise the required version anyway…
We can make things a bit simpler and more readable by not specifying the path.
Since we didn't specify the full path for all commands (including those invoked
recursively by anythign we invoke), this didn't really privide any security or
robustness benefits. I guess that full paths were used because this style of
rpm packagnig was popular in the past, with macros used for everything
possible, with special macros for common commands like %{__ln} and %{__mkdir}.
We would copy "forever" into the buffer. This is a fairly common case, so let's
do a microoptimization and return a static string. (All callers use the return
pointer, so this works just as well.)
The prefix "for " was not displayed, because the pointer to the part of the
buffer after "for " was returned. (Maybe it's just me, but I find strpcpy()
and associated functions really hard to use… I always have to look up what the
do exactly and what the return value is.)
A simple test is added.
When assigning the same address provided by a dynamic addressing
protocol, the new lifetime is stored on Request::Address, but not
Address object in Link object, which can be obtained by address_get().
So, we need to configure address with Address object in Request.
Fixes#20245.
Format output in a manner that can be copypasted as-is to NEWS.
That is, with 8 spaces indentation and wrapped at 80 columns.
Before:
$ tools/git-contrib.sh
Ben Stockett,
Carl Lei,
Frantisek Sumsal,
Gibeom Gwon,
Hugo Osvaldo Barrera,
James Hilliard,
Jan Palus,
Lennart Poettering,
Luca Boccassi,
Luca BRUNO,
Mike Gilbert,
nassir90,
nl6720,
Raul Tambre,
Yegor Alexeyev,
Yu Watanabe,
Zbigniew Jędrzejewski-Szmek,
After:
Contributions from: Ben Stockett, Carl Lei, Frantisek Sumsal,
Gibeom Gwon, Hugo Osvaldo Barrera, James Hilliard, Jan Palus,
Lennart Poettering, Luca Boccassi, Luca BRUNO, Mike Gilbert,
nassir90, nl6720, Raul Tambre, Yegor Alexeyev, Yu Watanabe,
Zbigniew Jędrzejewski-Szmek
This makes the default gateway is read from classless static routes or
router option even if UseGateway=no or UseRoutes=no, and will be used
when configuring semi-static routes such that specified with Gateway=_dhcp4.
This also changes the behavior of RoutesToDNS= or RoutesToNTP=.
Previously, the DNS or NTP servers are not in the same network, then the
routes to the servers were not configured when UseGateway=no or
UseRoutes=no. With this commit, the default gateway in classless static
routes or router option will used to connecting the servers even if
UseGateway=no or UseRoutes=no.
Fixes#20208.
For some reasons I do not know, on interface renaming, kernel once send
netlink message with old interface name, and then send with new name.
If eth0 is renamed, and then new interface appears as eth0, then the
message with the old name 'eth0' makes the interface enters failed
state.
To ignore such invalid(?) rename event messages, let's confirm the
received interface name.
Fixes#20203.
Fixes#20189. We would only log at debug level and return failure, which looks
like a noop for the user.
('help' accepts multiple arguments and will show multiple concatenated man
pages in that case. Actually, it will also show multiple concatenated man pages
if the Documentation= setting lists multiple pages. I don't think it's very
terribly useful, but, meh, I don't think we can do much better. If a user
requests a help for a two services, one known and one unknown, there'll now be
a line in the output. It's not very user friendly, but not exactly wrong too.)
Since autodetection is unlikely to work reliably for cross builds
disable it unless explicitly enabled.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Updated manpage for sd_bus_set_property and sd_bus_set_propertyv. In the old manpage, these functions included the parameter sd_bus_message **reply when the actual function had no such argument.
* Fixed typo
Before, the file claimed that some systemd units are created "from other
configuration". It should have read "from other configuration files".
Co-authored-by: Nozz <nozolo90@gmail.com>
Zbigniew Jędrzejewski-Szmek
WANG Xuerui
Aakash Singh
rene
Yu Watanabe
monosans
Frantisek Sumsal
James Hilliard
Luca Boccassi
duament
Luca Boccassi
Raul Tambre
Gibeom Gwon
Luca BRUNO
Carl Lei
Mike Gilbert
Ben Stockett
nassir90andNozz