We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/
towards the user unit being "enabled", because the symlinks were not
located in "config" paths. But this is confusing to users, since those units
are clearly enabled and will be started. So let's muddle the definition of
enablement a bit to include the paths only accessible to root when looking for
enabled user units.
Fixes#4432.
I think this matches the spirit of "indirect" well: the unit
*might* be active, even though it is not "installed" in the
sense of symlinks created based on the [Install] section.
The changes to test-install-root touch the same lines as in the previous
commit; the change in each case is from
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_ENABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_DISABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_INDIRECT)
in the last two commits.
When a unit has a symlink that makes an alias in the filesystem,
but that name is not specified in [Install], it is confusing
is the unit is shown as "enabled". Look only for names specified
in Alias=.
Fixes#6338.
v2:
- Fix indentation.
- Fix checking for normal enablement, when the symlink name is the same as the
unit name. This case wasn't handled properly in v1.
v3:
- Rework the patch to also handle templates properly:
A template templ@.service with DefaultInstance=foo will be considered
enabled only when templ@foo.service symlink is found. Symlinks with
other instance names do not count, which matches the logic for aliases
to normal units. Tests are updated.
The timezone was cut off the string once the timezone was not UTC.
If it is not UTC but a other timezone that matches tzname[0] or
tzname[1], then we can leave it to the impl function to parse that
correctly. If not we can just fallback to whatever is the current
timezone is in the given t_timezone.
This should fix the testuite and tests.
This adds a new setting LineMax= to journald.conf, and sets it by
default to 48K. When we convert stream-based stdout/stderr logging into
record-based log entries, read up to the specified amount of bytes
before forcing a line-break.
This also makes three related changes:
- When a NUL byte is read we'll not recognize this as alternative line
break, instead of silently dropping everything after it. (see #4863)
- The reason for a line-break is now encoded in the log record, if it
wasn't a plain newline. Specifically, we distuingish "nul",
"line-max" and "eof", for line breaks due to NUL byte, due to the
maximum line length as configured with LineMax= or due to end of
stream. This data is stored in the new implicit _LINE_BREAK= field.
It's not synthesized for plain \n line breaks.
- A randomized 128bit ID is assigned to each log stream.
With these three changes in place it's (mostly) possible to reconstruct
the original byte streams from log data, as (most) of the context of
the conversion from the byte stream to log records is saved now. (So,
the only bits we still drop are empty lines. Which might be something to
look into in a future change, and which is outside of the scope of this
work)
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=86465
See: #4863
Replaces: #4875
The documentation explained that the message doesn't really mean what it says,
but I think it's better to just make the message more straightforward.
Fixes#6554.
Now generators are only run in systemd --test mode, where this makes
most sense (how are you going to test what would happen otherwise?).
Fixes#6842.
v2:
- rename test_run to test_run_flags
This makes it possible to run more dbus tests in a build
environment/chroot where no system bus is available.
To run the dbus test one then can use dbus-run-session.
closes#6854
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off <==========================
Typically when DHCP server sets MTU it is a lower one. And a lower than usual
MTU is then thus required on said network to have operational networking. This
makes networkd's dhcp client to work in more similar way to other dhcp-clients
(e.g. isc-dhcp). In particular, in a cloud setting, without this default
instances have resulted in timing out talking to cloud metadata source and
failing to provision.
This does not change this default for the Annonymize code path.
For the session identifier, the code is currently slightly stricter, because it
only uses digits and letters, than the description. This should be OK.
Fixes#6745.
The document on the wiki is partially outdated and not very visible. Let's
import the gist of it here. The original text is retained, with only grammar
and stylistic and formatting changes.
It's confusing to use a single void* to store data with two different
types, i.e. a userdata value which is safe to pass to ->find(), and a
userdata value which identifies the found object.
Name the latter `found_u`. This naming treats (!c->find) as a degenerate
case. (I.e. at that point, we know the object has already been found :).
Before this commit, if you run `loginctl user-status` from
debug-shell.service (and you have no login sessions for root), you always
see this output:
0
Linger: no
because Properties.GetAll is returning success but without any properties,
when the only find() callback had returned 0 to mean "no object found".
After:
Could not get properties: Unknown object:
'/org/freedesktop/login1/user/self'
BTW I have a fix for more user-friendly messages from logind in this case.
It is pending in my local branch for #6829 "fix `loginctl enable-linger`".
The problem was with the tm.tm_isdst that is set to the current environment
value: either DST or not. While the current state is not relevant to the state
in the desired date.
Hence — it should be reset so that the mktime_or_timegm could normalise it
later.
Commit 0e8856d2 (assemble multidevice btrfs volumes without external
tools (#6607)) introduced a call to udevadm. That lives in @rootbindir@,
not @rootlibexecdir@. So fix the path.
We settled on "filename" and "file system", so change a couple of places for
consistency. The exception is when there's an adjective before "file" that
binds more strongly then "name": "password file name", "output file name", etc.
Those cases are left intact.
