If we tested a candidate time that would fall onto the DST change, and we
realized that it is now a valid time ('cause the given "hour" is missing),
we would jump to to beginning of the next bigger time period, i.e. the next
day.
mktime_or_timegm() already tells us what the next valid time is, so let's reuse
this, and continue the calculations at this point. This should allow us to
correctly jump over DST changes, but also leap seconds and similar. It should
be OK even multiple days were removed from calendar, similarly to the
Gregorian-Julian transition. By reusing the information from normalization, we
don't have to make assumptions what the next valid time is.
Fixes#13745.
$ TZ=Australia/Sydney faketime '2019-10-06 01:50' build/systemd-analyze calendar 0/1:0/1 --iterations 20 | grep Iter
Iter. #2: Sun 2019-10-06 01:52:00 AEST
Iter. #3: Sun 2019-10-06 01:53:00 AEST
Iter. #4: Sun 2019-10-06 01:54:00 AEST
Iter. #5: Sun 2019-10-06 01:55:00 AEST
Iter. #6: Sun 2019-10-06 01:56:00 AEST
Iter. #7: Sun 2019-10-06 01:57:00 AEST
Iter. #8: Sun 2019-10-06 01:58:00 AEST
Iter. #9: Sun 2019-10-06 01:59:00 AEST
Iter. #10: Sun 2019-10-06 03:00:00 AEDT
Iter. #11: Sun 2019-10-06 03:01:00 AEDT
Iter. #12: Sun 2019-10-06 03:02:00 AEDT
Iter. #13: Sun 2019-10-06 03:03:00 AEDT
Iter. #14: Sun 2019-10-06 03:04:00 AEDT
Iter. #15: Sun 2019-10-06 03:05:00 AEDT
Iter. #16: Sun 2019-10-06 03:06:00 AEDT
Iter. #17: Sun 2019-10-06 03:07:00 AEDT
Iter. #18: Sun 2019-10-06 03:08:00 AEDT
Iter. #19: Sun 2019-10-06 03:09:00 AEDT
Iter. #20: Sun 2019-10-06 03:10:00 AEDT
$ TZ=Australia/Sydney faketime 2019-10-06 build/systemd-analyze calendar 2/4:30 --iterations=3
Original form: 2/4:30
Normalized form: *-*-* 02/4:30:00
Next elapse: Sun 2019-10-06 06:30:00 AEDT
(in UTC): Sat 2019-10-05 19:30:00 UTC
From now: 5h 29min left
Iter. #2: Sun 2019-10-06 10:30:00 AEDT
(in UTC): Sat 2019-10-05 23:30:00 UTC
From now: 9h left
Iter. #3: Sun 2019-10-06 14:30:00 AEDT
(in UTC): Sun 2019-10-06 03:30:00 UTC
From now: 13h left
I think 80-wifi-adhoc.network is safe enough, since it just enables
the link-local addressing. But the other two enable DHCP in client
or server modes, and we should not do this by default.
Judging by https://travis-ci.org/systemd/systemd/jobs/604425785
(where the script failed with "tools/coverity.sh: line 45: python: command not found")
python-unversioned-command is no longer installed by default with python2.
Given that it's not the first time python has vanished and it's not clear
what exactly should be installed to make sure it's there, let's just use jq instead.
The name with plural made more sense where multiple options could be specified
in one line. After changes in the pull request, this option only accepts one
value, so from users' POV it should be singular.
(The field in the data structure remains plural, because it actually stores
multiple values.)
Validate the IP address in the certificate for DNS-over-TLS in strict mode when GnuTLS is used. As this is not yet the case in contrast to the documentation.
Increase the required version to ensure TLS 1.3 is always supported when using GnuTLS for DNS-over-TLS and allow further changes to use recent API additions.
We slowly added many many conditions over the years, and the text became
very hard to read, because all the terms were squished in one <termitem>.
This rearragnes the text into a new subsection, with minimal grammar changes
and removal of repetitions.
Device tree overlays are a convenient way to patch device trees, e.g.,
add new devices to a device tree or enable/disable devices. This is
useful for non-discoverable but configurable hardware. Device tree
overlays are commonly used for displays on the Raspberry Pi or for
describing the content of FPGA bitstreams.
Add the devicetree-overlay key to boot loader specification entries to
allow boot loaders to apply overlays.
See #13537
b92d0b4c5a added AddRef to the StartTransientUnit
call in machine_start_scope()/manager_start_scope() and a corresponding Unref
call in machine_stop_scope(). But when we are running systemd-nspawn@ with
--keep unit, the unit is not created by machined so the AddRef never happens.
Then when trying to stop the unit, we'd get:
systemd-machined[1101]: Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnrefUnit cookie=37 reply_cookie=0 signature=s error-name=n/a error-message=n/a
systemd-machined[1101]: Got message type=error sender=:1.1 destination=:1.13 path=n/a interface=n/a member=n/a cookie=2443 reply_cookie=37 signature=s error-name=org.freedesktop.systemd1.NotReferenced error-message=Unit has not been referenced yet.
systemd-machined[1101]: Failed to drop reference to machine scope, ignoring: Unit has not been referenced yet.
When showing logs from a container, we would fail to show various lines:
Oct 29 09:50:51 krowka systemd-nspawn[61376]: Detected architecture x86-64.
Oct 29 09:50:51 krowka systemd-nspawn[61376]: [1B blob data]
Oct 29 09:50:51 krowka systemd-nspawn[61376]: Welcome to Fedora 32 (Rawhide)!
Oct 29 09:50:51 krowka systemd-nspawn[61376]: [1B blob data]
Those are only harmless \r characters that trail the line. We already replace
tabs and strip various ansi characters that we deem inconsequential, so let's
also strip trailing carriage returns. Non-trailing ones are different, because
they change what would be displayed.
We already shut the machine down ourselves (and pid1 will also do
cleanup for us after we exit if anything was left behind). No need for
systemd-machined to try to stop the unit too.
(This calls the new machined method. If we are running against an older
machined, we will not deregister the machine. If we are simply exiting,
machined should notice that the unit is gone on its own. If we are restarting,
we will fail to register the machine after restart and fail. But this case
was already broken, because machined would create a stop job, breaking the
restart. So not doing anything with old machined should not make anything
more broken than it already is.)
Fixes#13766.
This is the opposite of RegisterMachine: machined knows that the machine is
"gone", but doesn't do anything on its own. We already had TerminateMachine,
but that would stop the unit, which isn't always wanted.
It was done for mount units already (see commit 142b8142d7). For the
same reasons and for consistency we should also stop activating automagically
swaps when their device is hot-plugged.
It is pretty common for the service to fail in the initramfs (for example
because certain modules have not been copied over or haven't been built yet in
case of dkms modules). This seems to be more trouble than it is worth. Let's
change the service to simply log any missing modules at error level, but not
fail the whole service.
https://bugzilla.redhat.com/show_bug.cgi?id=1254340
From the bug:
> According to the documentation of systemd.automount if the automoint point is
> automagically created if it doesn't exist yet. This ofcourse means the
> filesystem underneath has to be writable, which for / means not only does
> -.mount need to be started but also systemd-remount-fs.service has to be run,
> which isn't guaranteed by the default automount dependencies.
>
> For .mount units there is an automatic default After= dependency on
> local-fs-pre.target, would probably make sense to do the same for automount
> units to avoid it failing on the corner-case where it has to create directory.
Fixes#13306.
Allow earlier PAM modules to set `systemd.runtime_max_sec`. If they do,
parse it and set it as the `RuntimeMaxUSec=` property of the session
scope, to limit the maximum lifetime of the session. This could be
useful for time-limiting login sessions, for example.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #12035
Just as `RuntimeMaxSec=` is supported for service units, add support for
it to scope units. This will gracefully kill a scope after the timeout
expires from the moment the scope enters the running state.
This could be used for time-limited login sessions, for example.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #12035
Per https://github.com/mesonbuild/meson/issues/5003, ternary doesn't
always work as function args with older versions of meson.
Expand out ternary statements to stay compatible with older versions (< 0.49).
As discussed on systemd-devel [1], in Fedora we get lots of abrt reports
about the watchdog firing [2], but 100% of them seem to be caused by resource
starvation in the machine, and never actual deadlocks in the services being
monitored. Killing the services not only does not improve anything, but it
makes the resource starvation worse, because the service needs cycles to restart,
and coredump processing is also fairly expensive. This adds a configuration option
to allow the value to be changed. If the setting is not set, there is no change.
My plan is to set it to some ridiculusly high value, maybe 1h, to catch cases
where a service is actually hanging.
[1] https://lists.freedesktop.org/archives/systemd-devel/2019-October/043618.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1300212
