Bug 52669 - systemctl-daemon should be reloaded after changes on init.d- or systemd-files
systemctl-daemon should be reloaded after changes on init.d- or systemd-files
Status: NEW
Product: UCS
Classification: Unclassified
Component: General
UCS 4.4
All All
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-01-20 08:15 CET by Daniel Duchon
Modified: 2021-01-20 12:33 CET (History)
2 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2021011321000369
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Duchon univentionstaff 2021-01-20 08:15:38 CET
There are some init.d and systemd files that are built from templates.

When changes are made to the registry that affect these files, they are automatically rebuilt.

By the rebuild however also a 'systemctl daemon-reload' must be executed, so that a 'systemctl <service> reload' does not run on an error and a 'systemctl <service> restart' does not run into a WARNING.

Currently this has to be done manually.
However, if an administrator runs an update via the web interface, this can lead to an incorrect update in an unfavorable case.
Comment 1 Philipp Hahn univentionstaff 2021-01-20 10:34:03 CET
It still is an UCS policy to *not* restart services automatically after a UCR change - "interfaces/restart/auto" is the only painful exception.

You can work around this missing feature by using a "UCR Postint module" or "UCS script", see <https://docs.software-univention.de/developer-reference-4.4.html#ucr:info>
Comment 2 Daniel Duchon univentionstaff 2021-01-20 11:56:02 CET
(In reply to Philipp Hahn from comment #1)
> It still is an UCS policy to *not* restart services automatically after a
> UCR change - "interfaces/restart/auto" is the only painful exception.
> 
> You can work around this missing feature by using a "UCR Postint module" or
> "UCS script", see
> <https://docs.software-univention.de/developer-reference-4.4.html#ucr:info>

The point is not that the individual service is restarted immediately after a UCR change, but that the change is communicated to the systemd-daemon.

However, if changes are made to the dependencies as a result of changing the UCR variables or template files, these are not taken into account before a systemctl daemon-reload.

Shouldn't we also be consistent, if we already make changes to the init-files, then also perform a daemon-reload to exclude any errors that may result from this in the future?

Is it therefore not rather a bug?


BTW

This is the missing output from my test-system:

root@server:/etc/init.d# systemctl restart slapd
Warning: slapd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
root@schuldc1:/etc/init.d#



This is the missing information from the systemctl man-page:

systemctl daemon-reload
Reload the systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the
           entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of user configuration will stay accessible.
Comment 3 Philipp Hahn univentionstaff 2021-01-20 12:33:09 CET
I only told you that it is our current policy not to restart services.
The (generated) init files are configuration files to systemd, so what makes it so special to force systemd to reload its configuration files in violation of our current rule?

Also systemd choose to not reload its files automatically, but requires an explicit `systemctl daemon-reload`. They have a reason for that, which UCS should not ignore blindly or without discussion: <https://bugzilla.redhat.com/show_bug.cgi?id=615527>

From a users perspective I agree that the current UCS policy is a pain and it would we a huge usability gain if we changed our policy, either to restart always or at least those services implementing a `reload` to minimize down-time of services.
We probably would need to add a transaction like mechanism to UCR - most important to its UMC module - to be able to set / change / unset several UCRVs at once without restarting the service multiple times in between.