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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We already *install* those as real files since de78fa9ba0.
Meson will start to copy symlinks as-is, so we would get dangling symlinks in
/usr/lib/systemd/user/.
I considered the layout in our sources to match the layout in the installation
filesystem (i.e. creating units/system/ and moving all files from units/ to
units/system/), but that seems overkill. By using normal files for both we get
some duplication, but those files change rarely, so it's not a big downside in
practice.
Fixes#9906.
Let's simplify things and drop the logic that /var/lib/machines is setup
as auto-growing btrfs loopback file /var/lib/machines.raw.
THis was done in order to make quota available for machine management,
but quite frankly never really worked properly, as we couldn't grow the
file system in sync with its use properly. Moreover philosophically it's
problematic overriding the admin's choice of file system like this.
Let's hence drop this, and simplify things. Deleting code is a good
feeling.
Now that regular file systems provide project quota we could probably
add per-machine quota support based on that, hence the btrfs quota
argument is not that interesting anymore (though btrfs quota is a bit
more powerful as it allows recursive quota, i.e. that the machine pool
gets an overall quota in addition to per-machine quota).
Otherwise we might install the socket unit early, but the service
backing it late, and then end up in strange loops when we enter rescue
mode, because we saw an event on /dev/rfkill but really can't dispatch
it nor flush it.
Fixes: #9171
now that logind doesn't mount $XDG_RUNTIME_DIR anymore we can lock down
the service using fs namespacing (as we don't need the mount to
propagate to the host namespace anymore).
Previously, setting this option by default was problematic due to
SELinux (as this would also prohibit the transition from PID1's label to
the service's label). However, this restriction has since been lifted,
hence let's start making use of this universally in our services.
On SELinux system this change should be synchronized with a policy
update that ensures that NNP-ful transitions from init_t to service
labels is permitted.
An while we are at it: sort the settings in the unit files this touches.
This might increase the size of the change in this case, but hopefully
should result in stabler patches later on.
Fixes: #1219
I found zero references to busnames.target, using git grep "busnames".
(And we do not install using a wildcard units/*.*. There is no
busnames.target installed on my Fedora 28 system).
THis dep existed since the unit was introduced, but I cannot see what
good it would do. Hence in the interest of simplifying things, let's
drop it. If breakages appear later we can certainly revert this again.
Fixes: #10469
This is might be useful in some cases, but it's primarily an example for
a boot check service that can be plugged before boot-complete.target.
It's disabled by default.
All it does is check whether the failed unit count is zero
This is the counterpiece to the boot counting implemented in
systemd-boot: if a boot is detected as successful we mark drop the
counter again from the booted snippet or kernel image.
C.f. 287419c119: 'systemctl exit 42' can be
used to set an exit value and pulls in exit.target, which pulls in systemd-exit.service,
which calls org.fdo.Manager.Exit, which calls method_exit(), which sets the objective
to MANAGER_EXIT. Allow the same to happen through SuccessAction=exit.
v2: update for 'exit' and 'exit-force'
Explicit systemctl calls remain in systemd-halt.service and the system
systemd-exit.service. To convert systemd-halt, we'd need to add
SuccessAction=halt-force. Halting doesn't make much sense, so let's just
leave that is. systemd-exit.service will be converted in the next commit.
This updates the unit files of all our serviecs that deal with journal
stuff to use a higher RLIMIT_NOFILE soft limit by default. The new value
is the same as used for the new HIGH_RLIMIT_NOFILE we just added.
With this we ensure all code that access the journal has higher
RLIMIT_NOFILE. The code that runs as daemon via the unit files, the code
that is run from the user's command line via C code internal to the
relevant tools. In some cases this means we'll redundantly bump the
limits as there are tools run both from the command line and as service.
So far we always used "yes" instead of "true" in all our unit files,
except for one outlier. Let's do this here too. No change in behaviour
whatsoever, except that it looks prettier ;-)
I think this is a slightly cleaner approach than parsing the
configuration file at multiple places, as this way there's only a single
reload cycle for logind.conf, and that's systemd-logind.service's
runtime.
This means that logind and dbus become a requirement of
user-runtime-dir, but given that XDG_RUNTIME_DIR is not set anyway
without logind and dbus around this isn't really any limitation.
This also simplifies linking a bit as this means user-runtime-dir
doesn't have to link against any code of logind itself.
Let's not use the word "wrapper", as it's not clear what that is, and in
some way any unit file is a "wrapper"... let's simply say that it's
about the runtime directory.
If for any reason local-fs.target fails at startup while a password is
requested by systemd-cryptsetup@.service, we end up with the emergency shell
competing with systemd-ask-password-console.service for the console.
This patch makes sure that:
- systemd-ask-password-console.service is stopped before entering in emergency
mode so it won't make any access to the console while the emergency shell is
running.
- systemd-ask-password-console.path is also stopped so any attempts to restart
systemd-cryptsetup in the emergency shell won't restart
systemd-ask-password-console.service and kill the emergency shell.
- systemd-ask-password-wall.path is stopped so
systemd-ask-password-wall.service won't be started as this service pulls
the default dependencies in.
Fixes: #10131
This reverts commit d4e9e574ea.
(systemd.conf.m4 part was already reverted in 5b5d82615011b9827466b7cd5756da35627a1608.)
Together those reverts should "fix" #10025 and #10011. ("fix" is in quotes
because this doesn't really fix the underlying issue, which is combining
DynamicUser= with strict container sandbox, but it avoids the problem by not
using that feature in our default installation.)
Dynamic users don't work well if the service requires matching configuration in
other places, for example dbus policy. This is true for those three services.
In effect, distros create the user statically [1, 2]. Dynamic users make more
sense for "add-on" services where not creating the user, or more precisely,
creating the user lazily, can save resources. For "basic" services, if we are
going to create the user on package installation anyway, setting DynamicUser=
just creates unneeded confusion. The only case where it is actually used is
when somebody forgets to do system configuration. But it's better to have the
service fail cleanly in this case too. If we want to turn on some side-effect
of DynamicUser=yes for those services, we should just do that directly through
fine-grained options. By not using DynamicUser= we also avoid the need to
restart dbus.
[1] bd9bf30727
[2] 48ac1cebde/f/systemd.spec (_473)
(Fedora does not create systemd-timesync user.)
systemd-tmpfiles-setup.service needs to be ordered after
systemd-journald.service, so entries in /run/log/journal are already
created when systemd-tmpfiles tries to adjust its permissions.
This is specially problematic for setups using a volatile journal where
the initrd does not ship a machine-id (i.e. OSTree-based systems), where
logs from the initrd will be inaccessible for users in the
systemd-journal group. It also has a side effect of `journalctl --user`
failing with "No journal files were opened due to insufficient
permissions".
Fixes#10128.
We would create a useless empty directory under build/.
It seems we were lucky and all symlinks were installed into directories
which were alredy created because we installed something into the same
location earlier.
While at it, also add '-v' to 'mkdir -p'. This will print the names of
directories as they are created (just once), making it easier to see all of
what the install script is doing.
This reverts commit 48d3e88c18.
I kept the follow-symlink=false → follow-symlink=true change instact, since
we're likely to have existing installations with a symlink now.
Followup to commit 13cf422e04b7 ("user@.service: don't kill user manager at runlevel switch")
I think there's a general rule that units with `StopWhenUnneeded=yes` need
`IgnoreOnIsolate=yes`... But it doesn't apply to `suspend.target` and friends.
`printer.target` and friends break on isolate even if we apply the rule[1].
That just leaves `graphical-session.target`, which is a user service.
"isolate" is *mostly* a weird attempt to emulate runlevels, so I decided
not to worry about it for user services.
[1] https://github.com/systemd/systemd/issues/6505#issuecomment-320644819
Loggin in as root user and then switching the runlevel results in a
stop of the user manager, even though the user ist still logged in.
That leaves a broken user session.
Adding "IgnoreOnIsolate=true" to user@.service fixes this.
This service won't use much resources, but it's certainly nicer to see
it attached th the user's slice along with user@.service, so that
everything we run for a specific user is properly bound into one unit.
We use systemd-user-sessions.service as barrier when to allow login
sessions. With this patch user@.service is ordered after that too, so
that any login related code (which user-runtime-dir@.service is) is
guaranteed to run after the barrier, and never before.
This is an additional synchronization point normally not needed. Hence,
let's make it passive, i.e. pull it in from the unit which wants to be
ordered before the update service rather than by the update service
itself.
systemd offline-updates allows dropping multiple system update units
to be added to system-update.target.wants.
As documented in systemd.offline-updates(7) only 1 of these units
should actually be active (based on the /system-update symlink) and
when that unit is done it should reboot the system.
In some cases it is desirable to run a unit whenever booting in
offline-updates mode indepedent of which update unit is going to
handle the update. One example of this is integration with bootloader
code which checks if the previous boot was succesful.
Since the active unit will reboot the system when it is done, there
is no guarantee that adding such a unit to system-update.target.wants
will get it executed always.
This commit adds a system-update-pre.target which can be used for
units which should always run when booting in offline-updates mode.
This is generally the safer approach, and is what container managers
(including nspawn) do, hence let's move to this too for our own
services. This is particularly useful as this this means the new
@system-service system call filter group will get serious real-life
testing quickly.
This also switches from firing SIGSYS on unexpected syscalls to
returning EPERM. This would have probably been a better default anyway,
but it's hard to change that these days. When whitelisting system calls
SIGSYS is highly problematic as system calls that are newly introduced
to Linux become minefields for services otherwise.
Note that this enables a system call filter for udev for the first time,
and will block @clock, @mount and @swap from it. Some downstream
distributions might want to revert this locally if they want to permit
unsafe operations on udev rules, but in general this shiuld be mostly
safe, as we already set MountFlags=shared for udevd, hence at least
@mount won't change anything.
This adds a small service "systemd-portabled" and a matching client
"portablectl", which implement the "portable service" concept.
The daemon implements the actual operations, is PolicyKit-enabled and is
activated on demand with exit-on-idle.
Both the daemon and the client are an optional build artifact, enabled
by default rhough.
Unfortunately this needs a new binary to do the mount because there's just
too many special steps to outsource this to systemd-mount:
- EPERM needs to be treated specially
- UserRuntimeDir= setting must be obeyed
- SELinux label must be adjusted
This allows user@.service to be started independently of logind.
So 'systemctl start user@nnn' will start the user manager for user nnn.
Logind will start it too when the user logs in, and will stop it (unless
lingering is enabled) when the user logs out.
Fixes#7339.
This removes the UserTasksMax= setting in logind.conf. Instead, the generic
TasksMax= setting on the slice should be used. Instead of a transient unit we
use a drop-in to tweak the default definition of a .slice. It's better to use
the normal unit mechanisms instead of creating units on the fly. This will also
make it easier to start user@.service independently of logind, or set
additional settings like MemoryMax= for user slices.
The setting in logind is removed, because otherwise we would have two sources
of "truth": the slice on disk and the logind config. Instead of trying to
coordinate those two sources of configuration (and maintainer overrides to
both), let's just convert to the new one fully.
Right now now automatic transition mechanism is provided. logind will emit a
hint when it encounters the setting, but otherwise it will be ignored.
Fixes#2556.
Systems that have an accurate real-time clock may have an initial
unsynchronized time that is close enough to the synchronized time that
the final adjustment doesn't trigger a waking "clock set" event. Have
timesyncd touch a file in its runtime directory as a secondary signal
for synchronization. Continue to support the timerfd-based trigger as a
sufficient condition when the watchfile is not present.
Closes issue #8683
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
We still get the errors logged, but we don't fail the service. This
is better for users because rerunning tmpfiles-setup.service a second
time is dangerous (c.f. cd9f5b68ce).
Note that this only touches sd-tmpfiles-setup.service and
sd-tmpfiles-setup-dev.service. sd-tmpfiles-clean.service is as before.
https://bugzilla.redhat.com/show_bug.cgi?id=1539341
Use `systemctl --user --force exit` to implement the systemd-exit
user service.
This removes our dependence on an external `kill` binary and the
concerns about whether they recognize SIGRTMIN+n by name or what their
interpretation of SIGRTMIN is.
Tested: `systemctl --user start systemd-exit.service` kills the
`systemd --user` instance for my user.
Suspend to Hibernate is a new sleep method that invokes suspend
for a predefined period of time before automatically waking up
and hibernating the system.
It's similar to HybridSleep however there isn't a performance
impact on every suspend cycle.
It's intended to use with systems that may have a higher power
drain in their supported suspend states to prevent battery and
data loss over an extended suspend cycle.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
CPU accounting has a too bad impact on performance to be enabled by
default. Therefore we should not delegate "cpu" for now.
OTOH since commit e0c46a7364, memory accounting
has been turned on for all units by default so it makes sense to delegate this
controller by default.
`-.mount` is placed in `system.slice`, and hence depends on it.
`-.mount` is always active and can never be stopped. Therefore the same
should be true of `system.slice`.
Synthesize it as perpetual (unless systemd is running as a user manager).
Notice we also drop `Before=slices.target` as unnecessary.
AFAICS the justification for `perpetual` is to provide extra protection
against unintentionally stopping every single service. So adding
system.slice to the perpetual units is perfectly consistent.
I don't expect this will (or can) fix any other problem. And the
`perpetual` protection probably isn't formal enough to spend much time
thinking about. I've just noticed this a couple of times, as something
that looks strange.
Might be a bit surprising that we have user.slice on-disk but not
system.slice, but I think it's ok. `systemctl status system.slice` will
still point you towards `man systemd.special`. The only detail is that the
system slice disables `DefaultDependencies`. If you're worrying about how
system shutdown works when you read `man systemd.slice`, I think it is not
too hard to guess that system.slice might do this:
> Only slice units involved with early boot
> or late system shutdown should disable this option
(Docs are great. I really appreciate the systemd ones).
On systems that only use resolved for name resolution, there are usecases that
require resolved to be started before sysinit target, such that network name
resolution is available before network-online/sysinit targets. For example,
cloud-init for some datasources hooks into the boot process ahead of sysinit
target and may need network name resolution at that point already.
systemd-resolved already starts pretty early in the process, thus starting it
slightly earlier should not have negative side effects.
However, this depends on resolved ability to connect to system DBus once that
is up.
Now that we can configure which controllers to delegate precisely, let's
limit wht we delegate to the user session: only "cpu" and "pids" as a
minimal baseline.
Fixes: #1715
An explicit --user switch is necessary because for the user@0.service instance
systemd-tmpfiles is running as root, and we need to distinguish that from
systemd-tmpfiles running in systemd-tmpfiles*.service.
Fixes#2208.
v2:
- restore "systemd-" prefix
- add systemd-tmpfiles-clean.{service,timer}, systemd-setup.service to
systemd-tmpfiles(8)
This makes sense from the point of view of the whole distribution:
if there are some specific files that have syntax problems, or unknown
users or groups, or use unsupported features, failing the whole service
is not useful.
In particular, services with tmpfiles --boot should not be started after boot.
The premise of --boot is that there are actions which are only safe to do once
during boot, because the state evolves later through other means and re-running
the boot-time setup would destroy it. If services with --boot fail in the
initial transaction, they would be re-run later on when a unit which
(indirectly) depends on them is started, causing problems.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1507501.
(If we had a mode where a service would at most run once, and would not be
started in subsequent transactions, that'd be a good additional safeguard.
Using ExecStart=-... is a bit like that, but it causes all failure to be
ignored, which is too big of a hammer.)
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
There should be a way to turn this logic of, and DefaultDependencies=
appears to be the right option for that, hence let's downgrade this
dependency type from "implicit" to "default, and thus honour
DefaultDependencies=.
This also drops mount_get_fstype() as we only have a single user needing
this now.
A follow-up for #7076.
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.
In the past we introduced this property just for tmp.mount. However on
todays systems usually there are many more tmpfs mounts. Most notably
mounts backing XDG_RUNTIME_DIR for each user.
Let's generalize what we already have for tmp.mount and implement the
ordering After=swap.target for all tmpfs based mounts.
This makes this target the same as remote-fs.target in this regard. In practice
it probably doesn't make that much difference, because all encrypted devices
that are part of remote-fs.target (marked with _netdev) will be used for mount
points, so they will be pulled in anyway individually, but with this change any
such device will be configured, even if it is not pulled by any other unit.
