FS#76966 - [apache] support for systemd integration

Attached to Project: Arch Linux
Opened by David '-1' Schmid (gdkags) - Friday, 30 December 2022, 18:46 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:25 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Apache 2.4.42 added support for better integration with systemd (through mod_systemd). It would be great if we enabled this feature for opt-in or even provide it as default.

Upstream documentation: https://httpd.apache.org/docs/2.4/mod/mod_systemd.html
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:25 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/apache/issues/2
Comment by loqs (loqs) - Friday, 30 December 2022, 21:17 GMT
@gdkags is the attached diff what you had in mind?
Added db to makedepends to fix current build failure.
Add systemd to makedepends and systemd-libs to optdepends. Add --enable-systemd to configure invocation.
Change service type to notify and use KillSignal=SIGWINCH for graceful shutdown instead of ExecStop=/usr/bin/httpd -k graceful-stop
Comment by David '-1' Schmid (gdkags) - Monday, 13 March 2023, 08:17 GMT
Sorry, I missed the update e-mail for this. Yes, this should do what I gathered from the documentation. Thank you!
Comment by David '-1' Schmid (gdkags) - Monday, 13 March 2023, 10:34 GMT
Sorry, I missed the update e-mail for this. Yes, this should do what I gathered from the documentation. Thank you!
Comment by Anatol Pomozov (anatolik) - Tuesday, 14 March 2023, 00:12 GMT
Ioqs, it sounds like it contains multiple independent fixes.

I haven't tested the *.server file change. Is there any possible risk with the service change?
Comment by Anatol Pomozov (anatolik) - Tuesday, 14 March 2023, 00:20 GMT
The 'db' fix was merged a while ago.

The systems module part has landed with SVN revision 470798 and will be available with the next apache build.

The service file change is still open. Ioqs, could you please add a bit more description for this change?
Comment by loqs (loqs) - Tuesday, 14 March 2023, 20:36 GMT
> The service file change is still open. Ioqs, could you please add a bit more description for this change?

There are two changes to the service file. The first is switching from ExecStop to KillSignal=SIGWINCH as /usr/bin/httpd -k graceful-stop is asynchronous and returns after sending SIGWINCH [3] before all processes may have stopped. This is cautioned against in the ExecStop section of [3] quote:
Note that it is usually not sufficient to specify a command for this setting that only asks the service to terminate (for example, by sending some form of termination signal to it), but does not wait for it to do so. Since the remaining processes of the services are killed according to KillMode= and KillSignal= or RestartKillSignal= as described above immediately after the command exited, this may not result in a clean stop. The specified command should hence be a synchronous operation, not an asynchronous one.
It is also cautioned against in [4] quote:
If configured, an ExecStop command should be a synchronous operation which itself exits when the daemon has terminated. Running httpd -k stop asynchronously initiates daemon termination, so does not satisfy this condition.
The new behavior also matches that used by Fedora [8] for 8 years. The counter argument is if no one has complained about the current behavior why change it?

The second change is changing the service type from simple to notify. This is more problematic than it might appear as I found during testing because notify support is in the systemd_module so that module must be loaded in order to use it. The first approach [6] I propose is to guarantee that module is loaded by using a configuration directive in the service file to load it. The second approach [2] is to load the module in httpd.conf and expect users to merge the changed configuration file. This leaves the service file cleaner. Fedora use a drop in .conf file to load the module, as far as I can see Arch / upstream does not support loading *.conf files from httpd.conf only specifically named ones.

[1] PKGBUILD.diff.stop
[2] https://httpd.apache.org/docs/2.4/stopping.html
[3] https://man.archlinux.org/man/core/systemd/systemd.service.5.en
[4] https://httpd.apache.org/docs/2.4/mod/mod_systemd.html
[5] https://src.fedoraproject.org/rpms/httpd/blob/rawhide/f/httpd.service#_27
[6] PKGBUILD.diff.notify1
[7] PKGBUILD.diff.notify2
Comment by David '-1' Schmid (gdkags) - Saturday, 18 March 2023, 08:42 GMT
My two cents, since I caused this: I had intended to just have '--enable-systemd' in the build flags.
So, while this sat in my inbox, unnoticed, the build flag was already enabled and before I answered this, I did not check again. I'm very sorry for that.
Re: the 'second change': it seems like it could cause some (or even a lot) of confusion when upgrading packages, which is something I'd rather avoid.

That makes this ticket a little pointless, now; except loqs put in a lot more work than just enabling the build flag (thank you a lot!) and actually solved some things that I'd have to research by myself.
I would be fine to close this ticket and, with your permission loqs, I'd pick up this information+patch here and put it (or some derivative) onto the wiki, so the information is available to other users. If you'd rather do this yourself, be my guest, but I'd fine of doing some work here, since you already did a lot.
Comment by loqs (loqs) - Sunday, 19 March 2023, 21:44 GMT
> Re: the 'second change': it seems like it could cause some (or even a lot) of confusion when upgrading packages, which is something I'd rather avoid.
Enabling the systemd module without any further changes causes a commented out entry for it to be added to httpd.conf.

> I would be fine to close this ticket and, with your permission loqs
Would you mind letting Anatol review the proposed changes?
Comment by David '-1' Schmid (gdkags) - Monday, 20 March 2023, 09:17 GMT
> Would you mind letting Anatol review the proposed changes?
Of course not! This was just meant as a way to resolve this without causing any trouble for future upgrades. Sorry, if this sounded like an offence, it was not intended this way.
Comment by David '-1' Schmid (gdkags) - Monday, 20 March 2023, 11:04 GMT
> Would you mind letting Anatol review the proposed changes?
Of course not! This was just meant as a way to resolve this without causing any trouble for future upgrades. Sorry, if this sounded like an offence, it was not intended this way.

Loading...