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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
'systemd-coredumpctl' will list available coredumps:
PID UID GID sig exe
32452 500 500 11 /home/zbyszek/systemd/build/journalctl
32666 500 500 11 /usr/lib64/valgrind/memcheck-amd64-linux
...
'systemd-coredumpctl dump PID' will write the coredump
to specified file or stdout.
Given that "journalctl -u" exists now there's no need to duplicate this
functionality in systemctl, so let's drop this, especially given that it
always felt a bit awkward to overload "-f" to both --force and --follow,
and to have continues output with a status header for this.
systemctl status -f avahi-daemon
now becomes:
journalctl -fu avahi-daemon
Which is shorter and a lot less redundant.
The new 'unique' API allows listing all unique field values that a field
specified by a field name can take in all entries of the journal. This
allows answering queries such as "What units logged to the journal?",
"What hosts have logged into the journal?", "Which boot IDs have logged
into the journal?".
Ultimately this allows implementation of tools similar to lastlog based
on journal data.
Note that listing these field values will not work for journal files
created with older journald, as the field values are not indexed in
older files.
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.
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>
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>
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.
