`systemctl kill` leverages systemd's knowledge of the daemon's main PID, eliminating the need to rely on PID files or external tools like `killall` or `pkill`. This ensures precise signal sending to the intended process, reducing the risk of errors in process identification. Additionally, using `systemctl kill` logs the signal sending in the service's journal, providing a record of actions taken. Requires selinux-policy-41.43 or higher (see https://bugzilla.redhat.com/show_bug.cgi?id=2369644), available as an update for F41, F42, and Rawhide. https://bodhi.fedoraproject.org/updates/FEDORA-2025-eb98eb9e24 (F41 -- will go to stable in a few days) https://bodhi.fedoraproject.org/updates/FEDORA-2025-f9f097f491 (F42 -- stable) https://bodhi.fedoraproject.org/updates/FEDORA-2025-3db4c0ec1c (Rawhide) The logrotate configuration snippet: # cat /etc/logrotate.d/pgbouncer /var/log/pgbouncer/pgbouncer.log { missingok copytruncate compress notifempty sharedscripts create 0640 pgbouncer pgbouncer nodateext weekly rotate 5 postrotate /usr/bin/kill -HUP `cat /var/run/pgbouncer/pgbouncer.pid 2>/dev/null` 2> /dev/null || true endscript } In the postrotate script, kill can be replaced by: /usr/bin/systemctl kill --signal=HUP --kill-whom=main pgbouncer.service 2>/dev/null || true Because: # systemctl show -P MainPID pgbouncer.service 3983 # cat /var/run/pgbouncer/pgbouncer.pid 3983 However, there are conflicting options. The presence of `copytruncate` in the configuration snippet makes the postrotate script and the `sharedscripts` option unnecessary, as the original log file is preserved, eliminating the need for the daemon to reopen the file after log rotation. A simpler alternative is to keep `copytruncate` and remove the postrotate script and `sharedscripts`. Reproducible: Always Additional Information: pgbouncer-1.24.1-5.fc42.x86_64
If you decide to keep `copytruncate`, the `create` option can be removed as per logrotate(8): > copytruncate > Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place. The copytruncate option allows storing rotated log files on the different devices using olddir directive. The copytruncate option implies norenamecopy.
The systemctl kill command is available since systemd 240; so I'll add the proposed changes to el9, el10, fc41, fc42 and fc43. The --kill-whom parameter is in systemctl kill since version 252, so by luck also el9 is covered.
Sorry, pressed enter too fast. I've removed the sharedscripts, create and postrotate, but I will use the systemctl kill for the ExecReload command (https://bugzilla.redhat.com/show_bug.cgi?id=2403541).
Actually no, I'll stick to the kill -HUP for ExecReload as in the systemd.service man page for now. Thanks!
Regarding the --kill-whom option, yes, it's been supported since systemd 252. However, the --kill-who option has been around for ages and is still recognized by recent versions for backward compatibility. I opened this bug with a focus on Fedora (where --kill-whom is guaranteed to be supported) due to the SELinux policy, which *requires* at least version 41.43 for the logrotate fragment to work — I have no idea how or when that version will land in RHEL. Using /usr/bin/kill in ExecReload= is a common idiom in systemd unit files. systemctl kill is useful outside the unit.
(In reply to Marcos Mello from comment #5) > Using /usr/bin/kill in ExecReload= is a common idiom in systemd unit files. > systemctl kill is useful outside the unit. Exactly, for a moment I thought that I could also leverage systemctl --kill-whom=control directly in the systemd unit. Changes are in the branches, waiting for this to be fixed to publish the update: https://pagure.io/releng/issue/13073
FEDORA-2025-34773babcd (pgbouncer-1.25.0-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-34773babcd
FEDORA-2025-6421c2f4da (pgbouncer-1.25.0-5.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-6421c2f4da
FEDORA-EPEL-2025-2937411d89 (pgbouncer-1.25.0-4.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-2937411d89
FEDORA-EPEL-2025-22fc24e2ed (pgbouncer-1.25.0-4.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-22fc24e2ed
FEDORA-2025-24f14430ea has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-24f14430ea` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-24f14430ea See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-968a76d07e has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-968a76d07e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-6421c2f4da has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-6421c2f4da` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6421c2f4da See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-34773babcd has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-34773babcd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-34773babcd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-2937411d89 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-2937411d89 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-22fc24e2ed has been pushed to the Fedora EPEL 10.1 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-22fc24e2ed See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-6421c2f4da (pgbouncer-1.25.0-5.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-968a76d07e (pgbouncer-1.25.0-4.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-24f14430ea (pgbouncer-1.25.0-5.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-34773babcd (pgbouncer-1.25.0-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-22fc24e2ed (pgbouncer-1.25.0-4.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-2937411d89 (pgbouncer-1.25.0-4.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.