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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Debian recently introduced the option key-slot to /etc/crypttab to
specify the LUKS key slot to be used for decrypting the device. On
systems where a keyfile is used and the key is not in the first slot,
this can speed up the boot process quite a bit, since cryptsetup does
not need to try all of the slots sequentially. (Unsuccessfully testing
a key slot typically takes up to about 1 second.)
This patch makes systemd aware of this option.
Debian bug that introduced the feature:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704470
A compatibility libsystemd-login library is created which uses
.symver and ifunc magic proposed by Lennart to make programs linked
to the old library name continue to work seamlessly.
Unfortunately the bfd linker crashes:
https://sourceware.org/bugzilla/show_bug.cgi?id=16467
This will be fixed in binutils 2.25.
As a work-around, gold can be used:
LDFLAGS=-Wl,-fuse-ld=gold
Unfortunately the switch to pick the linker appeared in gcc 4.8.
This also doesn't work with LLVM:
http://llvm.org/bugs/show_bug.cgi?id=11897
gold doesn't exhibit the problems with linking of compatibility
libraries.
It is also slightly faster:
make clean && make -j5 bfd gold
real 34.885s 33.707s
user 34.486s 32.189s
sys 9.929s 10.845s
real 35.128s 33.508s
user 34.660s 31.858s
sys 10.798s 10.341s
real 35.405s 33.748s
user 34.765s 32.384s
sys 11.635s 10.998s
real 35.250s 33.795s
user 34.704s 32.253s
sys 11.220s 11.469s
touch src/libsystemd/sd-bus.c && make -j5
bfd gold
real 10.224s 9.030s
user 11.664s 9.877s
sys 3.431s 2.878s
real 10.021s 9.165s
user 11.526s 9.990s
sys 3.061s 3.015s
real 10.233s 8.961s
user 11.657s 9.973s
sys 3.467s 2.202s
real 10.160s 9.086s
user 11.637s 9.950s
sys 3.188s 2.859s
This works around the goa daemon crash:
Jan 25 20:54:24 lon goa[1363]: goa-daemon version 3.10.2 starting [main.c:117, main()]
Jan 25 20:54:24 lon systemd[424]: Starting Legacy D-Bus Protocol Compatibility Daemon (PID 1363/UID 2702)...
Jan 25 20:54:24 lon systemd[424]: Started Legacy D-Bus Protocol Compatibility Daemon (PID 1363/UID 2702).
Jan 25 20:54:24 lon kernel: goa-daemon[1363]: segfault at 20 ip 00007f46914b26d5 sp 00007fff1ae6d9a0 error 4 in libtelepathy-glib.so.0.80.1[7f469144f000+228000]
Jan 25 20:54:24 lon systemd-coredump[1368]: Process 1363 (goa-daemon) dumped core.
Jan 25 20:54:32 lon goa[1375]: goa-daemon version 3.10.2 starting [main.c:117, main()]
This brings the calls into similar style as the respective functions in
libsystemd-journal, and also is a bi shorter and more descriptive since
it clarifies the time unit used.
This reverts commit 021b89861d0b1defcbd6ba71d1aaf6271785a942.
Something is not quite right, "KillUnit" sent from systemctl is not
handled correctly and shutdown has problems.
logind has no concept of session ordering. Sessions have a unique name,
some attributes about the capabilities and that's already it. There is
currently no stable+total order on sessions. If we use the logind API to
switch between sessions, we are faced with an unordered list of sessions
we have no clue of.
This used to be no problem on seats with VTs or on seats with only a
single active session. However, with the introduction of multi-session
capability for seats without VTs, we need to find a way to order sessions
in a stable way.
This patch introduces session "positions". A position is a simple integer
assigned to a session which is never changed implicitly (currently, we
also don't change it explicitly, but that may be changed someday). For
seats with VTs, we force the position to be the same as the VTnr. Without
VTs, we simply find the lowest unassigned number and use it as position.
If position-assignment fails or if, for any reason, we decide to not
assign a position to a session, the position is set to 0 (which is treated
as invalid position).
During session_load() or if two sessions have the same VTnr, we may end up
with two sessions with the same position (this shouldn't happen, but lets
be fail-safe in case some other part of the stack fails). This case is
dealt with gracefully by ignoring any session but the first session
assigned to the position. Thus, session->pos is a hint, seat->positions[i]
is the definite position-assignment. Always verify both match in case you
need to modify them!
Additionally, we introduce SwitchTo(unsigned int) on the seat-dbus-API.
You can call it with any integer value != 0 and logind will try to switch
to the request position. If you implement a compositor or any other
session-controller, you simply watch for ctrl+alt+F1 to F12 and call
SwitchTo(Fx). logind will figure a way out deal with this number.
For convenience, we also introduce SwitchToNext/Previous(). It should be
called on ctrl+alt+Left/Right (like the kernel-console used to support).
Note that the public API (SwitchTo*()) is *not* bound to the underlying
logic that is implemented now. We don't export "session-positions" on the
dbus/C API! They are an implementation detail. Instead, the SwitchTo*()
API is supposed to be a hint to let logind choose the session-switching
logic. Any foreground session-controller is free to enumerate/order
existing sessions according to their needs and call Session.Activate()
manually. But the SwitchTo*() API provides a uniform behavior across
session-controllers.
Background: Session-switching keys depend on the active keymap. The XKB
specification provides the XKB_KEY_XF86Switch_VT_1-12 key-symbols which
have to be mapped by all keymaps to allow session-switching. It is usually
bound to ctrl+alt+Fx but may be set differently. A compositor passes any
keyboard input to XKB before passing it to clients. In case a key-press
invokes the XKB_KEY_XF86Switch_VT_x action, the keypress is *not*
forwarded to clients, but instead a session-switch is scheduled.
This actually prevents us from handling these keys outside of the session.
If an active compositor has a keymap with a different mapping of these
keys, and logind itself tries to catch these combinations, we end up with
the key-press sent to the compositor's clients *and* handled by logind.
This is *bad* and we must avoid this. The only situation where a
background process is allowed to handle key-presses is debugging and
emergency-keys. In these cases, we don't care for keymap mismatches and
accept the double-event. Another exception is unmapped keys like
PowerOff/Suspend (even though this one is controversial).
Similar to PrivateNetwork=, PrivateTmp= introduce PrivateDevices= that
sets up a private /dev with only the API pseudo-devices like /dev/null,
/dev/zero, /dev/random, but not any physical devices in them.
