| Age | Commit message (Collapse) | Author |
|---|
|
Now that objects of all unit types are allocated the exact amount of
memory they need, the Unit union has lost its purpose. Remove it.
"Unit" is a more natural name for the base unit class than "Meta", so
rename Meta to Unit.
Access to members of the base class gets simplified.
|
|
When we merge units that some kind of object points to, those pointers
might become invalidated, and needs to be updated. Introduce a UnitRef
struct which links up all the unit references, to ensure corrected
references.
At the same time, drop configured_sockets in the Service object, and
replace it by proper UNIT_TRIGGERS resp. UNIT_TRIGGERED_BY dependencies,
which allow us to simplify a lot of code.
|
|
|
|
There are a lot of forking daemons that do not exactly follow the
initialization steps as described in daemon(7). It is common that they
do not bother waiting in the parent process for the child to write the
PID file before exiting. The daemons' developers often do not perceive
this as a bug and they're unwilling to change.
Currently systemd warns about the missing PID file and falls back to
guessing the main PID. Being not quite deterministic, the guess can be
wrong with bad consequences. If the guessing is disabled, determinism is
achieved at the cost of losing the ability of noticing when the main
process of the service dies.
As long as it does not negatively affect properly written services,
systemd should strive for compatibility even with services with racy
daemonization. It is possible to provide determinism _and_ main process
supervision to them.
If the PID file is not there, rather than guessing and considering the
service running immediately after getting the SIGCHLD from the ExecStart
(or ExecStartPost) process, we can keep the service in the activating
state for a bit longer. We can use inotify to wait for the PID file to
appear. Only when it finally does appear and we read a valid PID from
it, we'll move the service to the running state. If the PID file never
appears, the usual timeout kicks in and the service fails.
|
|
|
|
child of init die
https://bugzilla.redhat.com/show_bug.cgi?id=699114
|
|
|
|
|
|
each other, so that both can be executed simultaneously and independently
|
|
just the reload job
|
|
|
|
|
|
|
|
similar
|
|
|
|
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).
|
|
|
|
|
|
|
|
lines for oneshot services
In contrast to the other service types oneshot services are usually not
long lasting and there's not necessarily a single clean main process for
them. This change allows multiple ExecStart= lines for this type of
services so that the admin/developer doesn't have to arbitrarily pick on
of various sequential commands as the "main one".
|
|
|
|
Previously we checked the SysV priority value to figure out if a SysV
unit was enabled or not, since th value was mostly read from the S
startup links. Since we read this value from the LSB headers as a
fallback we hence ended up considering a lot more services enabled than
were actually enabled.
This patch adds an explicit boolean which encodes whether a sysv service
is enabled or not via S links.
https://bugzilla.redhat.com/show_bug.cgi?id=615293
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
