Created attachment 492990 [details] Native systemd service file for sendmail Description of problem: The attached file is a native systemd file for upcoming F15 Feature [1] Please read [2] on how to packaging and installing systemd Service files. To learn more about Systemd daemon see [3]. To view old SysV with the new Systemd site by site see for your component see [4] If you have any question dont hesitate to ask them on this bug report. 1.http://fedoraproject.org/wiki/Features/systemd 2.https://fedoraproject.org/wiki/Systemd_Packaging_Draft 3.http://0pointer.de/public/systemd-man/daemon.html 4.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 492991 [details] Native systemd service file for sm-client
Created attachment 492992 [details] New /etc/sysconfig/sendmail No need to be doing somekind of checks if end users need to change the content of an variable in /etc/sysconfig/sendmail so let's just let that user conigure the variable there for the daemon as it should be.
Moving systemd service RFEs to rawhide. At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades. We therefore request: - wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes. - work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release. - do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy
Ping?
Jóhann thanks. It is now F16 feature, so it is not urgent at the moment: http://fedoraproject.org/wiki/Features/SysVtoSystemd I will look on this, probably during next week.
Just so you know we need this in before alpha so it wont block the alpha release and dont forget to split the old sysv init script into a seperate subpackage as stated by the packaging guidelines http://fedoraproject.org/wiki/Packaging:Systemd that is if you have any intention of continueing to support and maintain it.
Created attachment 510617 [details] Minor updates to sm-client.service
Created attachment 510618 [details] Minor updates to sendmail.service
Created attachment 510628 [details] Patch that Introduce systemd unit file, drop SysV support to the spec file..
A week has passed any updates? We probably can find a proven packager to assist you in packaging these files if you dont have time yourself.
Jóhann thanks. Mostly looks good, but: What about the auto updateconf function as was in original init script called on start? And why do you change the format of /etc/sysconfig/sendmail? Looks like no more than problems here. If it is needed to change, why not to use simply something like OPTS variable?
Created attachment 512230 [details] New sendmail.service Add the missing updateconf section before we start the service
(In reply to comment #11) > Jóhann thanks. Mostly looks good, but: > > What about the auto updateconf function as was in original init script called > on start? Added the missing update section note that you probably will have to have sendmail-cf installed unless you add "-" before the make commands as in ExecStartPre=-/etc/mail/make ExecStartPre=-/etc/mail/make aliases And ExecReload=-/etc/mail/make ExecReload=-/etc/mail/make aliases Otherwize the service will fail to start > And why do you change the format of /etc/sysconfig/sendmail? Looks like no more > than problems here. If it is needed to change, why not to use simply something > like OPTS variable? Unfortunately I was to dumb to save the original sysconfig file before editing it any who you can add $OPTS and OPTS="-bd -q1h" remove $DAEMON $QUEUE and start the daemon with ExecStart=/usr/sbin/sendmail $OPTS if you prefer I only tried to map 1:1 behaviour to the native systemd service script. You could even just start the daemon with those variables in place and update docs pointing admins to # cp /lib/systemd/system/sendmail.service /etc/systemd/system/ # vim /etc/systemd/system/sendmail.service ( make changes ) run # systemctl daemon-reload ( reload the systemd daemon to pick up those changes ) # systemctl start sendmail.service ( since systemd takes precedence over native systemd unit files in /etc/systemd/system )
Thanks, I will give it another check and perform some more testing and if all OK I will integrate it. Please give me approx. one day for this.
Created attachment 512387 [details] New sendmail.service Continue with old configs if sendmail-cf is not installed and configs needs updating instead of fail, same change as suggested in comment 13. Sad that user is not warned as with old initscript.
Created attachment 512389 [details] Patch that Introduce systemd unit file, drop SysV support to the spec file.. Updated triggerun to count with sendmail-8.13.5-2
Spotted one more problem, reproducer: # rpm -q sendmail sendmail-8.14.5-2.fc16.x86_64 # yum remove sendmail ... # yum install sendmail ... Running Transaction Installing : sendmail-8.14.5-3.fc16.x86_64 1/1 error reading information on service sendmail: No such file or directory Installed: sendmail.x86_64 0:8.14.5-3.fc16 # systemctl is-enabled sendmail.service # echo $? 1 It should be 0.
Hum.. If we remove sendmail and reinstall it the old legacy sysv init script no longer exist thus when chkconfig is run it will fail right?
If you comment out the trigger run section does the error still appear?
My guess is: alternatives .... --initscript sendmail It is there to enable the service in case it is installed the first time. I am not sure if this functionality is now handled with systemd. Let me check it.
Correct. No change after removing the trigger - because it shouldn't run - there is no sendmail installed. But when removed the --initscript option the error disappeared, but the sendmail service is still not enabled as it should be.
The whole alternatives thing should be taken into account. E.g. we need to enable/disable services on user switch of alternatives. It should be synced with the other MTAs - postfix, exim, ...
Any idea how to handle this? And what to use as replacement for alternatives? AFAIK the alternatives are part of chkconfig package.
%post if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable sendmail.service >/dev/null 2>&1 || : fi Will enabled the native systemd unit as mentioned per guidelines which I actually never posted here ;) https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
There is a bug open about the alternatives + --initscript #714830 so I guess remove it ?
(In reply to comment #25) > There is a bug open about the alternatives + --initscript #714830 so I guess > remove it ? Well, now this is probably the only possible solution. But it is not good. Consider the following situation: 1) The user selected the postfix as his default MTA. 2) The user removed sendmail. 3) The user reinstalled later the systemd capable sendmail. He will end up with both MTAs enabled, which is not good. This will be probably the same in vice versa, e.g. installing postfix or exim as another MTA. This should be noted in docs.
Would not adding conflicts take care of that?* As in if we add to the unit.. Conflicts=postfix.service exim.service etc.. Conflicts= Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies. If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required part of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case the job that is not the required will be removed, or in case both are not required the unit that conflicts will be started and the unit that is conflicted is stopped.
I will check this. It doesn't solve the problem, but the systemd errors (or preference of one MTA) seems more clear to me than the "Unable to bind" errors. Conclusion: If user installs secondary (or another) MTA, she/he not only needs to select the preferred MTA via alternatives. She/he will now also need to manually disable (via systemctl) all other unneeded MTAs and enable the preferred one. We can return to the previous functionality when the bug #714830 will be resolved.
Created attachment 512832 [details] Patch that Introduce systemd unit file, drop SysV support to the spec file..
Created attachment 512834 [details] New sendmail.service Added conflicts
systemd seems to get confused about which sendmail daemon belongs to the main service and which is the client, so I suggest adding PIDFile entries. Here's what I'm using at the moment: # more /lib/systemd/system/{sendmail,sm-client}.service :::::::::::::: /lib/systemd/system/sendmail.service :::::::::::::: [Unit] Description=Sendmail Mail Transport Agent After=syslog.target network.target Conflicts=postfix.service exim.service [Service] Type=forking PIDFile=/run/sendmail.pid EnvironmentFile=-/etc/sysconfig/sendmail ExecStartPre=-/etc/mail/make ExecStartPre=-/etc/mail/make aliases ExecStart=/usr/sbin/sendmail $DAEMON $QUEUE $SENDMAIL_OPTARG ExecReload=-/etc/mail/make ExecReload=-/etc/mail/make aliases [Install] WantedBy=multi-user.target :::::::::::::: /lib/systemd/system/sm-client.service :::::::::::::: [Unit] Description=Sendmail Mail Transport Client After=syslog.target network.target sendmail.service [Service] Type=forking PIDFile=/run/sm-client.pid EnvironmentFile=-/etc/sysconfig/sendmail ExecStart=/usr/sbin/sendmail -L sm-msp-queue -Ac $QUEUE $SENDMAIL_OPTARG [Install] WantedBy=multi-user.target None of the other services end their "Description" entries with a dot/period so I dropped those too. One other thing is that maybe sendmail.service should Require sm-client.service (and maybe vice-versa) so that they get enable/disabled together. Otherwise I think upgrades may end up with the client disabled.
Please file a new bug for this we want to keep this tracker bug closed thanks
Paul thanks for your suggestions. I will push it.
Fixed creation of sm-client.pid and bound enable/disable together: --- sm-client.service.old 2011-07-18 14:06:43.320584502 +0200 +++ sm-client.service 2011-07-18 14:03:49.000000000 +0200 @@ -6,6 +6,9 @@ Type=forking PIDFile=/run/sm-client.pid EnvironmentFile=-/etc/sysconfig/sendmail +ExecStartPre=/bin/touch /run/sm-client.pid +ExecStartPre=/bin/chown smmsp:smmsp /var/run/sm-client.pid +ExecStartPre=-/sbin/restorecon /var/run/sm-client.pid ExecStart=/usr/sbin/sendmail -L sm-msp-queue -Ac $QUEUE $SENDMAIL_OPTARG [Install] WantedBy=multi-user.target +Also=sendmail.service --- sendmail.service.old 2011-07-18 14:20:57.730323695 +0200 +++ sendmail.service 2011-07-18 14:20:20.130511695 +0200 @@ -15,3 +15,4 @@ [Install] WantedBy=multi-user.target +Also=sm-client.service
Hum is this really necessary? +ExecStartPre=/bin/touch /run/sm-client.pid +ExecStartPre=/bin/chown smmsp:smmsp /var/run/sm-client.pid +ExecStartPre=-/sbin/restorecon /var/run/sm-client.pid Is it not better to add User=smmsp Group=smmp To that unit and skip those lines? And makes this really any sense to have in the sendmail unit ? +Also=sm-client.service And is it not better to add BindTo=sendmail.service to the sm-client unit instead of +Also=sendmail.service ?
I don't think there's any point using /var/run when it's just a symlink to /run and /var/run will eventually disappear altogether,
(In reply to comment #35) > Hum is this really necessary? > > +ExecStartPre=/bin/touch /run/sm-client.pid > +ExecStartPre=/bin/chown smmsp:smmsp /var/run/sm-client.pid > +ExecStartPre=-/sbin/restorecon /var/run/sm-client.pid > > Is it not better to add > > User=smmsp > Group=smmsp > > To that unit and skip those lines? If the daemon was running as smmsp, it wouldn't have permission to create /run/sm-client.pid, which is why these are needed. > And makes this really any sense to have in the sendmail unit ? > > +Also=sm-client.service Yes, the two daemons need each other. The client needs the main service to deliver mail. The client service is always needed for message submission so that it can retry sending queued mail if submission failed the first time for whatever reason. If the two weren't started together, lots of admins would be quite likely to forget to start the client daemon and might not even notice the intermittently non-delivered (because it's only queued) local mail.
(In reply to comment #35) > Hum is this really necessary? > > +ExecStartPre=/bin/touch /run/sm-client.pid > +ExecStartPre=/bin/chown smmsp:smmsp /var/run/sm-client.pid > +ExecStartPre=-/sbin/restorecon /var/run/sm-client.pid > > Is it not better to add > > User=smmsp > Group=smmp > > To that unit and skip those lines? > This doesn't work, it does not create /run/sm-client.pid: # tail /var/log/maillog Jul 18 14:48:19 localhost sm-msp-queue[5582]: unable to write pid to /var/run/sm -client.pid: Permission denied > And makes this really any sense to have in the sendmail unit ? > > +Also=sm-client.service > > > And is it not better to add BindTo=sendmail.service to the sm-client unit > instead of +Also=sendmail.service ? > This causes deadlocks: # systemctl restart sendmail.service [deadlock] # systemctl list-jobs JOB UNIT TYPE STATE 1306 sendmail.service restart waiting 1307 sm-client.service start waiting 2 jobs listed.
(In reply to comment #36) > I don't think there's any point using /var/run when it's just a symlink to /run > and /var/run will eventually disappear altogether, It is not implemented by symlink, but good point. We need to change the mc/cf files also.
(In reply to comment #38) > (In reply to comment #35) > > And is it not better to add BindTo=sendmail.service to the sm-client unit > > instead of +Also=sendmail.service ? > > > This causes deadlocks: > # systemctl restart sendmail.service > [deadlock] > # systemctl list-jobs > JOB UNIT TYPE STATE > 1306 sendmail.service restart waiting > 1307 sm-client.service start waiting > > 2 jobs listed. Hum this actually might be a bug because if I bind sendmail to sm-client and sm-client to sendmail then start/stop either of them the other one is brought down cleanly with it however if I restart either one of them they deadlock as you mention.
> The client needs the main service to deliver mail. > > The client service is always needed for message submission so that it can retry > sending queued mail if submission failed the first time for whatever reason. > > If the two weren't started together, lots of admins would be quite likely to > forget to start the client daemon and might not even notice the intermittently > non-delivered (because it's only queued) local mail. And as such, I think they need to "Want" each other in their "[Unit]" sections so that they start together as well as being enabled together.
You dont need want if you have BindTo ...
(In reply to comment #38) > (In reply to comment #35) > > Hum is this really necessary? > > > > +ExecStartPre=/bin/touch /run/sm-client.pid > > +ExecStartPre=/bin/chown smmsp:smmsp /var/run/sm-client.pid > > +ExecStartPre=-/sbin/restorecon /var/run/sm-client.pid > > > > Is it not better to add > > > > User=smmsp > > Group=smmp > > > > To that unit and skip those lines? > > > This doesn't work, it does not create /run/sm-client.pid: > # tail /var/log/maillog > Jul 18 14:48:19 localhost sm-msp-queue[5582]: unable to write pid to > /var/run/sm > -client.pid: Permission denied > > > And makes this really any sense to have in the sendmail unit ? > > > > +Also=sm-client.service > > > > > > And is it not better to add BindTo=sendmail.service to the sm-client unit > > instead of +Also=sendmail.service ? > > > This causes deadlocks: > # systemctl restart sendmail.service > [deadlock] > # systemctl list-jobs > JOB UNIT TYPE STATE > 1306 sendmail.service restart waiting > 1307 sm-client.service start waiting > > 2 jobs listed. Unfortunetly I'm unable to duplicate this with simple test units.. testA.service [Unit] Description=BindTo Restart Test BindTo=testB.service Before=testB.service [Service] Type=oneshot ExecStart=/bin/sleep 5 RemainAfterExit=yes testB.service [Unit] Description=BindTo Restart Test BindTo=testA.service After=testA.service [Service] Type=oneshot ExecStart=/bin/sleep 5 RemainAfterExit=yes Start/Stops/Restart cleanly
(In reply to comment #42) > You dont need want if you have BindTo ... I think Wants is more appropriate really. With BindTo, stopping/restarting one of the services should do the same to the other, but that's not always what's wanted here. For instance, if the main sendmail configuration has been tweaked, you'd want to restart that but not necessarily the client, which has a separate configuration file.
(In reply to comment #44) > (In reply to comment #42) > > You dont need want if you have BindTo ... > > I think Wants is more appropriate really. With BindTo, stopping/restarting one > of the services should do the same to the other, but that's not always what's > wanted here. For instance, if the main sendmail configuration has been tweaked, > you'd want to restart that but not necessarily the client, which has a separate > configuration file. Which is why I asked if this was always the case as in if sendmail is started then sm-client would be started and if sendmail would be stopped then sm-client would be too Anyway both BindTo= and Requires= trigger the "deadlock" since both of them bring down sm-client with them when started/stopped Wants= will not take down the sm-client daemon if sendmail.service is stopped ( thus restart works )
Paul thanks. "Wants" makes sense to me. I will add it to both services. And I will also change all occurrences of /var/run to /run in all configs and unit files.
Created attachment 513629 [details] New sendmail.service Type=forking and Wants sm-client.service
Created attachment 513630 [details] Minor updates to sm-client.service Type=forking, fix for PID creation and Wants sendmail.service