And remove machine-id-commit as separate binary.
There's really no point in keeping this separate, as the sources are
pretty much identical, and have pretty identical interfaces. Let's unify
this in one binary.
Given that machine-id-commit was a private binary of systemd (shipped in
/usr/lib/) removing the tool is not an API break.
While we are at it, improve the documentation of the command substantially.
Apparently, disk IO issues are more frequent than we hope, and 1min
waiting for disk IO happens, so let's increase the watchdog timeout a
bit, for all our services.
See #1353 for an example where this triggers.
When a systemd service running in a container exits with a non-zero
code, it can be useful to terminate the container immediately and get
the exit code back to the host, when systemd-nspawn returns. This was
not possible to do. This patch adds the following to make it possible:
- Add a read-only "ExitCode" property on PID 1's "Manager" bus object.
By default, it is 0 so the behaviour stays the same as previously.
- Add a method "SetExitCode" on the same object. The method fails when
called on baremetal: it is only allowed in containers or in user
session.
- Add support in systemctl to call "systemctl exit 42". It reuses the
existing code for user session.
- Add exit.target and systemd-exit.service to the system instance.
- Change main() to actually call systemd-shutdown to exit() with the
correct value.
- Add verb 'exit' in systemd-shutdown with parameter --exit-code
- Update systemctl manpage.
I used the following to test it:
| $ sudo rkt --debug --insecure-skip-verify run \
| --mds-register=false --local docker://busybox \
| --exec=/bin/chroot -- /proc/1/root \
| systemctl --force exit 42
| ...
| Container rkt-895a0cba-5c66-4fa5-831c-e3f8ddc5810d failed with error code 42.
| $ echo $?
| 42
Fixes https://github.com/systemd/systemd/issues/1290
The bus-proxy manages the kdbus connections of all users on the system
(regarding the system bus), hence, it needs an elevated NOFILE.
Otherwise, a single user can trigger ENFILE by opening NOFILE connections
to the bus-proxy.
Note that the bus-proxy still does per-user accounting, indirectly via
the proxy/fake API of kdbus. Hence, the effective per-user limit is not
raised by this. However, we now prevent one user from consuming the whole
FD limit of the shared proxy.
Also note that there is no *perfect* way to set this. The proxy is a
shared object, so it needs a larger NOFILE limit than the highest limit
of all users. This limit can be changed dynamically, though. Hence, we
cannot protect against it. However, a raised NOFILE limit is a privilege,
so we just treat it as such and basically allow these privileged users to
be able to consume more resources than normal users (and, maybe, cause
some limits to be exceeded by this).
Right now, kdbus hard-codes 1024 max connections per user on each bus.
However, we *must not* rely on this. This limits could be easily dropped
entirely, as the NOFILE limit is a suitable limit on its on.
Make sure we support ExecReload= for bus-proxyd to reload configuration
during runtime. This is *really* handy when hacking on kdbus.
Package-managers are still recommended to run
`busctl --address=unix:path=` directly.
This drops the libsystemd-terminal and systemd-consoled code for various
reasons:
* It's been sitting there unfinished for over a year now and won't get
finished any time soon.
* Since its initial creation, several parts need significant rework: The
input handling should be replaced with the now commonly used libinput,
the drm accessors should coordinate the handling of mode-object
hotplugging (including split connectors) with other DRM users, and the
internal library users should be converted to sd-device and friends.
* There is still significant kernel work required before sd-console is
really useful. This includes, but is not limited to, simpledrm and
drmlog.
* The authority daemon is needed before all this code can be used for
real. And this will definitely take a lot more time to get done as
no-one else is currently working on this, but me.
* kdbus maintenance has taken up way more time than I thought and it has
much higher priority. I don't see me spending much time on the
terminal code in the near future.
If anyone intends to hack on this, please feel free to contact me. I'll
gladly help you out with any issues. Once kdbus and authorityd are
finished (whenever that will be..) I'll definitely pick this up again. But
until then, lets reduce compile times and maintenance efforts on this code
and drop it for now.
Otherwise copying full directory trees between container and host won't
work, as we cannot access some fiels and cannot adjust the ownership
properly on the destination.
Of course, adding these many caps to the daemon kinda defeats the
purpose of the caps lock-down... but well...
Fixes#433
Merely calling "plymouth quit" isn't sufficient, as plymouth needs some time to
shut down. This needs plymouth --wait (which is a no-op when it's not running).
Fixes invisible emergency shell with plymouth running endlessly.
https://launchpad.net/bugs/1471258
./configure --enable/disable-kdbus can be used to set the default
behavior regarding kdbus.
If no kdbus kernel support is available, dbus-dameon will be used.
With --enable-kdbus, the kernel command line option "kdbus=0" can
be used to disable kdbus.
With --disable-kdbus, the kernel command line option "kdbus=1" is
required to enable kdbus support.
The daemon requires the busname unit to operate (on kdbus systems),
since it contains the policy that allows it to acquire its service
name.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=90287
This way we know that any bridges and other user-created network devices
are in place, and can be properly added to the container.
In the long run this should be dropped, and replaced by direct calls
inside nspawn that cause the devices to be created when necessary.
For a longer discussion see this:
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030175.html
This introduces /run/systemd/fsck.progress as a simply
AF_UNIX/SOCK_STREAM socket. If it exists and is connectable we'll
connect fsck's -c switch with it. If external programs want to get
progress data they should hence listen on this socket and will get
all they need via that socket. To get information about the connecting
fsck client they should use SO_PEERCRED.
Unless /run/systemd/fsck.progress is around and connectable this change
reverts back to v219 behaviour where we'd forward fsck output to
/dev/console on our own.
Even trivial service occasionally get stuck, for example when
there's a problem with the journal. There's nothing more annoying
that looking at the cylon eye for a job with an infinite timeout.
Use standard 90s for jobs that do some work, and 30s for those which
should be almost instantenous.
Not that all functionality has been ported over to logind, the old
implementation can be removed. There goes one of the oldest parts of
the systemd code base.
Fedora's filesystem package ships /usr/bin (and other directories) which are
not writable by its owner. machinectl pull-dkr (and possibly others) are not
able to extract those:
14182 mkdirat(3, "usr", 0700) = 0
14182 mkdirat(3, "usr/bin", 0500) = 0
14182 openat(3, "usr/bin/[", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0700) = -1 EACCES (Permission denied)
...
We support /var, /tmp and /var/tmp on NFS. NFS shares however are by
default ordered only before remote-fs.target which is a late-boot
service. /var, /tmp, /var/tmp need to be around earlier though, hence
explicitly order them before basic.target.
Note that this change simply makes explicit what was implicit before,
since many early-boot services pulled in parts of /var anyway early.
Create minimal image which runs systemd
FROM rhel7.1
RUN yum install -y /usr/bin/ps
ENV container docker
CMD [ "/usr/sbin/init" ]
When you run the container without -t, the process
/sbin/agetty --noclear --keep-baud console 115200 38400 9600
is not happy and checking the journal in the container, there is a stream of
Mar 13 04:50:15 11bf07f59fff agetty[66]: /dev/console: No such file or directory
Mar 13 04:50:25 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart.
Mar 13 04:50:25 11bf07f59fff systemd[1]: Stopping Console Getty...
Mar 13 04:50:25 11bf07f59fff systemd[1]: Starting Console Getty...
Mar 13 04:50:25 11bf07f59fff systemd[1]: Started Console Getty.
Mar 13 04:50:25 11bf07f59fff agetty[67]: /dev/console: No such file or directory
Mar 13 04:50:35 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart.
Mar 13 04:50:35 11bf07f59fff systemd[1]: Stopping Console Getty...
Mar 13 04:50:35 11bf07f59fff systemd[1]: Starting Console Getty...
Mar 13 04:50:35 11bf07f59fff systemd[1]: Started Console Getty.
Mar 13 04:50:35 11bf07f59fff agetty[74]: /dev/console: No such file or directory
Mar 13 04:50:45 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart.
Mar 13 04:50:45 11bf07f59fff systemd[1]: Stopping Console Getty...
Mar 13 04:50:45 11bf07f59fff systemd[1]: Starting Console Getty...
On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau <michael.marineau@coreos.com> wrote:
> Currently systemd-timesyncd.service includes
> ConditionVirtualization=no, disabling it in both containers and
> virtual machines. Each VM platform tends to deal with or ignore the
> time problem in their own special ways, KVM/QEMU has the kernel time
> source kvm-clock, Xen has had different schemes over the years, VMware
> expects a userspace daemon sync the clock, and other platforms are
> content to drift with the wind as far as I can tell.
>
> I don't know of a robust way to know if a platform needs a little
> extra help from userspace to keep the clock sane or not but it seems
> generally safer to try than to risk drifting. Does anyone know of a
> reason to leave timesyncd off by default? Otherwise switching to
> ConditionVirtualization=!container should be reasonable.
When manipulating container and VM images we need efficient and atomic
directory snapshots and file copies, as well as disk quota. btrfs
provides this, legacy file systems do not. Hence, implicitly create a
loopback file system in /var/lib/machines.raw and mount it to
/var/lib/machines, if that directory is not on btrfs anyway.
This is done implicitly and transparently the first time the user
invokes "machinectl import-xyz".
This allows us to take benefit of btrfs features for container
management without actually having the rest of the system use btrfs.
The loopback is sized 500M initially. Patches to grow it dynamically are
to follow.
We will be woken up on rtnl or dbus activity, so let's just quit if some time has passed and that is the only thing that can happen.
Note that we will always stay around if we expect network activity (e.g. DHCP is enabled), as we are not restarted on that.
Only the very basics, more to come.
For now:
$ busctl tree org.freedesktop.network1
└─/org/freedesktop/network1
└─/org/freedesktop/network1/link
├─/org/freedesktop/network1/link/1
├─/org/freedesktop/network1/link/2
├─/org/freedesktop/network1/link/3
├─/org/freedesktop/network1/link/4
├─/org/freedesktop/network1/link/5
├─/org/freedesktop/network1/link/6
├─/org/freedesktop/network1/link/7
├─/org/freedesktop/network1/link/8
└─/org/freedesktop/network1/link/9
$ busctl introspect org.freedesktop.network1 /org/freedesktop/network1
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.network1.Manager interface - - -
.OperationalState property s "carrier" emits-change
$ busctl introspect org.freedesktop.network1 /org/freedesktop/network1/link/1
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.network1.Link interface - - -
.AdministrativeState property s "unmanaged" emits-change
.OperationalState property s "carrier" emits-change
Services which are not crucial to system bootup, and have Type=oneshot
can effectively "hang" the system if they fail to complete for whatever
reason. To allow the boot to continue, kill them after a timeout.
In case of systemd-journal-flush the flush will continue in the background,
and in the other two cases the job will be aborted, but this should not
result in any permanent problem.
The old "systemd-import" binary is now an internal tool. We still use it
as asynchronous backend for systemd-importd. Since the import tool might
require some IO and CPU resources (due to qcow2 explosion, and
decompression), and because we might want to run it with more minimal
priviliges we still keep it around as the worker binary to execute as
child process of importd.
machinectl now has verbs for pulling down images, cancelling them and
listing them.
Instead of using Accept=true and running one proxy for each connection, we
now run one proxy-daemon with a thread per connection. This will enable us
to share resources like policies in the future.
When there are a lot of split out journal files, we might run out of fds
quicker then we want. Hence: bump RLIMIT_NOFILE to 16K if possible.
Do these even for journalctl. On Fedora the soft RLIMIT_NOFILE is at 1K,
the hard at 4K by default for normal user processes, this code hence
bumps this up for users to 4K.
https://bugzilla.redhat.com/show_bug.cgi?id=1179980
Making use of the fd storage capability of the previous commit, allow
restarting journald by serilizing stream state to /run, and pushing open
fds to PID 1.
- Unescape instance name so that we can take almost anything as instance
name.
- Introduce "machines.target" which consists of all enabled nspawns and
can be used to start/stop them altogether
- Look for container directory using -M instead of harcoding the path in
/var/lib/container
This adds a new bus call to machined that enumerates /var/lib/container
and returns all trees stored in it, distuingishing three types:
- GPT disk images, which are files suffixed with ".gpt"
- directory trees
- btrfs subvolumes
This pulls out the hwdb managment from udevadm into an independent tool.
The old code is left in place for backwards compatibility, and easy of
testing, but all documentation is dropped to encourage use of the new
tool instead.
Otherwise this actually remains in the generated unit in /usr/lib.
If you want to keep it commented out, a m4-compatible way would be:
m4_ifdef(`HAVE_SMACK',
dnl Capabilities=cap_mac_admin=i
dnl SecureBits=keep-caps
)
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
The unit file only active the machine-id-commit helper if /etc is mounted
writable and /etc/machine-id is an independant mount point (should be a tmpfs).
--link-journal={host,guest} fail if the host does not have persistent
journalling enabled and /var/log/journal/ does not exist. Even worse, as there
is no stdout/err any more, there is no error message to point that out.
Introduce two new modes "try-host" and "try-guest" which don't fail in this
case, and instead just silently skip the guest journal setup.
Change -j to mean "try-guest" instead of "guest", and fix the wrong --help
output for it (it said "host" before).
Change systemd-nspawn@.service.in to use "try-guest" so that this unit works
with both persistent and non-persistent journals on the host without failing.
https://bugs.debian.org/770275
This reverts commit a4962513c5.
logind.service is a D-Bus service, hence we should use the dbus name as
indication that we are up. Type=dbus is implied if BusName= is
specified, as it is in this case.
This removes a warning that is printed because a BusName= is specified
for a Type=notify unit.
The code already calls sd_notify("READY=1"), so we may as well take
advantage of the startup behavior in the unit. The same was done for
the journal in a87a38c20.
kdbus has seen a larger update than expected lately, most notably with
kdbusfs, a file system to expose the kdbus control files:
* Each time a file system of this type is mounted, a new kdbus
domain is created.
* The layout inside each mount point is the same as before, except
that domains are not hierarchically nested anymore.
* Domains are therefore also unnamed now.
* Unmounting a kdbusfs will automatically also detroy the
associated domain.
* Hence, the action of creating a kdbus domain is now as
privileged as mounting a filesystem.
* This way, we can get around creating dev nodes for everything,
which is last but not least something that is not limited by
20-bit minor numbers.
The kdbus specific bits in nspawn have all been dropped now, as nspawn
can rely on the container OS to set up its own kdbus domain, simply by
mounting a new instance.
A new set of mounts has been added to mount things *after* the kernel
modules have been loaded. For now, only kdbus is in this set, which is
invoked with mount_setup_late().
It seems that there actually aren't any long running tasks which are
performed at shutdown. If it turns out that there actually are, this
should be revisited.
This reverts most of commit 038193efa6.
For boot, we might kill fsck in the middle, with likely catastrophic
consequences.
On shutdown there might be other jobs, like downloading of updates for
installation, and other custom jobs. It seems better to schedule an
individual timeout on each one separately, when it is known what
timeout is useful.
Disable the timeouts for now, until we have a clearer picture of how
we can deal with long-running jobs.
For priviliged units this resource control property ensures that the
processes have all controllers systemd manages enabled.
For unpriviliged services (those with User= set) this ensures that
access rights to the service cgroup is granted to the user in question,
to create further subgroups. Note that this only applies to the
name=systemd hierarchy though, as access to other controllers is not
safe for unpriviliged processes.
Delegate=yes should be set for container scopes where a systemd instance
inside the container shall manage the hierarchies below its own cgroup
and have access to all controllers.
Delegate=yes should also be set for user@.service, so that systemd
--user can run, controlling its own cgroup tree.
This commit changes machined, systemd-nspawn@.service and user@.service
to set this boolean, in order to ensure that container management will
just work, and the user systemd instance can run fine.
Otherwise we could attempt to flush the journal while /var/log/ was
still ro, and silently skip journal flushing.
The way that errors in flushing are handled should still be changed to
be more transparent and robust.
Since commit 19f8d03783 'timer: order OnCalendar units after
timer-sync.target if DefaultDependencies=no' timers might get a
dependency on time-sync.target, which does not really belong in early
boot. If ntp is enabled, time-sync.target might be delayed until a
network connection is established.
It turns out that majority of timer units found in the wild do not
need to be started in early boot. Out of the timer units available in
Fedora 21, only systemd-readahead-done.timer and mdadm-last-resort@.timer
should be started early, but they both have DefaultDependencies=no,
so are not part of timers.target anyway. All the rest look like they
will be fine with being started a bit later (and the majority even
much later, since they run daily or weekly).
Let timers.target be pulled in by basic.target, but without the
temporal dependency. This means timer units are started on a "best
effort" schedule.
https://bugzilla.redhat.com/show_bug.cgi?id=1158206
In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.
So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.
Add a new --usr flag to "udevadm hwdb --update" which puts the database
into UDEVLIBEXECDIR.
Adjust systemd-udev-hwdb-update.service to not generate the file in /etc if we
already have it in /usr.
Using the new JobTimeoutAction= setting make sure we power off the
machine after basic.target is queued for longer than 15min but not
executed. Similar, if poweroff.target is queued for longer than 30min
but does not complete, forcibly turn off the system. Similar, if
reboot.target is queued for longer than 30min but does not complete,
forcibly reboot the system.
This new command will ask the journal daemon to flush all log data
stored in /run to /var, and wait for it to complete. This is useful, so
that in case of Storage=persistent we can order systemd-tmpfiles-setup
afterwards, to ensure any possibly newly created directory in /var/log
gets proper access mode and owners.
systemd-journald check the cgroup id to support rate limit option for
every messages. so journald should be available to access cgroup node in
each process send messages to journald.
In system using SMACK, cgroup node in proc is assigned execute label
as each process's execute label.
so if journald don't want to denied for every process, journald
should have all of access rule for all process's label.
It's too heavy. so we could give special smack label for journald te get
all accesses's permission.
'^' label.
When assign '^' execute smack label to systemd-journald,
systemd-journald need to add CAP_MAC_OVERRIDE capability to get that smack privilege.
so I want to notice this information and set default capability to
journald whether system use SMACK or not.
because that capability affect to only smack enabled kernel
They were left from an early review iteration, when hibernate-resume
functionality was intended to work also outside of initramfs.
Now this is not the case, and these dependencies became redundant
as systemd-fsck-root.service can never be part of initramfs, and
systemd-remount-fs.service makes little sense in it.
This way we are sure that /dev/net/tun has been given the right permissions before we try to connect to it.
Ideally, we should create tun/tap devices over netlink, and then this whole issue would go away.
It seems the return code of systemctl daemon-reload can be !=0 in some
circumstances, which causes a failure of the unit and breaks booting in
the initrd.
This can be used to initiate a resume from hibernation by path to a swap
device containing the hibernation image.
The respective templated unit is also added. It is instantiated using
path to the desired resume device.
With this change, it becomes possible to order a unit to activate before any
modifications to the file systems. This is especially useful for supporting
resume from hibernation.
For pluggable ttys such as USB serial devices, the getty is restarted
and exits in a loop until the remove event reaches systemd. Under
certain circumstances the restart loop can overload the system in a
way that prevents the remove event from reaching systemd for a long
time (e.g. at least several minutes on a small embedded system).
Use the default RestartSec to prevent the restart loop from
overloading the system. Serial gettys are interactive units, so
waiting an extra 100ms really doesn't make a difference anyways
compared to the time it takes the user to log in.
Currently after exiting rescue shell we isolate default target. User
might want to isolate to some other target than default one. However
issuing systemctl isolate command to desired target would bring system
to default target as a consequence of running ExecStopPost action.
Having common ancestor for rescue shell and possible followup systemctl
default command should fix this. If user exits rescue shell we will
proceed with isolating default target, otherwise, on manual isolate,
parent shell process is terminated and we don't isolate default target,
but target chosen by user.
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
As Zbigniew pointed out a new ConditionFirstBoot= appears like the nicer
way to hook in systemd-firstboot.service on first boots (those with /etc
unpopulated), so let's do this, and get rid of the generator again.
A new tool "systemd-firstboot" can be used either interactively on boot,
where it will query basic locale, timezone, hostname, root password
information and set it. Or it can be used non-interactively from the
command line when prepareing disk images for booting. When used
non-inertactively the tool can either copy settings from the host, or
take settings on the command line.
$ systemd-firstboot --root=/path/to/my/new/root --copy-locale --copy-root-password --hostname=waldi
The tool will be automatically invoked (interactively) now on first boot
if /etc is found unpopulated.
This also creates the infrastructure for generators to be notified via
an environment variable whether they are running on the first boot, or
not.
We really don't want these in containers as they provide a too lowlevel
look on the system.
Conditionalize them with CAP_SYS_RAWIO since that's required to access
/proc/kcore, /dev/kmem and similar, which feel similar in style. Also,
npsawn containers lack that capability.
npsawn containers generally have CAP_MKNOD, since this is required
to make PrviateDevices= work. Thus, it's not useful anymore to
conditionalize the kmod static device node units.
Use CAP_SYS_MODULES instead which is not available for nspawn
containers. However, the static device node logic is only done for being
able to autoload modules with it, and if we can't do that there's no
point in doing it.
Reported by Gerardo Exequiel Pozzi:
Looks like [commit a4a878d0] also changes a unrelated file
(units/local-fs.target) [partially]reverting the commit
40f862e3 (filesystem targets: disable default dependencies)
The side effect, at least in my case is that the "nofail" option in both
"crypttab" and "fstab" has partial effect does the default timeout
instead of continue normal boot without timeout.
In a normal running system, non-passive targets and units used during
early bootup are always started. So refusing "manual start" for them
doesn't make any difference, because a "start" command doesn't cause
any action.
In early boot however, the administrator might want to start on
of those targets or services by hand. We shouldn't interfere with that.
Note: in case of systemd-tmpfiles-setup.service, really running the
unit after system is up would break the system. So e.g. restarting
should not be allowed. The unit has "RefuseManualStop=yes", which
prevents restart too.
networkd-wait-online should never exist in the default transaction,
unless explicitly enable or pulled in via things like NFS. However, just
enabling networkd shouldn't enable networkd-wait-online, since it's
common to use the former without the latter.
The DefaultInstance= name is used when enabling template units when only
specifying the template name, but no instance.
Add DefaultInstance=tty1 to getty@.service, so that when the template
itself is enabled an instance for tty1 is created.
This is useful so that we "systemctl preset-all" can work properly,
because we can operate on getty@.service after finding it, and the right
instance is created.
The only update service we really need to guard like this is
systemd-tmpfiles-setup.service since if invoked manually might create
/var/run/nologin and thus blocking the user from login. The other
services are pretty much idempotent and don't suffer by this problem,
hence let's simplify them.
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
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.
