On Wed, Jun 17, 2020 at 10:06:39PM +1000, Nathan Scott wrote:
> Digging into that aspect, it seems the PCP configure script has now
> started disabling systemd (!) on Debian for reasons I don't follow.
>
> Here's a relevant build log:
> https://buildd.debian.org/status/fetch.php?pkg=pcp&arch=amd64&ver=5.1.1-1&stamp=1590715276&raw=0
>
> This is the relevant PCP configure.ac snippet:
>
> dnl Check for systemd services
> enable_systemd=false
> AC_MSG_CHECKING([if systemd should be used])
> AS_IF([test "x$do_systemd" != "xno"], [
> enable_systemd=true
>
> PKG_CHECK_VAR([SYSTEMD_SYSTEMUNITDIR], [systemd], [systemdsystemunitdir],
> [pcp_systemdunit_dir=$SYSTEMD_SYSTEMUNITDIR], [enable_systemd=false])
>
> so, we are (all of a sudden?) taking the enable_systemd=false path
> and looks like it's all downhill from there.
I bet the buildd chroots don't have systemd installed, and you don't
build-depend on it. You probably also want to build-depend on
libsystemd-dev, which ships the sd-daemon.h header used by another check
in configure.ac.
More generally though, it's not great for a Debian package to ship timer
units vs cron jobs based on whether systemd was installed when the
package is built.
This is because some users still prefer to use sysvinit on their Debian
system, in which case nothing will be launching pcp's timer units.
The good news is that it's easy to handle this case by modifying your
cron jobs, for instance:
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php/sessionclean ] && if [ ! -d
/run/systemd/system ]; then /usr/lib/php/sessionclean; fi
It's also a good idea to check whether the program your cron job
launches is still runnable in order to handle the case where the package
has been removed (which removes the program) but not purged. In this
case, conffiles such as cron jobs will still be present, and root will
receive lots of mail from cron about the missing program. :)
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
