IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Explanation:
"Please note the login session may be limited to a stub
process or two. User processes may instead be started from their
systemd user manager, e.g. GUI applications started using DBus
activation, as well as service processes which are shared between
multiple logins of the same user."
The most glaring example being when you run commands from gnome-terminal,
or as you see nowadays, "gnome-terminal-server".
*_get_session() is still currently used (directly or indirectly) by Xorg,
Weston etc. running within the session scope. That setup is perfectly
functional, although code will be more generally useful if it is able to
run outside the session scope.[1]
[1] https://wiki.archlinux.org/index.php/Systemd/User#Xorg_as_a_systemd_user_service
Re-order the man pages a bit at the same time. This is to avoid having the
first and titular entry introduce the session concept, and then immediately
try and persuade you not to use it :).
remote-cryptsetup-pre.target was designed as an active unit (that pulls in
network-online.target), the opposite of remote-fs-pre.target (a passive unit,
with individual provider services ordering itself before it and pulling it in,
for example iscsi.service and nfs-client.target).
To make remote-cryptsetup-pre.target really work, those services should be
ordered before it too. But this would require updates to all those services,
not just changes from systemd side.
But the requirements for remote-fs-pre.target and remote-cryptset-pre.target
are fairly similar (e.g. iscsi devices can certainly be used for both), so
let's reuse remote-fs-pre.target also for remote cryptsetup units. This loses
a bit of flexibility, but does away with the requirement for various provider
services to know about remote-cryptsetup-pre.target.
Commit 5248e7e1f1
(resolved,nss-myhostname: use _gateway for the gateway) changed how the
gateway is resolved. Reflect the change in documentation.
Close#7084.
We should be careful when talking about "units" and "unit files". The
latter should be the concept on disk, and the former, the loaded version
of it. However, as a single unit file can result in multiple loaded
units (think templates), and a units can also exist with no unit file at
all (think .device units), we should be precise.
As symlinks are created on unit files rather than units (as symlinks are
an fs object, and unit files are too, but units are not), let's say so
here.
This adds "systemd-resolve --reset-server-features" for explicitly
forgetting what we learnt. This might be useful for debugging
purposes, and to force systemd-resolved to restart its learning logic
for all DNS servers.
This documents the status quo, clarifying when we are synchronous and
when asynchronous by default and when --no-block is support to force
asynchronous operation.
See: #6479
The configuration option was called -Dresolve, but the internal define
was …RESOLVED. This options governs more than just resolved itself, so
let's settle on the version without "d".
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
This removes the '@credentials' syscall set that was added in commit
v234-468-gcd0ddf6f75.
Most of these syscalls are so simple that we do not want to filter them.
They work on the current calling process, doing only read operations,
they do not have a deep kernel path.
The problem may only be in 'capget' syscall since it can query arbitrary
processes, and used to discover processes, however sending signal 0 to
arbitrary processes can be used to discover if a process exists or not.
It is unfortunate that Linux allows to query processes of different
users. Lets put it now in '@process' syscall set, and later we may add
it to a new '@basic-process' set that allows most basic process
operations.
Starting with kernel version 4.8 the kernel has a single `l3mdev` rule
that handles this. This rule will be created when the first VRF device
is added.
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 <!-- --> comment lines resulted in double newlines in the man page
header, which looks quite ugly. Let's rearrange a bit so that these
comments don't result in changes in the output.
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.
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.
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.
Usually, it's a good thing that we isolate the kernel session keyring
for the various services and disconnect them from the user keyring.
However, in case of the cryptsetup key caching we actually want that
multiple instances of the cryptsetup service can share the keys in the
root user's user keyring, hence we need to be able to disable this logic
for them.
This adds KeyringMode=inherit|private|shared:
inherit: don't do any keyring magic (this is the default in systemd --user)
private: a private keyring as before (default in systemd --system)
shared: the new setting
That advice is generally apropriate for "user" programs, i.e. programs which
are run interactively and used pipelines and such. But it makes less sense for
daemons to propagate the exit signal. For example, if a process receives a SIGTERM,
it is apropriate for it to exit with 0 code. So let's just delete the whole
paragraph, since this page doesn't seem to be the right place for the longer
discussion which would be required to mention all the caveats and considerations.
Fixes#6415.
This reverts commit 0ffddc6e2c. That
causes a rather severe disruption of D-Bus and other services when e. g.
restarting local-fs.target (as spotted by the "storage" test regression).
Fixes#6834
If two separate log streams are connected to stdout and stderr, let's
make sure $JOURNAL_STREAM points to the latter, as that's the preferred
log destination, and the environment variable has been created in order
to permit services to automatically upgrade from stderr based logging to
native journal logging.
Also, document this behaviour.
Fixes: #6800
Routing Policy rule manipulates rules in the routing policy database control the
route selection algorithm.
This work supports to configure Rule
```
[RoutingPolicyRule]
TypeOfService=0x08
Table=7
From= 192.168.100.18
```
```
ip rule show
0: from all lookup local
0: from 192.168.100.18 tos 0x08 lookup 7
```
V2 changes:
1. Added logic to handle duplicate rules.
2. If rules are changed or deleted and networkd restarted
then those are deleted when networkd restarts next time
V3:
1. Add parse_fwmark_fwmask
Let's lock things down a bit, and maintain a list of what's permitted
rather than a list of what's prohibited in nspawn (also to make things a
bit more like Docker and friends).
Note that this slightly alters the effect of --system-call-filter=, as
now the negative list now takes precedence over the positive list.
However, given that the option is just a few days old and not included
in any released version it should be fine to change it at this point in
time.
Note that the whitelist is good chunk more restrictive thatn the
previous blacklist. Specifically:
- fanotify is not permitted (given the buffer size issues it's
problematic in containers)
- nfsservctl is not permitted (NFS server support is not virtualized)
- pkey_xyz stuff is not permitted (really new stuff I don't grok)
- @cpu-emulation is prohibited (untested legacy stuff mostly, and if
people really want to run dosemu in nspawn, they should use
--system-call-filter=@cpu-emulation and all should be good)
With this setting we can explicitly unset specific variables for
processes of a unit, as last step of assembling the environment block
for them. This is useful to fix#6407.
While we are at it, greatly expand the documentation on how the
environment block for forked off processes is assembled.
Fixes#6639.
(This behaviour of systemd-sysusers is long established, so it's better
to adjust the documentation rather than change the code. If there are any
situations out there where it matters, users must have adjusted to the
current behaviour.)
"Currently, the following values are defined: xxx: in case <condition>" is
awkward because "xxx" is always defined unconditionally. It is _used_ in case
<condition> is true. Correct this and a bunch of other places where the
sentence structure makes it unclear what is the subject of the sentence.
This reworks the paragraph describing $SERVICE_RESULT into a table, and
adds two missing entries: "success" and "start-limit-hit".
These two entries are then also added to the table explaining the
$EXIT_CODE + $EXIT_STATUS variables.
Fixes: #6597
In this mode, we'll directly connect stdin/stdout/stderr of the invoked
service with whatever systemd-run itself is invoked on. This allows
inclusion of "systemd-run" commands in shell pipelines, as unlike
"--pty" this means EOF of stdin/stdout/stderr are propagated
independently.
If --pty and --pipe are combined systemd-run will automatically pick the
right choice for the context it is invoked in, i.e. --pty when invoked
on a TTY, and --pipe otherwise.
Now that we have ported nspawn's seccomp code to the generic code in
seccomp-util, let's extend it to support whitelisting and blacklisting
of specific additional syscalls.
This uses similar syntax as PID1's support for system call filtering,
but in contrast to that always implements a blacklist (and not a
whitelist), as we prepopulate the filter with a blacklist, and the
unit's system call filter logic does not come with anything
prepopulated.
(Later on we might actually want to invert the logic here, and
whitelist rather than blacklist things, but at this point let's not do
that. In case we switch this over later, the syscall add/remove logic of
this commit should be compatible conceptually.)
Fixes: #5163
Replaces: #5944
The values for StartLimitAction are defined in `man systemd.unit`.
Don't send people to `man systemd.service` just to find they need to look
back in `man systemd.unit` again :).
They’re counterparts to the existing set-log-level and set-log-target
verbs, simply printing the current value to stdout. This makes it
slightly easier to temporarily change the log level and/or target and
then restore the old value(s).
Add prefix delegation documentation covering IPv6PrefixDelegation=
setting in the Network section as well as all the parameters and
the IPv6PrefixDelegation and IPv6Prefix sections implemented so
far, including DNS= and DNSLifetimeSec= settings.
The pair is similar to remote-fs.target and remote-fs-pre.target. Any
cryptsetup devices which require network shall be ordered after
remote-cryptsetup-pre.target and before remote-cryptsetup.target.
They already were mostly ordered alphabetically, but some disorder
snuck in.
Also, fix formatting. Some options were described using "--" prefixes, which
looks like the text was just copied from crypttab(8).
Now we don't support tunnels to be created without a .network file
that is we need a interface index.
This work allows tunnel to be created without a ifindex.
Closes#6695
The irreversible job mode is required to ensure that shutdown is not
interrupted by the activation of a unit with a conflict.
We already used the correct job mode for `ctrl-alt-del.target`. But not
for `exit.target` (SIGINT of user manager). The SIGRT shutdown signals
also needed fixing.
Also change SIGRTMIN+0 to isolate default.target, instead of starting
it. The previous behaviour was documented. However there was no reason
given for it, nor can we provide one. The problem that isolate is too
aggressive anywhere outside of emergency.target (#2607) is orthogonal.
This feature is "accessible by different means and only really a safety
net"; it is confusing for it to differ from `systemctl default` without
explanation.
`AllowIsolate=yes` is retained on poweroff.target etc. for backwards
compatibility.
`sigpwr.target` is also an obvious candidate for linking to a shutdown
target. Unforunately it is also a possible hook for implementing some
logic like system V init did, reading `/etc/powerstatus`. If we switched
to starting `sigpwr.target` with REPLACE_IRREVERSIBLY, attempts to run
`systemctl shutdown` from it would fail, if they had not thought to set
`DefaultDependencies=no`. We had provided no examples for `sigpwr`, and
the whole idea is cruft to keep legacy people happy. For the moment, I
leave `sigpwr` alone, with no risk of disrupting anyone's
previously-working, half-working, or untested setup.
Fixes#6484. See also #6471
It's like Manager.PowerOff(), which does not start poweroff.target.
Instead, the dbus methods are used for `systemctl --force exit`
or `systemctl --force poweroff`. They shut down the system without
processing individual unit's ExecStop or TimeoutStopSec.
This new target is a passive unit, hence it is supposed to be pulled in
to the transaction by the service that wants to block login on the
console (e.g. text version of initial-setup). Now both getty and
serial-getty are ordered after this target.
https://lists.freedesktop.org/archives/systemd-devel/2015-July/033754.html
The last sentence in the paragraph described the behaviour of `--global`. But "the last case" we listed was "only this boot", which does not match... This was the fifth case described, but there are only _four_ different option names. Fix it.
Add LockPersonality boolean to allow locking down personality(2)
system call so that the execution domain can't be changed.
This may be useful to improve security because odd emulations
may be poorly tested and source of vulnerabilities, while
system services shouldn't need any weird personalities.
This patch adds two new special character prefixes to ExecStart= and
friends, in addition to the existing "-", "@" and "+":
"!" → much like "+", except with a much reduced effect as it only
disables the actual setresuid()/setresgid()/setgroups() calls, but
leaves all other security features on, including namespace
options. This is very useful in combination with
RuntimeDirectory= or DynamicUser= and similar option, as a user
is still allocated and used for the runtime directory, but the
actual UID/GID dropping is left to the daemon process itself.
This should make RuntimeDirectory= a lot more useful for daemons
which insist on doing their own privilege dropping.
"!!" → Similar to "!", but on systems supporting ambient caps this
becomes a NOP. This makes it relatively straightforward to write
unit files that make use of ambient capabilities to let systemd
drop all privs while retaining compatibility with systems that
lack ambient caps, where priv dropping is the left to the daemon
codes themselves.
This is an alternative approach to #6564 and related PRs.
This new group lists all UID/GID credential changing syscalls (which are
quite a number these days). This will become particularly useful in a
later commit, which uses this group to optionally permit user credential
changing to daemons in case ambient capabilities are not available.
Currently if tmpfiles is run with force on symlink creation but there already
exists a directory at that location, the creation will fail. This change
updates the behavior to remove the directory with rm_fr and then attempts to
create the symlink again.
