Bugzilla – Bug 1115430
[TRACKERBUG-OPENSUSE] FATE#323635: Reduce usage of cron in favour of systemd timers
Last modified: 2021-07-07 13:50:56 UTC
This is a tracker bug for fate#323635 (Reduce usage of cron package in favor of systemd timers). It tracks openSUSE packages only (for SLE packages see bug#1115399).
The goal is to minimize the number of openSUSE:Factory packages that use cron in favour of systemd timers. See dependent bugs for more information about particular packages that should be migrated.
Is it possible to give some pointers to packagers how systemd timers should look like in openSUSE?
I've spent a few minutes searching the wiki if there is dedicated information on it but haven't found anything.
openSUSE:Systemd packaging guidelines does not have anything on timers.
Could easily be that I missed it but I think this tracking bug is a good place to indicate some pointers packagers could use if they have not been in touch with systemd-timers much.
Thanks for bringing this idea. I've created a systemd timers section at opensuse wiki . It covers the basic packaging schema. I suppose that it can happen that each package can need a little bit different approach as the purpose of the former cron entry can be various.
So anybody can enhance this wiki page when he/she encounters a situation that can be interesting for other packagers dealing with the cron->timers migration.
Disclaimer: I personally have no strong objections against systemd in general. Thus I don't want to open yet another systemd discussion.
But my concern for this particular case is that systemd is not started in containers while it would be possible to start cronie in a container.
Were there any considerations about this?
Maybe I'm overlooking something but e.g. accepting this request would make unbound unusable in a docker container:
But especially a DNS recursor is something you likely want to run in a elastic container deployment.
(In reply to Michael Ströder from comment #3)
> But my concern for this particular case is that systemd is not started in
> containers while it would be possible to start cronie in a container.
I'm not a container expert so this is probably a question for Flavio.
@Flavio: Can you please help here? Thanks!
It is true that running systemd inside of an **application** container (like one started by Docker) is tricky. However this isn't something really needed on a daily basis. Application containers have a completely different use case from system containers (like the ones created by LXC and LXD).
Because of that I would find really really wrong to have someone running cron jobs inside of application containers.
I think you don't have to worry about containers (neither application, nor system) in this discussion.
Disclaimer: I'm not a container expert.
(In reply to Flavio Castelli from comment #5)
> It is true that running systemd inside of an **application** container (like
> one started by Docker) is tricky.
AFAIK it is not recommended to modify a container setup to allow running systemd because of some security implications. Thus there won't be systemd available in normal container setups.
> However this isn't something really needed
> on a daily basis. Application containers have a completely different use
> case from system containers (like the ones created by LXC and LXD).
> Because of that I would find really really wrong to have someone running
> cron jobs inside of application containers.
Frankly I don't understand your answer.
Personally I think that running a DNS resolver like unbound in a Docker container on e.g. an elastic Kubernetes cluster is something users definitely want. Thus requiring systemd for installing and using unbound package is a real obstacle for such a setup.
> I think you don't have to worry about containers (neither application, nor
> system) in this discussion.
I strongly disagree.
General info for packagers dealing with the migration: Please see  for more information about enabling timers and mainly how to pick the correct preset package where to put your timer (systemd-presets-common-SUSE or systemd-presets-branding-openSUSE).
openSUSE will systemd.timers.
But will the user systemd.timers too?
I think not.
So we should offer both ways, so that the user can self decide what he/she want use.