| Age | Commit message (Collapse) | Author |
|---|
|
Let's move the enforcement of the per-unit start limit from unit.c into the
type-specific files again. For unit types that know a concept of "result" codes
this allows us to hook up the start limit condition to it with an explicit
result code. Also, this makes sure that the state checks in clal like
service_start() may be done before the start limit is checked, as the start
limit really should be checked last, right before everything has been verified
to be in order.
The generic start limit logic is left in unit.c, but the invocation of it is
moved into the per-type files, in the various xyz_start() functions, so that
they may place the check at the right location.
Note that this change drops the enforcement entirely from device, slice, target
and scope units, since these unit types generally may not fail activation, or
may only be activated a single time. This is also documented now.
Note that restores the "start-limit-hit" result code that existed before
6bf0f408e4833152197fb38fb10a9989c89f3a59 already in the service code. However,
it's not introduced for all units that have a result code concept.
Fixes #3166.
|
|
This feature will not be used anytime soon, so remove a bit of cruft.
The BusPolicy= config directive will stay around as compat noop.
|
|
Remove some old cruft
|
|
This should be handled fine now by .dir-locals.el, so need to carry that
stuff in every file.
|
|
unit, not just services
This moves the StartLimitBurst=, StartLimitInterval=, StartLimitAction=, RebootArgument= from the [Service] section
into the [Unit] section of unit files, and thus support it in all unit types, not just in services.
This way we can enforce the start limit much earlier, in particular before testing the unit conditions, so that
repeated start-up failure due to failed conditions is also considered for the start limit logic.
For compatibility the four options may also be configured in the [Service] section still, but we only document them in
their new section [Unit].
This also renamed the socket unit failure code "service-failed-permanent" into "service-start-limit-hit" to express
more clearly what it is about, after all it's only triggered through the start limit being hit.
Finally, the code in busname_trigger_notify() and socket_trigger_notify() is altered to become more alike.
Fixes: #2467
|
|
string-util.[ch]
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
|
|
|
|
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
|
|
files from core
Stuff in src/shared or src/libsystemd should *never* include code from
src/core or any of the tools, so don't do that here either. It's not OK!
|
|
In order to re-use the policy definitions, factor them out into their own
files.
|
|
It's not safe invoking NSS from PID 1, hence fork off worker processes
that upload the policy into the kernel for busnames.
|
|
|
|
Add a new config 'Activating' directive which denotes whether a busname
is actually registered on the bus. It defaults to 'yes'.
If set to 'no', the .busname unit only uploads policy, which will remain
active as long as the unit is running.
|
|
AcceptFD= defaults to true, thus making sure that by default fd passing
is enabled for all activatable names. Since for normal bus connections
fd passing is enabled too by default this makes sure fd passing works
correctly regardless whether a service is already activated or not.
Making this configurable on both busname units and in bus connections is
messy, but unavoidable since busnames are established and may queue
messages before the connection feature negotiation is done by the
service eventually activated. Conversely, feature negotiation on bus
connections takes place before the connection acquires its names.
Of course, this means developers really should make sure to keep the
settings in .busname units in sync with what they later intend to
negotiate.
|
|
There are three directives to specify bus name polices in .busname
files:
* AllowUser [username] [access]
* AllowGroup [groupname] [access]
* AllowWorld [access]
Where [access] is one of
* 'see': The user/group/world is allowed to see a name on the bus
* 'talk': The user/group/world is allowed to talk to a name
* 'own': The user/group/world is allowed to own a name
There is no user added yet in this commit.
|
|
|
