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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
DRM Master access requires CAP_SYS_ADMIN, yay! Add it to the capability
bounding set for systemd-logind. As CAP_SYS_ADMIN actually allows a huge
set of actions, this mostly renders the restriction-set useless. Anyway,
patches are already pending to reduce the restriction on the kernel side.
But these won't really make it into any stable-release so for now we're
stuck with CAP_SYS_ADMIN.
With the advent of systemd --user sessions, it's become very interesting to spawn X as a user unit, as well as accompanying processes that may have previously been in a .xinitrc/.xsession, or even just to replace a collection of XDG/GDM/KDM/etc session files with independent systemd --user units. The simplest case here would be to login on a tty, with the traditional /usr/sbin/login "login manager".
However, systemd --user (spawned by user@.service) is at the top level of the slice for the user, and does not inherit any environment variables from the login process. Given the number of common applications which rely on SHELL being set in the environment, it seems like the cleanest way to provide this variable is to set it to %s in the user@.service.
Ideally in the long-term, applications which rely on SHELL being set should be fixed to just grab it from getpwnam() or similar, but until that becomes more common, I propose this simple change to make user sessions a little bit nicer out of the box.
systemd-logind will start user@.service. user@.service unit uses
PAM with service name 'systemd-user' to perform account and session
managment tasks. Previously, the name was 'systemd-shared', it is
now changed to 'systemd-user'.
Most PAM installations use one common setup for different callers.
Based on a quick poll, distributions fall into two camps: those that
have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia,
Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE).
Distributions that have system-auth have just one configuration file
that contains auth, password, account, and session blocks, and
distributions that have common-auth also have common-session,
common-password, and common-account. It is thus impossible to use one
configuration file which would work for everybody. systemd-user now
refers to system-auth, because it seems that the approach with one
file is more popular and also easier, so let's follow that.
This means we can use default dependencies on mount units without having to get them automatically
ordered before the filesystem targets.
Reported-by: Thomas Baechler <thomas@archlinux.org>
Fixes errors seen when booting VMs on QEMU like
systemd[1]: kmod-static-nodes.service: main process exited, code=exited, status=203/EXEC
systemd[1]: Failed to start Create list of required static device nodes for the current kernel.
systemd[1]: Unit kmod-static-nodes.service entered failed state.
Make sure that mknod capability is available
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Without this, fsck would be re-run if any other service which pulls
in a target requiring one of the mounts was started after fsck was done
but before the initial transaction was done.
https://bugs.freedesktop.org/show_bug.cgi?id=66784
As many laptops don't save/restore screen brightness across reboots,
let's do this in systemd with a minimal tool, that restores the
brightness as early as possible, and saves it as late as possible. This
will cover consoles and graphical logins, but graphical desktops should
do their own per-user stuff probably.
This only touches firmware brightness controls for now.
Without this, tmpfiles-setpu-dev would be re-run if any other service,
which pulls in basic.target, was started after setup-dev was finished
and before basic.target was active.
As of kmod v14, it is possible to export the static node information from
/lib/modules/`uname -r`/modules.devname in tmpfiles.d(5) format.
Use this functionality to let systemd-tmpfilesd create the static device nodes
at boot, and drop the functionality from systemd-udevd.
As an effect of this we can move from systemd-udevd to systemd-tmpfiles-setup-dev:
* the conditional CAP_MKNOD (replaced by checking if /sys is mounted rw)
* ordering before local-fs-pre.target (see 89d09e1b5c)
Embedded folks don't need the machine registration stuff, hence it's
nice to make this optional. Also, I'd expect that machinectl will grow
additional commands quickly, for example to join existing containers and
suchlike, hence it's better keeping that separate from loginctl.
In order to prepare things for the single-writer cgroup scheme, let's
make logind use systemd's own primitives for cgroup management.
Every login user now gets his own private slice unit, in which his sessions
live in a scope unit each. Also, add user@$UID.service to the same
slice, and implicitly start it on first login.
Replace the very generic cgroup hookup with a much simpler one. With
this change only the high-level cgroup settings remain, the ability to
set arbitrary cgroup attributes is removed, so is support for adding
units to arbitrary cgroup controllers or setting arbitrary paths for
them (especially paths that are different for the various controllers).
This also introduces a new -.slice root slice, that is the parent of
system.slice and friends. This enables easy admin configuration of
root-level cgrouo properties.
This replaces DeviceDeny= by DevicePolicy=, and implicitly adds in
/dev/null, /dev/zero and friends if DeviceAllow= is used (unless this is
turned off by DevicePolicy=).
- This changes all logind cgroup objects to use slice objects rather
than fixed croup locations.
- logind can now collect minimal information about running
VMs/containers. As fixed cgroup locations can no longer be used we
need an entity that keeps track of machine cgroups in whatever slice
they might be located. Since logind already keeps track of users,
sessions and seats this is a trivial addition.
- nspawn will now register with logind and pass various bits of metadata
along. A new option "--slice=" has been added to place the container
in a specific slice.
- loginctl gained commands to list, introspect and terminate machines.
- user.slice and machine.slice will now be pulled in by logind.service,
since only logind.service requires this slice.
* baud rate is optional and unnecessary for virtual terminals
* term type is optional (default is 'linux' for virtual terminals
and 'vt102' for serial lines)
* long options are more user-friendly
... all this is supported since util-linux v2.20 (Aug 2011).
That way ordering it with MountsRequiredFor= works properly, as this no
longer results in mount units start requests to be added to the shutdown
transaction that conflict with stop requests for the same unit.
Since v183, the contents of /usr/lib/udev/devices is no longer copied to /dev
on boot, rather systemd-tmpfiles should be used instead. However, as
systemd-tmpfiles --create is only ran long after udevd has been started, it is
no longer possible to use udev rules to assign permissions to the static nodes.
This calls systemd-tmpfiles --create early, before udev is started, and
restricts the call to /dev, which is known to be mounted already.
In the future, this could also take over the creation of static device nodes
from systemd-udevd.
This patch changes local-fs.target and systemd-fsck to not use
"isolate" when going into emergency.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=810722
The motivation is, that when something wents wrong, we should
keep everything as it is, to let the user fix the problem. When
isolating we stop a lot of services and therefore change the
system heavily so that it gets harder for the user to fix.
An example is a crypted partition. When the fsck in a crypted
partition fails, it previously used "emergency/start/isolate"
which stops cryptsetup. Therefore if the user tries to fsck
e.g. /dev/mapper/luks-356c20ae-c7a2-4f1c-ae1d-1d290a91b691
as printed by the failing fsck, then it will not find this
device (because it got closed).
So please apply this patch to let the user see the failing
situation.
Thanks!
[zj: removed dead isolate param from start_target().]
https://bugs.freedesktop.org/show_bug.cgi?id=49463https://bugzilla.redhat.com/show_bug.cgi?id=810722
As passive units only are useful for ordering things within the initial
transaction there is no point in ever activating them manually, hence
refuse it.
Units such as nss-lookup.target, nss-user-lookup.target,
remote-fs-pre.target, local-fs-pre.target, time-sync.target,
rpcbind.target are to be pulled in by the implementing services, and
that's there only purpose. They should not have any 'active component'
otherwise, so let's drop all further deps from these units.
This introduces remote-fs-setup.target independently of
remote-fs-pre.target. The former is only for pulling things in, the
latter only for ordering.
The new semantics:
remote-fs-setup.target: is pulled in automatically by all remote mounts.
Shall be used to pull in other units that want to run when at least one
remote mount is set up. Is not ordered against the actual mount units,
in order to allow activation of its dependencies even 'a posteriori',
i.e. when a mount is established outside of systemd and is only picked
up by it.
remote-fs-pre.target: needs to be pulled in automatically by the
implementing service, is otherwise not part of the initial transaction.
This is ordered before all remote mount units.
A service that wants to be pulled in and run before all remote mounts
should hence have:
a) WantedBy=remote-fs-setup.target -- so that it is pulled in
b) Wants=remote-fs-pre.target + Before=remote-fs-pre.target -- so that
it is ordered before the mount point, normally.
This reverts commit 6bde0b3220.
We should not pull in remote-fs-pre.target unconditionally. It's
supposed to be pulled in by the implementors of it, rather then its
users.
Not that it would matter much, but let's make things a bit more
systematic: early boot services shall order themselves before
sysinit.target, and nothing else.
static nodes (like /dev/loop-control) are created when systemd-udevd
is started and needed to mount loopback devices. Therefore,
local-fs-pre.target should be only started after systemd-udevd is
started.
While most folks will be using the derivative from user-session-units,
I'm updating this one to reflect some of the fixes and things to note
about user sessions:
- cgroup should be set with "%u" - username instead of %I
- set dbus path with %U explicitly too
- hint to folks that wish to use MEM_CG features in user sessions
- allow unit to be enabled for instances with systemctl enable
This reverts commit faeffa73a8.
There isn't really much point in dropping the Conflicts= since shutting
down this service is basically free as it doesn't have anything running.
Also, the patch was incomplete, because shutdown.target was still listed
in Before=.
First, rename root-fs.target to initrd-root-fs.target to clarify its usage.
Mount units with "x-initrd-rootfs.mount" are now ordered before
initrd-root-fs.target. As we sometimes construct /sysroot mounts in
/etc/fstab in the initrd, we want these to be mounted before the
initrd-root-fs.target is active.
initrd.target can be the default target in the initrd.
(normal startup)
:
:
v
basic.target
|
______________________/|
/ |
| sysroot.mount
| |
| v
| initrd-root-fs.target
| |
| v
| initrd-parse-etc.service
(custom initrd services) |
| v
| (sysroot-usr.mount and
| various mounts marked
| with fstab option
| x-initrd.mount)
| |
| v
| initrd-fs.target
| |
\______________________ |
\|
v
initrd.target
|
v
initrd-cleanup.service
isolates to
initrd-switch-root.target
|
v
______________________/|
/ |
| initrd-udevadm-cleanup-db.service
| |
(custom initrd services) |
| |
\______________________ |
\|
v
initrd-switch-root.target
|
v
initrd-switch-root.service
|
v
switch-root
Instead of using local-fs*.target in the initrd, use root-fs.target for
sysroot.mount and initrd-fs.target for /sysroot/usr and friends.
Using local-fs.target would mean to carry over the activated
local-fs.target to the isolated initrd-switch-root.target and thus in
the real root. Having local-fs.target already active after
deserialization causes ordering problems with the real root services and
targets.
We better isolate to targets for initrd-switch-root.target, which are
only available in the initrd.
This pulls in remote-fs-pre.target if remote-fs.target is needed.
Previously remote-fs-pre.target was not active, if no remote fs was
mounted from /etc/fstab. So, every manual remote fs mount was ordered
against the inactive remote-fs-pre.target and umount.target.
Because remote-fs-pre.target was not active, the remote fs was umounted
at umount.target time, which was too late (network already down).
Now remote-fs-pre.target is active, even if no remote fs is mounted.
On shutdown it is deactivated in the correct order and all manual remote
fs mounts also.
This will:
* mount all configured filesystems (typically the rootfs on /sysroot)
* reload the configuration to pick up anything from the mounted fs (typically
/sysroot/etc/fstab)
* mount any newly configured filesystems (typically /usr on /sysroot/usr, if
applicable)
* shut-down and clean-up any daemons running in the initramfs (typically udevd)
* switch-root to /sysroot and start the real init
For an example of what files should be included in an initramfs based on this
see
<https://mailman.archlinux.org/pipermail/arch-projects/2013-February/003628.html>.
Cc: Harald Hoyer <harald.hoyer@gmail.com>
Cc: Dave Reisner <d@falconindy.com>
Sometimes it is useful to look at them, and they don't take
up any significant amount of space. Keeping them also avoids
the message about files being removed at the end of make
run.
We no longer allow early-boot init scripts, however in late boot the
syslog socket and local mounts are established anyway, so let's simplify
our dep graph a bit.
If $syslog doesn't resolve to syslog.target anymore there's no reason to
keep syslog.target around anymore. Let's remove it.
Note that many 3rd party service unit files order themselves after
syslog.target. These will be dangling dependencies now, which should be
unproblematic, however.
Systemd should not introduce any new facilities. Distributions which still
need to support their non-standard/legacy facilities should add them as
patches to their packaging.
The following facilities are no longer recognized:
$x-display-manager
$mail-transfer-agent
$mail-transport-agent
$mail-transfer-agent
$smtp
$null
This target is no longer available:
mail-transfer-agent.target
This also drops automatic selection of the rc local scripts
based on the local distro. Distributions now should specify the paths
of the rc-local and halt-local scripts on the configure command line.
This was premarily intended to support the LSB facility $httpd which is
only known by Fedora, and a bad idea since it lacks any real-life
usecase.
Similar, drop support for some other old Fedora-specific facilities.
Also, document the rules for introduction of new facilities, to clarify
the situation for the future.
Do not suggest to the user that commands can be issued before
logging in.
sulogin prints it own message, which mentions ^D, so there's no need
to repeat it here.
This minimal HTTP server can serve journal data via HTTP. Its primary
purpose is synchronization of journal data across the network. It serves
journal data in three formats:
text/plain: the text format known from /var/log/messages
application/json: the journal entries formatted as JSON
application/vnd.fdo.journal: the binary export format of the journal
The HTTP server also serves a small HTML5 app that makes use of the JSON
serialization to present the journal data to the user.
Examples:
This downloads the journal in text format:
# systemctl start systemd-journal-gatewayd.service
# wget http://localhost:19531/entries
Same for JSON:
# curl -H"Accept: application/json" http://localhost:19531/entries
Access via web browser:
$ firefox http://localhost:19531/
It is no longer possible to manually enable systemd-udev-settle.service,
so its only use is by legacy services explicitly pulling it in. It makes
sense for these services to also explicitly order themselves after
udev-settle.service, which makes After=basic.target redundant.
This should reduce the negative effect on boot-time of having to enable
legacy services such as lvm.service.
It's time to get rid of prefdm. Distributions which still want to use
this should maintain this downstream, but it's probably better to just
provide proper units for the various display managers, like Fedora is
doing this, for example:
https://fedoraproject.org/wiki/Features/DisplayManagerRework
