Red Hat Bugzilla – Bug 719371
Provide native systemd unit file
Last modified: 2011-07-14 05:37:39 EDT
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 511522 [details]
Native systemd service file mailman
Note that the cronjob part should be in the rpm package and happen at install time if you need valid sysadmin arguements it's simple you would not install mailman if you had not intention of running it and if the cron job bothers you then uninstall mailman...
Created attachment 511679 [details]
I've tested and slightly improved provided unit file:
- added Type=forking
- added reload command
- redirected stderr to syslog (optional, but nice)
With above changes mailman correctly starts, stops and reacts to reload. You still have to install cron job from RPM, like it was done before.
Thanks for your job, I will test it and if it will work correctly for me too, I will commit it.
Well, I don't think the cronjob should be active when mailman is stopped. Mailman can be installed and stopped and admin should not for example receive emails from it when it's stopped. That would be unexpected behaviour.
You're right that it's logical to have mailman installed in order to use it, but since there's a way to have it installed but turned off, we have to fully support it.
Do you need update the cron job then as in first check if mailman is running then do $foo if not then do nothing ?
Well, I've changed my new mailman.service and it works as expected for me. Attaching it here.
Created attachment 512628 [details]
service with cron support
Maybe create second unit, mailman-cron-control, with
Description=Mailman cron job
ExecStart=/usr/bin/install -m644 -o root -g root /usr/lib/mailman/cron/crontab.in /etc/cron.d/mailman
ExecStop=/bin/sh -c 'echo -e "# DO NOT EDIT THIS FILE!\n#\n# Contents of this file managed by /lib/systemd/system/mailman-cron-control.service\n# Master copy is /usr/lib/mailman/cron/crontab.in" > /etc/cron.d/mailman
And then, in mailman.service use Requires=mailman-cron-control.service in [Unit] and Also=mailman-cron-control.service in [Install].
Those are defined in systemd.unit man page, but I'm not sure if I got BindTo= correctly.
I'm still on the view that this should not be done by the unit file and
replaced with something like this on top of my head
Crontab file would call
0 8 * * * mailman /usr/lib/mailman/cron/checkdbs.sh
checkdbs.sh would look something like..
if [ -s /var/run/mailman.pid ];
Anyway let's just package what Jan had the rest can be fixed later via update
(In reply to comment #8)
> Maybe create second unit, mailman-cron-control, with
> Description=Mailman cron job
> ExecStart=/usr/bin/install -m644 -o root -g root
> /usr/lib/mailman/cron/crontab.in /etc/cron.d/mailman
> ExecStop=/bin/sh -c 'echo -e "# DO NOT EDIT THIS FILE!\n#\n# Contents of this
> file managed by /lib/systemd/system/mailman-cron-control.service\n# Master copy
> is /usr/lib/mailman/cron/crontab.in" > /etc/cron.d/mailman
> And then, in mailman.service use Requires=mailman-cron-control.service in
> [Unit] and Also=mailman-cron-control.service in [Install].
> Those are defined in systemd.unit man page, but I'm not sure if I got BindTo=
I can, but are there any benefits? I could do the same with "/usr/bin/mailman-update-cfg" and call it mailman-config-control.
(In reply to comment #9)
> I'm still on the view that this should not be done by the unit file and
> replaced with something like this on top of my head
> Crontab file would call
> 0 8 * * * mailman /usr/lib/mailman/cron/checkdbs.sh
> checkdbs.sh would look something like..
> if [ -s /var/run/mailman.pid ];
> exit 1
> exit 0
> Anyway let's just package what Jan had the rest can be fixed later via update
I'm not against something like that probably, but we would have to change it in all scripts or write one wrapper script and call it with the original scripts are arguments.
Created attachment 512638 [details]
This is mailman.spec patch which works for me and which I'm going to commit. If you see something bad there, please tell me.
Well, I've committed those changes into rawhide. Closing this bug to not block SysVtoSystemd. Fill another one for to further changes.