popularity-contest still Recommends cron|cron-daemon on Linux ports. It would be desirable to migrate the cron job to a systemd timer on Linux ports. The cron job remains desirable on the Hurd port, however, since that port has no systemd unit support.

Martin-Éric

[Martin-Éric Racine]

What is the feature of a systemd timer that popularity-contest would
gain from, and how will its advantage compencate for the need to
maintain two different cron job mechanisms?

pe 6.12.2024 klo 19.51 Petter Reinholdtsen (pere@hungry.com) kirjoitti:

https://udd.debian.org/lintian-tag/missing-systemd-timer-for-cron-script
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007257

Ideally, popularity-contest would ship both a cron job and a systemd
timer, drop the recommends on cron|cron-daemon and presume that the
host comes with some task scheduler that can leverage either one.

Martin-Éric

Could you provide a patch that does not break backward compatibility with the
fact that /etc/cron.daily/popularity-contest is a conffile ?

Cheers,

[Petter Reinholdtsen]

[Martin-Éric Racine]

Thank you for the pointers.  As far as I can see, any advantages for
popularity-contest are not mentioned in either of these.  The overhead
of maintaining both a cron job and a systemd timer would on the other
hand be very noticable.  Did I misunderstand something?

There is systemd-cron, which by the way provides cron-daemon anyway,
although that could have been made more explicit for those unaware.
Thing is, it's also a crutch, and was only ever meant as an interim
solution while the remaining vestiges of cron crumble(d) away. The
question is not (and was not) what systemd timers provide that cron and
friends don't: they provide all of that and much, much more, that's one
reason they replaced it. It is obsolete on systemd-platforms, that is
probably 95% of Linux desktops/servers. And there is no excuse to make
the vast majority of users install *two* equivalent mechanism, or even a
crutch as mentioned, when they already have systemd, and whether they
like it or not. Virtually nothing else requires to install cron-cruft
anymore.

Well, then please address my request:

" Provide a patch that does not break backward compatibility with the fact that
/etc/cron.daily/popularity-contest is a conffile. "

Cheers,

First of all thanks for the reminder, for some reason I failed to see
all but the oldest reply, that's why I only referred to that. It
certainly wasn't meant to be rude. Now I'm very likely misunderstanding
something, but ls -R /etc/cron* still lists about 10 files on my
cron-less system: are these not conffiles? To be sure I don't care about
that, they're just text files. Rather, like someone else suggested,
PopCon should ideally provide both, after all that's how those 10 other
packages deal with it, and countless others not installed. If that isn't
possible for PopCon for some reason beyond me, ok, end of story. The
inital justification given here however was burden of maintenance, that
is something else entirely.

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.general as well.

Bill Allombert <ballombe@debian.org> writes:

Could you say what the unusual requirements are? i couldnt tell from the bug

i think one issue is that sending email from systemd-timers is harder
than it should be due to an incompatibility between the way exim (and
maybe postfix) fork processes and systemd's assumptions about how things
should work

but generally you can:

- move the code that does the work from the current cron job file to new-script
- the cron job should a) if  [ -d /run/systemd/system ]; then exit 0; else new-script;fi
- the timer should start a service that runs new-script, and then does a "sleep 10" to ensure exim can deliver the email before
  systemd kills the unit (see #1106030)
  (better workarounds welcomed)


the second step means cron is a no-op on systemd but will still operate for non-systemd

Here we are. I omited then to avoid debian-devel starting to discuss the requirement
instead of the solution...

1/ popcon need to have a minimal package footprint so that it does not twist the statistic
(hence it is written in sh and perl-base which are 'Essential: yes' so are
always installed anyway)

2/ it should work on Debian derivative that might not use systemd or use it differently.

3/ it should not break backward compatibility and user customization, so
   /etc/cron.daily/popularity-contest should still be run.

Specifically for the timer:
1/ the report need to be sent about once a week at some random time to minimize congestion
on the server side.

2/ if the host is not powered or not online at the time the report is to be
sent, sending the report need to be retried later, about one time per day.

This is done currently by the /etc/cron.daily/popularity-contest running every
day at some time determined randomly at installation time in
/etc/cron.d/popularity-contest.

Thanks for your interest.

Cheers,

Hello,

afaiui the important thing when interacting with a local exim is to
*not* submit mail from a systemd service via the /usr/sbin/sendmail
interface. This avoids having the exim and the respective service in the
same cgroup. Submitting by smtp should work avoid this.

(I do not think postfix has this problem, its sendmail writes a
file in the maildrop queue. Further processing happends by
pickup monitoring the maildrop queue and picking it up there, without
fork/exec.)

cu Andreas

Correct.

Hi,

We have however seen some posts in debian-user where people are confused
about why their service set up on a new release can no longer send
email, e.g. a monitoring service. When we have dug into it, it's been
because the service gained a systemd service unit with directives that
prevent writing to the postfix spool.

So there is some thought needed if adding protections to a service unit
that sends email, if it is to be run on a system with a setup like
Postfix.

Thanks,
Andy

postfix does have a different problem for systemd services that is worth
bearing in mind, though: the maildrop mechanism described above relies
on some component having privileges (setgid mail if I remember correctly).

This is fine for a simple, un-hardened systemd service, but if a service
has the NoNewPrivileges hardening option (or DynamicUser, which implies
NoNewPrivileges), then that service will be unable to send mail by
running postfix's sendmail program. See for example
https://bugs.debian.org/998242, which despite its title did affect both
exim and postfix.

     smcv

i think this is actually  fairly simple:  as you've already implemented
this in the cron script,  we just need to ensure systemd and cron can
coexist

my only questions are: 1..s there any way to test this  - i think there are
no tests in the package at all, but is there maybe some option i can pass
to output the report not actually send it?

and 2. how do i even build the package?

i did a git clone and "gbp buildpackage" and it failed with:

                     install -m 644 debian-popcon.gpg
debian/popularity-contest/usr/share/popularity-contest/
    install: cannot stat 'debian-popcon.gpg': No such file or directory


there's no .gpg file in the repository... what am i missing?

Sorry! What do you want to test ?

You can run /usr/sbin/popularity-contest manually.
You can change the day in /etc/popularity-contest.conf
and run /etc/cron.daily/popularity-contest
There is a log in /var/log/popularity-contest

The official debian-popcon.gpg file is the Debian source tarball.

Cheers,
Bill.

i just want to know what it's going to send, without actually sending any
mails to anyone.



i think you've lost me, sorry  - how does the official source tarball get
built?

In /etc/popularity-contest.conf set
MAILTO=""
USEHTTP="no"
There should still be a logfile at /var/log/popularity-contest

Cheers,
Bill.

I think the intention with the cron approach was:
a) at install time, $DAY is chosen randomly as a day of the week (date(1)'s %w)
b) always submit on $DAY
c) also submit if we ever notice it's been a week without a submission

I think there are some issues in the current code (and one cron daily
script could do both tasks), but hopefully i understood the idea

I've implemented a MODE=--systemd that does the same using a systend
timer, at https://salsa.debian.org/rpil2/popularity-contest/-/tree/systemd-timer?ref_type=heads
- Ive added autopkgtests to test the logic as i understand it, ie the
three bullets a, b, c above, i think this part is OK but im yet to
test whether systemd actually schedules things as expected: i dont
think it's quite ready to merge yet: there may be some edge cases i
missed -- but i think you could take a look at the new code (ie
debian/cron.daily) and see if it makes sense (and if the other changes
made sense).

while i was at it i modernised the packaging, and added the .gpg file
to git (please check this is right - i just copied it from a random
trixie system, but presumably you can verify the sha256sum etc) --
this fixes several lintian warnings (there are still issues with
encodings in po files).

Thanks for you effort!

There is an extra difficulty:

At install time, a file /etc/cron.d/popularity-contest is created with a
random time of day so that different systems reports at different time.
Unfortunately, we do not know whether the system will be up at that time,
so we also run the script via the normal /etc/cron.daily/popularity-contest
mechanism.

But likely you take this into account already

We need to deal with the case where the user do not accept the changes to
/etc/cron.daily/popularity-contest at upgrade time
("keep old version" in dpkg).

Also we should avoid systemd security setting that are incompatible with other
SMTP servers and also with tor.

Cheers,
Bill.