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.
