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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We would not send the property because we'd call sd_bus_get_current_message()
which would return NULL. If there is no message, we cannot support /self or
/auto, but things are still OK if a path with a session name is given.
Traceback when the issue is triggered:
#2 we'd call sd_bus_get_current_message() here, which would return NULL, and
session_object_find() would immediately return 0.
#3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2",
interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0)
at ../src/login/logind-session-dbus.c:620
#4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2",
c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37
#5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110,
prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2",
interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163,
names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088
#6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110,
path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session",
names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291
#7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active")
at ../src/login/logind-session-dbus.c:730
#8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249
#9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361
#10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395
#11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0)
at ../src/login/logind.c:588
#12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828
#13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241
#14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615)
at ../src/libsystemd/sd-event/sd-event.c:3299
#15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186
#16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234
#17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244
Fixes#13437. Bug introduced in 3b92c086a8.
This fixes the following problem:
> At the very end of the boot, just after the first user logs in
> (usually using sddm / X) I get the following messages in my logs:
> Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
> Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
These messages are caused by the "stub" service files that systemd
installs. It installed them because early versions of systemd activation
required them to exist.
Since dbus 1.11.0, a dbus-daemon that is run with --systemd-activation
automatically assumes that o.fd.systemd1 is an activatable
service. As a result, with a new enough dbus version,
/usr/share/dbus-1/services/org.freedesktop.systemd1.service and
/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service should
become unnecessary, and they can be removed.
dbus 1.11.0 was released 2015-12-02.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914015
This reverts commit 2de9b9793b.
This check causes regressions, in particular our own units fail. Apparently, it
is enough for the unit to be referenced enough times:
$ journalctl -b -u systemd-ask-password-console.path
Aug 30 12:08:14 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: systemd-ask-password-console.path: Start request repeated too quickly.
Aug 30 12:08:33 krowka systemd[1]: Failed to start Dispatch Password Requests to Console Directory Watch.
$ journalctl -b -u systemd-firstboot.service
-- Logs begin at Sun 2019-04-21 12:39:21 CEST, end at Fri 2019-08-30 12:23:06 CEST. --
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: systemd-firstboot.service: Start request repeated too quickly.
Aug 30 12:08:33 krowka systemd[1]: Failed to start First Boot Wizard.
And the same for other units.
Fixes#13434.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935829
In a current VirtualBox installation the board_vendor is set to "Oracle
Corporation". So we need to add this to the dmi_vendor_table for a
relieable detection.
This fixes#13429
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
In the past, we asked people to open a security bug on one of the "big"
distros. This worked OK as far as getting bugs reported and notifying some
upstream developers went. But we always had trouble getting information to
all the appropriate parties, because each time a bug was reported, a big
thread was created, with a growing CC list. People who were not CCed early
enough were missing some information, etc.
To clean this up, we decided to create a private mailing list. The natural
place would be freedesktop.org, but unfortunately the request to create a
mailing list wasn't handled
(https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/134). And even
if it was, at this point, if there was ever another administrative issue, it
seems likely it could take months to resolve. So instead, we asked for a list
to be created on the redhat mailservers.
Please consider the previous security issue reporting mechanisms rescinded, and
send any senstive bugs to systemd-security@redhat.com.
systemctl supports runlevel invocation name without utmp.
The runlevel symlink is installed unconditionally.
So it's reasonable to install runlevel manpage with it as well.
Signed-off-by: Jan Chren (rindeal) <dev.rindeal@gmail.com>
When booting with Fedora-Server-dvd-x86_64-30-20190411.n.0.iso,
/proc/cmdline is empty (libvirt, qemu host with bios, not sure if that
matters), after installation to disk, anaconda would "crash" in kernel-core
%posttrans, after calling kernel-install, because dracut would fail
with
> Could not determine the kernel command line parameters.
> Please specify the kernel command line in /etc/kernel/cmdline!
I guess it's legitimate, even if unusual, to have no cmdline parameters.
Two changes are done in this patch:
1. do not fail if the cmdline is empty.
2. if /usr/lib/kernel/cmdline or /etc/kernel/cmdline are present, but
empty, ignore /proc/cmdline. If there's explicit configuration to
have empty cmdline, don't ignore it.
The same change was done in dracut:
https://github.com/dracutdevs/dracut/pull/561.
Traditionally, user logins had a $PATH in which /bin was before /sbin, while
root logins had a $PATH with /sbin first. This allows the tricks that
consolehelper is doing to work. But even if we ignore consolehelper, having the
path in this order might have been used by admins for other purposes, and
keeping the order in user sessions will make it easier the adoption of systemd
user sessions a bit easier.
Fixes#733.
https://bugzilla.redhat.com/show_bug.cgi?id=1744059
OOM handling in manager_default_environment wasn't really correct.
Now the (theorertical) malloc failure in strv_new() is handled.
Please note that this has no effect on:
- systems with merged /bin-/sbin (e.g. arch)
- when there are no binaries that differ between the two locations.
E.g. on my F30 laptop there is exactly one program that is affected:
/usr/bin/setup -> consolehelper.
There is less and less stuff that relies on consolehelper, but there's still
some.
So for "clean" systems this makes no difference, but helps with legacy setups.
$ dnf repoquery --releasever=31 --qf %{name} --whatrequires usermode
anaconda-live
audit-viewer
beesu
chkrootkit
driftnet
drobo-utils-gui
hddtemp
mate-system-log
mock
pure-ftpd
setuptool
subscription-manager
system-config-httpd
system-config-rootpassword
system-switch-java
system-switch-mail
usermode-gtk
vpnc-consoleuser
wifi-radar
xawtv
When we would iterate over the lookup paths for each unit, making the list as
short as possible was important for performance. With the current cache, it
doesn't matter much. Two classes of paths were being removed:
- paths which don't exist in the filesystem
- paths which symlink to a path earlier in the search list
Both of those points cause problems with the caching code:
- if a user creates a directory that didn't exist before and puts units there,
now we will notice the new mtime an properly load the unit. When the path
was removed from list, we wouldn't.
- we now properly detect whether a unit path is on the path or not.
Before, if e.g. /lib/systemd/system, /usr/lib/systemd/systemd were both on
the path, and /lib was a symlink to /usr/lib, the second directory would be
pruned from the path. Then, the code would think that a symlink
/etc/systemd/system/foo.service→/lib/systemd/system/foo.service is an alias,
but /etc/systemd/system/foo.service→/usr/lib/systemd/system/foo.service would
be considered a link (in the systemctl link sense).
Removing the pruning has a slight negative performance impact in case of
usr-merge systems which have systemd compiled with non-usr-merge paths.
Non-usr-merge systems are deprecated, and this impact should be very small, so
I think it's OK. If it turns out to be an issue, the loop in function that
builds the cache could be improved to skip over "duplicate" directories with
same logic that the cache pruning did before. I didn't want to add this,
becuase it complicates the code to improve a corner case.
Fixes#13272.
*We* control the sysctl setting. If the user configured IPv6, then we apply the
settings, and just make sure that at some point during the configuration the
sysctl is disabled (i.e. ipv6 enabled) if we have IPv6 configured.
Replaces #13283.
This test runs under qemu, which may run on some testbeds without
acceleration; in those cases, a 10s timeout is frequently too short.
Simply removing the timeout to allow the default timeoutsec should
be enough time for the test to finish, even on very slow testbeds.
The acceleromater in the GPD win is in the base, mark it as such so that
iio-sensor-proxy does not try to use it for display rotation.
Note as mentioned in the added comment the DMI strings are unfortunately
somewhat generic, but the combination of using all DMI strings including
the BIOS build data + the sensor modalias should be unique enough.
This avoids unnecessary noise in the stderr logs which dd always produces,
such as:
0+0 records in
0+0 records out
0 bytes copied, 0.000155284 s, 0.0 kB/s
Using truncate should not result in any functional change; the image will
still be created as a sparse file of the size specified.
In Ubuntu CI, we test binaries from the installed system, not from
$BUILD_DIR, so use the appropriate binary. Most of the calls to the
binaries are part of checking/processing asan-built binaries, and so
did not apply to Ubuntu CI, except for generating noise in the stderr
log like:
objdump: '/tmp/autopkgtest.83yGoI/build.fHB/src/test/TEST-01-BASIC/systemd-journald': No such file
However this also applies to the call to systemd-nspawn, which the debian
upstream test wrapper was sed-adjusting to use the installed binary
instead of the binary in $BUILD_DIR. This commit allows removing that
sed processing of the test-functions file during Ubuntu CI test.
