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.
This does two semi-independent but interleaved things: firstly, the manager now
prints the status text (if available) of a service when we have a job running
for that service and it is slow. Because it's hard to fit enough info on the
line, we only do this if the output mode uses unit names. The format of the
line "… job is running for …" is changed to be shorter. This way we can
somewhat reasonably fit two status messages on one line.
Secondly, the manager now sends more information using sd_notify. This mostly
matters for in case of the user manager. In particular, we notify when starting
one of the special units. Without this, when the system manager would display a
line about waiting for the user manager, it would show status like "Ready.",
which is confusing. Now it'll either show something like "Started special unit
shutdown.target", or the line about waiting for a user job.
Also, the timeouts for the user manager are lowered: the user manager usually
(always?) has status disabled, so we would wait for 25 seconds before showing
job progress. Normally we don't expect to have any jobs that take more than a
second. So let's start the progress output fairly quickly, like we would if
status showing was enabled. This obviously makes the output in the system
manager about the user manager more useful. The timeouts are "desynchronized"
by a fraction so if there are multiple jobs running, we'll cycle through
showing all combinations.
Example output:
Stopping user@1000.service...
[ OK ] Stopped dracut-shutdown.service.
[ OK ] Stopped systemd-logind.service.
[ OK ] Stopped systemd-logind.service - User Login Management.
[* ] Job user@1000.service/stop running (2s / 2min): (1 of 2) User job slowstop.service/stop running (1s / 1min 30s)...
[*** ] Job user@1000.service/stop running (3s / 2min): (2 of 2) User job slowstop2.service/stop running (2s / 1min 30s)...
[ ***] Job user@1000.service/stop running (4s / 2min): (1 of 2) User job slowstop.service/stop running (4s / 1min 30s)...
[ *] Job user@1000.service/stop running (5s / 2min): (1 of 2) User job slowstop.service/stop running (5s / 1min 30s)...
[ ***] Job user@1000.service/stop running (6s / 2min): (2 of 2) User job slowstop2.service/stop running (6s / 1min 30s)...
[*** ] Job user@1000.service/stop running (8s / 2min): (1 of 2) User job slowstop.service/stop running (7s / 1min 30s)...
[*** ] Job user@1000.service/stop running (10s / 2min): (2 of 2) User job slowstop2.service/stop running (9s / 1min 30s)...
[ *** ] Job user@1000.service/stop running (11s / 2min): (1 of 2) User job slowstop.service/stop running (10s / 1min 30s)...
[ *] Job user@1000.service/stop running (12s / 2min): (2 of 2) User job slowstop2.service/stop running (12s / 1min 30s)...
[ ***] Job user@1000.service/stop running (13s / 2min): (1 of 2) User job slowstop.service/stop running (13s / 1min 30s)...
[*** ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User job slowstop2.service/stop running (14s / 1min 30s)...
[* ] Job user@1000.service/stop running (15s / 2min): (2 of 2) User job slowstop2.service/stop running (14s / 1min 30s)...
[*** ] Job user@1000.service/stop running (16s / 2min): User job slowstop.service/stop running (16s / 1min 30s)...
[ ***] Job user@1000.service/stop running (18s / 2min): User job slowstop.service/stop running (17s / 1min 30s)...
[ *] Job user@1000.service/stop running (19s / 2min): User job slowstop.service/stop running (18s / 1min 30s)...
[ ***] Job user@1000.service/stop running (20s / 2min): User job slowstop.service/stop running (19s / 1min 30s)...
[* ] Job user@1000.service/stop running (22s / 2min): User job slowstop.service/stop running (22s / 1min 30s)...
[** ] Job user@1000.service/stop running (30s / 2min): User job slowstop.service/stop running (29s / 1min 30s)...
[ ***] Job user@1000.service/stop running (32s / 2min): User job slowstop.service/stop running (31s / 1min 30s)...
[ *] Job user@1000.service/stop running (33s / 2min): User job slowstop.service/stop running (32s / 1min 30s)...
[ ***] Job user@1000.service/stop running (34s / 2min): User job slowstop.service/stop running (33s / 1min 30s)...
[** ] Job user@1000.service/stop running (37s / 2min): User job slowstop.service/stop running (36s / 1min 30s)...
[ *** ] Job user@1000.service/stop running (41s / 2min): User job slowstop.service/stop running (41s / 1min 30s)...
[ OK ] Stopped user@1000.service - User Manager for UID 1000.
Stopping user-runtime-dir@1000.service - User Runtime Directory /run/user/1000...
[ OK ] Unmounted run-user-1000.mount - /run/user/1000.
[ OK ] Stopped user-runtime-dir@1000.service - User Runtime Directory /run/user/1000.
If the output width is lower than approximately 100 columns, the output stops
being very useful. No idea what to do about that.
We would send READY=1,STATUS="Startup finished in …" once after finishing
boot. This changes the message to just "Ready.". The time used to reach
readiness is not part of the ongoing status — it's just a bit of debug
information that it useful in some scenarious, but completely uninteresting
most of the time. Also, when we start sending status about other things in
subsequent patches, we can't really go back to showing "Startup finished in …"
later on. So let's just show "Ready." whenever we're in the steady state.
In manager_check_finished(), more steps are skipped if MANAGER_IS_FINISHED().
Those steps are idempotent, but no need to waste cycles trying to do them
more than once.
We'll now also check whether to send the status message whenever the job queue
runs empty. If we already sent the exact same message already, we'll not send
again.
This is the initiatation of the machine shutdown/reboot/etc, so it's
useful to log about this. We log about the steps that we take, but
so far we didn't really log why we started the sequence (except at
debug level).
The function is renamed, because we also use it for dbus.service,
not just targets.
The man page says asprintf() pointer is "undefined" on error, but the
only meaningful interpretation is that it's either NULL or points to
something that should be freed with free().
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>
We still sometimes try to grep an empty strace log because strace is not
yet properly initialized. Let's make the check a bit clever and wait
until strace is attached to PID 1 by checking the `TracerPid` field in
`/proc/1/status`.
Yu Watanabe
Frantisek Sumsal
James Hilliard
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
duament
Luca Boccassi
Raul Tambre
Gibeom Gwon
Luca BRUNO
Carl Lei
Christoph Anton Mitterer
Mike Gilbert
Ben Stockett
nassir90andNozz