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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Chen Jie observed and analyzed a deadlock. Assuming systemd-kmsg-syslogd
is already stopped, but rsyslogd is not started yet:
1. systemd makes a synchronous call to dbus-daemon.
2. dbus-daemon wants to write something to syslog.
3. syslog needs to be started by systemd.
... but cannot be, because systemd is waiting in 1.
Solve this by avoiding synchronous D-Bus calls. I had to write an async
bus registration call. Interestingly, D-Bus authors anticipated this, in
documentation to dbus_bus_set_unique_name():
> The only reason to use this function is to re-implement the equivalent
> of dbus_bus_register() yourself. One (probably unusual) reason to do
> that might be to do the bus registration call asynchronously instead
> of synchronously.
Lennart's comments from IRC:
> though I think this doesn't fix the problem in its entirety
> simply because dbus_connection_open_private() itself is still synchronous
> i.e. the connect() call behind it is not async
> I think I listed that issue actually on some D-Bus todo list
> i.e. to make dbus_connection_get() fully async
> but that's going to be hard
> so your patch looks good
So it may not be perfect, but it's clearly an improvement.
I did not manage to reproduce the original deadlock with the patch.
Instead of having individual counters n_serializing and n_deserializing
have a single one n_reloading, which should be sufficient.
Set n_reloading when we are about to go down for reexecution to avoid
cgroup trimming when we free the units for reexecution.
This patch adds a cpp definition HAVE_SYSV_COMPAT that is used to
isolate code dealing with /etc/init.d and /etc/rcN.d for systems where
it does not make sense (one that does not use sysv or one that is fully
systemd native).
The patch tries to be as little intrusive as possible, however in
order to minimize the number of #ifdef'ed regions I've reordered some
code in path-lookup.c:lookup_paths_init() where all code dealing with
sysv is now isolated under running_as == MANAGER_SYSTEM as well.
Moreover, In struct Service, some fields were rearranged to reduce
the number of ifdefs.
Lennart's suggestions were fixed and squashed with the original patch,
that was sent by Gustavo Sverzut Barbieri (barbieri@profusion.mobi).
It is essential that the gettys are proper dependencies from
getty.target so that they aren't killed and immediately restarted on
runlevel changes. Hence rework the logic to implicitly add console
gettys to getty.target as dependencies.
This also adds an automatic hvc console for virtualizers.
https://bugzilla.redhat.com/show_bug.cgi?id=501720
Don't try to merge devices that have been created via dependencies when
they appear in the system and can be recognized as the same. Instead,
simply continue to maintain them independently of each other, however
with the same state cycle. Why? Because otherwise we'd have a hard time
to seperate the dependencies after the devices are unplugged again and
we hence cannot be sure anymore that next time the device is plugged in
it will carry the same names.
Example: if one depndency refers to dev-sda.device and another one to
dev-by-id-xxxyyy.device we only learn at time of plug in of the device
that it is actually the same device that was ment. In the moment the
device is unplugged again we won't know anymore their relation to each
other and the next time the harddisk is plugged it might even appear as
dev-by-id-xxxyyy.device and dev-sdb.service. To ensure the dependencies
continue to have the meaning they were intended to have let's hence keep
the .device objects seperate all the time, even when they are plugged
in.
This patch also introduces a new Following= property which points from
the various .device units of a specific device to the main .device unit
for it. This can be used by the client side to figure out the relation
of the .device units to each other and even filter units from display.
