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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
With this in place RPMs can make sure that whatever they drop in is
immeidately applied, and not delayed until next reboot.
This also moves systemd-sysusers back to /usr/bin, since hardcoding the
path to /usr/lib in the macros would mean compatibility breaks in
future, should we turn sysusers into a command that is actually OK for
people to call directly. And given that that is quite likely to happen
(since it is useful to prepare images with its --root= switch), let's
just prepare for it.
This new condition allows checking whether /etc or /var are out-of-date
relative to /usr. This is the counterpart for the update flag managed by
systemd-update-done.service. Services that want to be started once after
/usr got updated should use:
[Unit]
ConditionNeedsUpdate=/etc
Before=systemd-update-done.service
This makes sure that they are only run if /etc is out-of-date relative
to /usr. And that it will be executed after systemd-update-done.service
which is responsible for marking /etc up-to-date relative to the current
/usr.
ConditionNeedsUpdate= will also checks whether /etc is actually
writable, and not trigger if it isn't, since no update is possible then.
In order to support offline updates to /usr, we need to be able to run
certain tasks on next boot-up to bring /etc and /var in line with the
updated /usr. Hence, let's devise a mechanism how we can detect whether
/etc or /var are not up-to-date with /usr anymore: we keep "touch
files" in /etc/.updated and /var/.updated that are mtime-compared with
/usr. This means:
Whenever the vendor OS tree in /usr is updated, and any services that
shall be executed at next boot shall be triggered, it is sufficient to
update the mtime of /usr itself. At next boot, if /etc/.updated and/or
/var/.updated is older than than /usr (or missing), we know we have to
run the update tools once. After that is completed we need to update the
mtime of these files to the one of /usr, to keep track that we made the
necessary updates, and won't repeat them on next reboot.
A subsequent commit adds a new ConditionNeedsUpdate= condition that
allows checking on boot whether /etc or /var are outdated and need
updating.
This is an early step to allow booting up with an empty /etc, with
automatic rebuilding of the necessary cache files or user databases
therein, as well as supporting later updates of /usr that then propagate
to /etc and /var again.
We install two sysctl snippets ourselves, hence the condition will
always trigger, so no point in tryng to optimize things with this, it
just will make things slower, if anything.
There's no point in conditionalizing systemd-tmpfiles at boot, since we
ship tmpfiles snippets ourselves, hence they will always trigger anyway.
Also, there's no reason to pull in local-fs.target from the service,
hence drop that.
There might be implementations around where the network-online logic
might not talk to any network configuration service (and thus not have
to wait for it), hence let's explicitly order network-online.target
after network.target to avoid any ambiguities.
network-pre.target is a passive target that should be pulled in by
services that want to be executed before any network is configured (for
example: firewall scrips).
network-pre.target should be ordered before all network managemet
services (but not be pulled in by them).
network-pre.target should be order after all services that want to be
executed before any network is configured (and be pulled in by them).
Also, rename ProtectedHome= to ProtectHome=, to simplify things a bit.
With this in place we now have two neat options ProtectSystem= and
ProtectHome= for protecting the OS itself (and optionally its
configuration), and for protecting the user's data.
Either become uid/gid of the client we have been forked for, or become
the "systemd-bus-proxy" user if the client was root. We retain
CAP_IPC_OWNER so that we can tell kdbus we are actually our own client.
ReadOnlySystem= uses fs namespaces to mount /usr and /boot read-only for
a service.
ProtectedHome= uses fs namespaces to mount /home and /run/user
inaccessible or read-only for a service.
This patch also enables these settings for all our long-running services.
Together they should be good building block for a minimal service
sandbox, removing the ability for services to modify the operating
system or access the user's private data.
Rely on modules being built-in or autoloaded on-demand.
As networkd is a network facing service, we want to limits its capabilities,
as much as possible. Also, we may not have CAP_SYS_MODULE in a container,
and we want networkd to work the same there.
Module autoloading does not always work, but should be fixed by the kernel
patch f98f89a0104454f35a: 'net: tunnels - enable module autoloading', which
is currently in net-next and which people may consider backporting if they
want tunneling support without compiling in the modules.
Early adopters may also use a module-load.d snippet and order
systemd-modules-load.service before networkd to force the module
loading of tunneling modules.
This sholud fix the various build issues people have reported.
This allows us to run networkd mostly unpriviliged with the exception of
CAP_NET_* and CAP_SYS_MODULE. I'd really like to get rid of the latter
though...
The ptrace capability was only necessary to detect virtualizations
environments. Since we changed the logic to determine this to not
require priviliges, there's no need to carry the CAP_SYS_PTRACE
capability anymore.
Create initial stamp file with compiled-in time to prevent bootups
with clocks in the future from storing invalid timestamps.
At shutdown, only update the timestamp if we got an authoritative
time to store.
This is useful to make sure the system clock stays monotonic even on
systems that lack an RTC.
Also, why we are at it, also use the systemd release time for bumping
the clock, since it's a slightly less bad than starting with jan 1st,
1970.
This also moves timesyncd into the early bootphase, in order to make
sure this initial bump is guaranteed to have finished by the time we
start real daemons which might write to the file systemd and thus
shouldn't leave 1970's timestamps all over the place...
To make sure we don't delay boot on systems where (some) network links are managed by someone else
we don't block if something else has successfully brought up a link.
We will still block until all links we are aware of that are managed by networkd have been
configured, but if no such links exist, and someone else have configured a link sufficiently
that it has a carrier, it may be that the link is ready so we should no longer block.
Note that in all likelyhood the link is not ready (no addresses/routes configured),
so whatever network managment daemon configured it should provide a similar wait-online
service to block network-online.target until it is ready.
The aim is to block as long as we know networking is not fully configured, but no longer. This
will allow systemd-networkd-wait-online.service to be enabled on any system, even if we don't
know whether networkd is the main/only network manager.
Even in the case networking is fully configured by networkd, the default behavior may not be
sufficient: if two links need to be configured, but the first is fully configured before the
second one appears we will assume the network is up. To work around that, we allow specifying
specific devices to wait for before considering the network up.
This unit is enabled by default, just like systemd-networkd, but will only be pulled in if
anyone pulls in network-online.target.
Add a new config 'Activating' directive which denotes whether a busname
is actually registered on the bus. It defaults to 'yes'.
If set to 'no', the .busname unit only uploads policy, which will remain
active as long as the unit is running.
Add the first 3270 terminal device that is associated with the Linux preferred
console to the list of virtualization consoles. This is required to
automatically start a getty if the conmode=3270 kernel parameter is specified
for Linux on z/VM instances. Note that a queued upstream patch also enable
the 3270 terminal device if it is associated with the Linux preferred console.
How
To successfully start agetty on a 3270 terminal, a change in the agetty
parameter order is required. Previously, agetty would started like this:
/sbin/agetty --keep-baud 3270/tty1 115200,38400,9600 TERM
The agetty program interprets the "3270/tty1" as baud rate and fails to start
with the "bad speed: 3270/tty1" error message. Fixing this in agetty is more
complex rather than reordering the command line parameters like this:
/sbin/agetty --keep-baud 115200,38400,9600 3270/tty1 TERM
According to agetty sources and "agetty --help", agetty accepts the "tty",
"baudrate tty", and "tty baudrate" specifications.
P.S. The "tty: Set correct tty name in 'active' sysfs attribute" introduces
a change to display the terminal device which is associated with the
Linux preferred console. This change helps to let systemd handle this
particular case only. Without the changes of this commit, no additional
3270 terminal device can be managed by systemd.
https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/commit/?id=723abd87f6e536f1353c8f64f621520bc29523a3
The instance name is never escaped in the udev rule, but unescaped in the unit.
This results in the following error message on Asus boards:
Failed to get backlight or LED device 'backlight:eeepc/wmi': No such file or directory
That is, without --enable-kdbus and kdbus running.
With --enable-kdbus things are more complicated, because dbus might be
necessary, if kdbus is missing at runtime. If it is not necessary,
the socket will be started, which is not imporant, but not the service.
This should fix some race with terminating systemd --user, where the
system systemd instance might race against the user systemd instance
when sending SIGTERM.
We may not have a dbus daemon in the initrd (until we can rely on kdbus). In
this case, simply ignore any attempts at using the bus. There is only one user
for now, but surely more to come.
In order to work reliably in the real root without kdbus, but at the same time
don't delay boot when kdbus is in use, order ourselves after dbus.service.
They were supposed to make it easy to make the default.target a symlink
to these targets, but this was never advertised and we have a better
command for this now in "systemctl set-default". Since the install
section makes the output of "systemctl list-unit-files" confusing (since
it makes the units appear as "disabled"), let's drop the sections.
Various operations done by systemd-tmpfiles may only be safely done at
boot (e.g. removal of X lockfiles in /tmp, creation of /run/nologin).
Other operations may be done at any point in time (e.g. setting the
ownership on /{run,var}/log/journal). This distinction is largely
orthogonal to the type of operation.
A new switch --unsafe is added, and operations which should only be
executed during bootup are marked with an exclamation mark in the
configuration files. systemd-tmpfiles.service is modified to use this
switch, and guards are added so it is hard to re-start it by mistake.
If we install a new version of systemd, we actually want to enforce
some changes to tmpfiles configuration immediately. This should now be
possible to do safely, so distribution packages can be modified to
execute the "safe" subset at package installation time.
/run/nologin creation is split out into a separate service, to make it
easy to override.
https://bugzilla.redhat.com/show_bug.cgi?id=1043212https://bugzilla.redhat.com/show_bug.cgi?id=1045849
Condition for /lib (necessary for split /usr) was missing from the unit.
Some changes which were done in tmpfiles.d(5) were not carried over to
systemd-tmpfiles(1).
Also use markup where possible.
This has the effect that systemd-networkd won't run in containers
without network namespacing wher CAP_NET_ADMIN is (usually) not
available. It will still run in containers with network namespacing on
(where CAP_NET_ADMIN is usually avilable).
We might remove this condition check again if networkd provides services
to apps that also are useful in containers lacking network namespacing,
however, as long as it doesn't it should be handled like udevd and be
excluded in such containers.
Adds a new call sd_event_set_watchdog() that can be used to hook up the
event loop with the watchdog supervision logic of systemd. If enabled
and $WATCHDOG_USEC is set the event loop will ping the invoking systemd
daemon right after coming back from epoll_wait() but not more often than
$WATCHDOG_USEC/4. The epoll_wait() will sleep no longer than
$WATCHDOG_USEC/4*3, to make sure the service manager is called in time.
This means that setting WatchdogSec= in a .service file and calling
sd_event_set_watchdog() in your daemon is enough to hook it up with the
watchdog logic.
This daemon listens for and configures network devices tagged with
'systemd-networkd'. By default, no devices are tagged so this daemon
can safely run in parallel with existing network daemons/scripts.
Networks are configured in /etc/systemd/network/*.network. The first .network
file that matches a given link is applied. The matching logic is similar to
the one for .link files, but additionally supports matching on interface name.
The mid-term aim is to provide an alternative to ad-hoc scripts currently used
in initrd's and for wired setups that don't change much (e.g., as seen on
servers/and some embedded systems).
Currently, static addresses and a gateway can be configured.
Example .network file:
[Match]
Name=wlp2s0
[Network]
Description=My Network
Gateway=192.168.1.1
Address=192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64
