This is regards to the popularity-contest cron job.  I'm looking into
running systems without anacron/cron installed - instead using systemd
timers.

My suggestion would be to remove the what to do functionality from the
cron job/timing bits to another script - say popcon-runner.

The cron job could then be something like:
# skip in favour of systemd timer (from logrotate)
if [ -d /run/systemd/system ]; then
    exit 0
fi

<anything else cron specific needed to schedule when it runs>

popcon-runner

And creating a systemd timer/service for those that have systemd installed:

Timer File
/etc/systemd/system/timers.target.wants/popularity-contest.timer
[Unit]
Description=Sends popularity contest data

[Timer]
OnCalendar=daily
AccuracySec=24h  [ Can change this to be less accurate to spread
server load, etc)
Persistent=true

[Install]
WantedBy=timers.target

Service File
/usr/lib/systemd/system/popularity-contest.service
[Unit]
Description=Sends popularity contest data

[Service]
ExecStart=/path/to/popcon-runner
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

(can easily set nice levels, IO limits)

PrivateTmp=true
PrivateDevices=true

There are a bunch of other restrictions that can be placed on it via
systemd Private directives.

Thanks!

Hello Bryan,

Why not use systemd-cron instead ?

/etc/cron.daily/popularity-contest is a conffile, I cannot make it into
a systemd service.

Sorry for not answering sooner, systemd is still mysterious to me.

Cheers,

The usual way to handle both cron and systemd timers is to move most of
the logic in the cron script into a script in /usr then make the cron
script exit under systemd or call the /usr script under sysvinit and
then add a systemd timer and service that calls the /usr script.

An example of this approach is in the apt package, I think you could
use most of that as-is but adjusting names for the popcon cron job:

   /etc/cron.daily/apt-compat
   /usr/lib/apt/apt.systemd.daily
   /lib/systemd/system/apt-daily.service
   /lib/systemd/system/apt-daily.timer
   /lib/systemd/system/apt-daily-upgrade.service
   /lib/systemd/system/apt-daily-upgrade.timer
  
The systemd.directives manual page can be used to look up where
individual settings in the systemd service/timer files are documented.

Hi,

That's nucely written out, better than I could.

An extra bit of policy(*) I attempt to infuse with/for systemd-cron is this
one: the name of the crontab (here "apt-compat")
should match the name of the main timer (here "apt-daily", so not the case
yet) so that systemd-cron will ignore this one crontab and won't generate a
dynamic .timer + .service in /run for this package.

So my end goal for systemd-cron is that it would do nothing i.e. generate
no dynamic .timer / .service pair because all crontab would have a matching
static .timer shipped in the same package.

I understand it's a bit convulated to wrap it's mind around this one.

(*): not yet proposed for Policy, already talked about here:
https://lists.debian.org/debian-devel/2022/03/msg00211.html

Greetings,

Le jeu. 17 nov. 2022, 02:39, Paul Wise <pabs@debian.org> a écrit :

But then the user would not be able to configure it anymore,
so I do not see the upside.

Cheers,

They would be able to configure it via the config file as usual.

   /etc/popularity-contest.conf

They could also patch it automatically via an apt hook if needed, but
most people won't need to do that, I will though so that I can modify
the report in unsupported ways, for eg filtering out certain packages.

I just discovered an alternative that preserves the current location
and the conffile status of the cron.daily script. The script stays the
same, except it exits under systemd when the first argument isn't a
option indicating that the script should continue under systemd.
The systemd service then passes that option as the only parameter.

An example from the exim4-base package:

   $ head -n8 /etc/cron.daily/exim4-base
   #!/bin/sh
  
   EX4SYSTEMDTIMER=$1
  
   # skip in favour of systemd timer if called from cron.daily
   if [ -d /run/systemd/system ] && [ "$EX4SYSTEMDTIMER" != "systemd-timer" ]; then
               exit 0
   fi
  
   $ systemctl cat exim4-base.service exim4-base.timer
   # /lib/systemd/system/exim4-base.service
   [Unit]
   Description=exim4-base housekeeping
   Documentation=man:exim4(8)
   ConditionACPower=true
   Before=logrotate.service
  
   [Service]
   Type=oneshot
   ExecStart=/etc/cron.daily/exim4-base systemd-timer
  
   # performance options
   Nice=19
   IOSchedulingClass=best-effort
   IOSchedulingPriority=7
  
   # /lib/systemd/system/exim4-base.timer
   [Unit]
   Description=Daily exim4-base housekeeping
   Documentation=man:exim4(8)
   Before=logrotate.timer
  
   [Timer]
   OnCalendar=daily
   AccuracySec=12h
   Persistent=true
  
   [Install]
   WantedBy=timers.target

Sorry for the delay in getting back to you.

I expected savelog would implement locking against itself at least
but this is not the case.

Would you help me with this ?

Do you have spurious logfiles like

/var/log/popularity-contest.1010995
/var/log/popularity-contest.1010995.gpg

Cheers,

Hello Paul
Could you suggest a patch that implement this ?
Is it linked to systemd-timer ?

Cheers,