Readahead has all sorts of bad side effects depending on your
storage media. On rotating disks, it may be degrading startup
performance if enough requests are queued spanning linearly
over all blocks early at boot, and mount, blkid and friends
want to insert reads to the start of these block devices after.
The end result is that on spinning disks with ext3/4 that udev
and mounts take a very long time, and nothing really happens until
readahead is completely finished.
This has the net effect that the CPU is almost entirely idle
for the entire period that readahead is working. We could have
finished starting up quite a lot of services in this time if
we were smarter at how we do readahead.
This patch sorts all requests into 2 second "chunks" and sub-sorts
each chunk by block. This adds a single cross-drive seek per "chunk"
but has the benefit that we will have a lot of the blocks we need
early on in the boot sequence loaded into memory faster.
For a comparison of how before/after bootcharts look (ext4 on a
mobile 5400rpm 250GB drive) please look at:
http://foo-projects.org/~sofar/blocked-tests/
There are bootcharts in the "before" and "after" folders where you
should be able to see that many low-level services finish 5-7
seconds earlier with the patch applied (after).
x-initrd.mount now has different meanings, if fstab-generator is called
in the initramfs.
initrd:/etc/fstab and x-initrd.mount defines mounts for the
initrd-root-fs.target
initrd:/sysroot/etc/fstab and x-initrd.mount defines mounts for the
initrd-fs.target
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 changes the fstab mount option x-initrd-rootfs.mount to
x-initrd.rootfs, in order to only use a single namespace "x-initrd." for
all mount options of the initrd.
Add option to force journal sync with fsync. Default timeout is 5min.
Interval configured via SyncIntervalSec option at journal.conf. Synced
journal files will be marked as OFFLINE.
Manual sync can be performed via sending SIGUSR1.
Let's say you have two initscripts, A and B:
A contains in its LSB header:
Required-Start: C
and B contains in its LSB header:
Provides: C
When systemd is parsing /etc/rc.d/, depending on the file order, you
can end up with either:
- B is parsed first. An unit "C.service" will be "created" and will be
added as additional name to B.service, with unit_add_name. No bug.
- A is parsed first. An unit "C.service" is created for the
"Required-Start" dependency (it will have no file attached, since
nothing provides this dependency yet). Then B is parsed and when trying
to handle "Provides: C", unit_add_name is called but will fail, because
"C.service" already exists in manager->units. Therefore, a merge should
occur for that case.
The manager already prints "Time has been changed" at level info. It
seems too verbose to print the time change message additionally for
every waiting timer unit.
Downgrade the per-unit message to debug.
This alos gets rid of explicit sd_open_fd() and sd_open_address()
constructors in favour of sd_new() + sd_new_start() where the
negotiation parameters may be set it in between.
Setting MaxRetentionSec= caused the kernel log to overflow and the
journal daemon to enter an endless loop.
Logging from the journald main loop gets directed to /dev/kmsg,
which wakes up journald again. We skip the import of this message
by checking for our own PID, but this still causes the main loop
to never go to sleep again because we never stopped logging from
there.
Some code really wants to know whether there was a string list parsed,
so don't take the shortcut here, and always allocate a string list, even
if it is an empty one.
https://bugs.freedesktop.org/show_bug.cgi?id=62558
src/libsystemd-bus/bus-message.h:41:1: warning: attribute 'packed' is ignored, place it after
"struct" to apply attribute to type declaration [-Wignored-attributes]
Requesites are not supposed to be auto-started afterall, they are just
checks, so don't try to be smarter here than appropriate.
Based on a patch from Michal Schmidt.
Distributions that never shipped upstart do not have
"telinit" in /lib/upstart/..
Defaults to /lib/upstart/telinit so there is no change
for systems existing installs.
- Reword messages a bit
- Correct check whether EACCES is in the set of errors
- Don't complain if no journal files are found
- allocate Set object for errors lazily since in the best case we don't
need it at all.
- don't consider it an error if /run/log/journal doesn't exist (because
that's the usual case actually, if storage is enabled)
Some parts of systemd (at least the DBus activation codepath) "reply"
to signals, which of course have the no-reply flag set. We will be
defensive here and still send out a reply if we're passed a signal.
Regression introduced by: c6a818c820
Reported-by: Mantas Mikulėnas <grawity@gmail.com>
Tested-by: Mantas Mikulėnas <grawity@gmail.com>
Previously, it would set all caps, but it should drop them all, anything
else makes little sense.
Also, document that this works as it does, and what to do in order to
assign all caps to the bounding set.
https://bugzilla.redhat.com/show_bug.cgi?id=914705
Ensure clients don't overflow usec_t when doing relative time changes.
This is mostly just paranoia and protection against accidents, after all
clients are already authenticated, and they can se the time to any
value they wish anyway, but better be safe than sorry.
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1152187/comments/14
gcc does not know that errno cannot be negative, and warns
about unitialized variables later on. Kill the warnings by
returning -errno only after checking that errno is positive.
There are many ways in which we can get those checks wrong, so it is
better to warn and then error out on a real access failure.
The error messages are wrapped to <80 lines, because their primary
use is to be displayed in the terminal, and it is easier to read them
this way. Reading them in the journal can be a bit trickier, but
this is a bug in logs-show.c.
Auke Kok
Lennart Poettering
Harald Hoyer
Martin Pitt
Mantas Mikulėnas
Oleksii Shevchuk
Frederic Crozat
Michal Schmidt
Miklos Vajna
Kay Sievers
Zbigniew Jędrzejewski-Szmek
Cristian Rodríguez
Colin Walters