Created attachment 337476 [details] squid systemd service unit Attached is a systemd service file for starting Squid. It parses the Squid config and creates the cache directories at startup, and supports config reloading. It retains the the max file descriptor limit of 1024 from the OpenRC runscript. To include in an ebuild, inherit the systemd eclass, and add 'systemd_dounit "${FILESDIR}"/squid.service' to src_install() (assuming squid.service is in $FILESDIR).
Created attachment 337624 [details] squid.service Sets user and group to squid.
Please contact upstream to provide a systemd unit file. Thank you.
*** Bug 504146 has been marked as a duplicate of this bug. ***
Pardon me, wasn't the council-approved policy that if a package doesn't provides an upstream-provided unit file, but there is a candidate for one, it should be included in the ebuild? I have a candidate unit file (based on Arch's), but I see that the one from Emery was rejected, so I'm asking first before uploading it. Also, I can add systemd@g.o to the CC list, since they have offered to take care of the unit file in any ebuild where a maintainer does not want to. Again, I'm just asking before doing that, since I believe adding the unit file is just a matter of adding "systemd" to the inherit line of the ebuild, and doing systemd_dounit "${FILESDIR}/squid.service" in the src_install() stage.
That comment was probably made before all those systemd discussions and council decision. Just go adead and attach the unit file. systemd folk usually take care of the rest. Adding systemd to cc and reopening.
Created attachment 387076 [details] squid unit file squid unit file based on Arch's
systemd compatibility is being tracked upstream by http://bugs.squid-cache.org/show_bug.cgi?id=3826
*** Bug 528342 has been marked as a duplicate of this bug. ***
Created attachment 465120 [details] correct systemd squid.service Even Red Hat does it wrong. ExecStop=/usr/sbin/squid -k shutdown -f ${SQUID_CONF} is really the wrong way to go because it doesn't wait for squid to exit, causing systemd to SIGKILL squid right away which is certainly NOT what we want. Instead, enjoy the SIGTERM default which is identical to "squid -k shutdown" but without the nasty side effect of a (too early) SIGKILL. However per default, squid takes 30 seconds to exit which is acceptable but quite a long time. Fortunately, this can easily be changed to 1 second in /etc/squid/squid.conf: shutdown_lifetime 1 second So ... please use this systemd unit in combination with shutdown_lifetime 1 in /etc/squid/squid.conf
Correction, that should be: So ... please use this systemd unit in combination with: shutdown_lifetime 1 second in /etc/squid/squid.conf See also http://www.christianschenk.org/blog/tuning-and-hardening-squid/
Is there any chance to get a service file for systemd?
Upstream now ships a systemd service file at tools/systemd/squid.service in the 4.13 tarball, so this should be trivial to fix.
(In reply to John Helmert III (ajak) from comment #12) > Upstream now ships a systemd service file at tools/systemd/squid.service in > the 4.13 tarball, so this should be trivial to fix. I meant "any chance to get a file installed into proper place using emerge".
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b7dc497f33a127dbf5706db72e9c5a077a8b82c commit 5b7dc497f33a127dbf5706db72e9c5a077a8b82c Author: Mikle Kolyada <zlogene@gentoo.org> AuthorDate: 2021-03-07 10:33:24 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2021-03-07 10:35:55 +0000 net-proxy/squid: add systemd support Closes: https://bugs.gentoo.org/454878 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Mikle Kolyada <zlogene@gentoo.org> net-proxy/squid/{squid-4.13.ebuild => squid-4.13-r1.ebuild} | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
