Age | Commit message (Collapse) | Author |
|
Much like logind has a client in loginctl, and journald in journalctl
introduce timedatectl, to change the system time (incl. RTC), timezones
and related settings.
|
|
This also enables time-based rotation (but not vacuuming) after 1month,
so that not more one month of journal is lost at a time per vacuuming.
|
|
|
|
This applies unit_name_mangle() to the specified unit names and hence
can handle weird characters nicely and will add unit suffixes as
necessary.
|
|
|
|
As you likely know, Arch Linux is in the process of moving to systemd.
So I was reading through the various systemd docs and quickly became
baffled by this new abbreviation "resp.", which I've never seen before
in my English-mother-tongue life.
Some quick Googling turned up a reference:
<http://www.transblawg.eu/index.php?/archives/870-Resp.-and-other-non-existent-English-wordsNicht-existente-englische-Woerter.html>
I guess it's a literal translation of the German "Beziehungsweise", but
English doesn't work the same way. The word "respectively" is used
exclusively to provide an ordering connection between two lists. E.g.
"the prefixes k, M, and G refer to kilo-, mega-, and giga-,
respectively." It is also never abbreviated to "resp." So the sentence
"Sets the default output resp. error output for all services and
sockets" makes no sense to a natural English speaker.
This patch removes all instances of "resp." in the man pages and
replaces them with sentences which are much more clear and, hopefully,
grammatically valid. In almost all instances, it was simply replacing
"resp." with "or," which the original author (Lennart?) could probably
just do in the future.
The only other instances of "resp." are in the src/ subtree, which I
don't feel privileged to correct.
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
|
|
|
|
text/event-stream
|
|
to show their details
|
|
Fix reference to "system-shutdown" as being a binary.
|
|
handle-hibernate-key in systemd-inhibit help and man.
|
|
to IPv4/IPv6
|
|
No longer override the default kernel font if nothing is specified in
vconsole.conf.
The default kernel font[0] provides ISO-8859-1 and box characters. Users
of Arabic, Cyrilic or Hebrew must set a different font manually as these
character sets were provided by the old default font [1], but are not
any longer.
Rationale:
* it is counter-intuitive that an empty vconsole.conf file is different
from adding FONT="";
* the version of the default font shipped with Arch (which is the
upstream one) behaves very badly during early boot[2] (which should
admittedly be fixed in the font itself);
* the kernel already supplies a default font, it seems reasonable to
use that unless anything else is specified;
* This also avoids a needless slow call to setfont; and
* We don't want to work around problems in the kernel (in case the
compiled-in font is not acceptable for whatever reason).
[0]: <https://dev.archlinux.org/~tomegun/kernel.bdf>
[1]: <https://dev.archlinux.org/~tomegun/latarcyrheb.bdf>
[2]: <http://i.imgur.com/J2tM4.jpg>
|
|
s/Generator/Generators/
|
|
The documentation for --link-journal is also reworded.
|
|
|
|
implements
|
|
|
|
|
|
The kernel and X11 distuingish these two, and Thinkpad keys have both,
hence we really should distinguish them too.
|
|
|
|
http://lists.freedesktop.org/archives/systemd-devel/2012-September/006604.html
https://bugzilla.gnome.org/show_bug.cgi?id=680689
This changes the meaning of the
HandlePowerKey=/HandleSleepKey=/HandleLidSwitch= setting of logind.conf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously, if X allocated all 6 TTYs (for multi-session for example) no
getty would be available anymore to guarantee console-based logins.
With the new ReserveVT= switch in logind.conf we can now choose one VT
(6 by default) that will always be subject to autovt-style activation,
i.e. we'll always have a getty on TTY6, and X will never take possession
of it.
|
|
This resolves problems with filesystems which do not implement the
aio_write file operation. In this case, the kernel will fall back using
a loop writing technique for each pointer in a received iovec. The
result is strange errors in dmesg such as:
[ 31.855871] elevator: type not found
[ 31.856262] elevator: switch to
[ 31.856262] failed
It does not make sense to implement a synchronous aio_write method for
sysfs as this isn't a real filesystem where a reasonable use case for
using writev exists, nor is there an expectation that tmpfiles will be
used to write more data than can be reasonably written in a single write
syscall.
In addition, some sysfs attrs are currently buggy and will NOT reject
the second write with the newline, causing the sysfs value to be zeroed
out. This of course should be fixed in the kernel regardless of any
wrongdoing in userspace, but this simple change makes us immune to such
a bug.
This change means that we do not write a trailing newline by default, as
the expected use case of 'w' is for sysfs and procfs. In exchange, honor
C-style backslash escapes so that if the newline is really needed, the
user can add it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=54501
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=54501
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=54501
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=54501
|
|
Break out the write logic into a separate function and simply use it as
a callback to glob_item.
This allows users to consolidate writes to sysfs with multiple similar
pathnames, e.g.
w /sys/class/block/sd[a-z]/queue/read_ahead_kb - - - - 1024
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=54448
|
|
|
|
|
|
|
|
|
|
journals by default
|
|
|
|
The kernel implicitly does sync() anyway, hence there is no need to do
that in userspace explicitly. This makes the "-n" switch to halt(8) a
noop.
|