Bug 697636 - Providing native systemd file for upcoming F15 Feature Systemd
Summary: Providing native systemd file for upcoming F15 Feature Systemd
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: sendmail
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2011-04-18 19:34 UTC by Jóhann B. Guðmundsson
Modified: 2017-04-12 02:57 UTC (History)
4 users (show)

Fixed In Version: sendmail-8.14.5-3.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-14 09:10:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Native systemd service file for sendmail (338 bytes, text/plain)
2011-04-18 19:34 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for sm-client (309 bytes, text/plain)
2011-04-18 19:35 UTC, Jóhann B. Guðmundsson
no flags Details
New /etc/sysconfig/sendmail (26 bytes, text/plain)
2011-04-18 19:39 UTC, Jóhann B. Guðmundsson
no flags Details
Minor updates to sm-client.service (285 bytes, text/plain)
2011-06-30 09:36 UTC, Jóhann B. Guðmundsson
no flags Details
Minor updates to sendmail.service (316 bytes, text/plain)
2011-06-30 09:37 UTC, Jóhann B. Guðmundsson
no flags Details
Patch that Introduce systemd unit file, drop SysV support to the spec file.. (2.38 KB, patch)
2011-06-30 10:15 UTC, Jóhann B. Guðmundsson
no flags Details | Diff
New sendmail.service (380 bytes, text/plain)
2011-07-11 14:57 UTC, Jóhann B. Guðmundsson
no flags Details
New sendmail.service (384 bytes, application/octet-stream)
2011-07-12 10:20 UTC, Jaroslav Škarvada
no flags Details
Patch that Introduce systemd unit file, drop SysV support to the spec file.. (4.78 KB, patch)
2011-07-12 10:26 UTC, Jaroslav Škarvada
no flags Details | Diff
Patch that Introduce systemd unit file, drop SysV support to the spec file.. (5.52 KB, patch)
2011-07-14 08:57 UTC, Jaroslav Škarvada
no flags Details | Diff
New sendmail.service (423 bytes, patch)
2011-07-14 08:58 UTC, Jaroslav Škarvada
no flags Details | Diff
New sendmail.service (465 bytes, text/plain)
2011-07-18 15:04 UTC, Jaroslav Škarvada
no flags Details
Minor updates to sm-client.service (476 bytes, text/plain)
2011-07-18 15:06 UTC, Jaroslav Škarvada
no flags Details

Description Jóhann B. Guðmundsson 2011-04-18 19:34:35 UTC
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:

Comment 1 Jóhann B. Guðmundsson 2011-04-18 19:35:54 UTC
Created attachment 492991 [details]
Native systemd service file for sm-client

Comment 2 Jóhann B. Guðmundsson 2011-04-18 19:39:34 UTC
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.

Comment 3 Bill Nottingham 2011-04-26 17:35:42 UTC
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

Comment 4 Jóhann B. Guðmundsson 2011-06-24 17:48:11 UTC
Ping?

Comment 5 Jaroslav Škarvada 2011-06-25 09:31:54 UTC
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.

Comment 6 Jóhann B. Guðmundsson 2011-06-25 10:41:25 UTC
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.

Comment 7 Jóhann B. Guðmundsson 2011-06-30 09:36:34 UTC
Created attachment 510617 [details]
Minor updates to sm-client.service

Comment 8 Jóhann B. Guðmundsson 2011-06-30 09:37:28 UTC
Created attachment 510618 [details]
Minor updates to sendmail.service

Comment 9 Jóhann B. Guðmundsson 2011-06-30 10:15:45 UTC
Created attachment 510628 [details]
Patch that Introduce systemd unit file, drop SysV support to the spec file..

Comment 10 Jóhann B. Guðmundsson 2011-07-11 13:46:39 UTC
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.

Comment 11 Jaroslav Škarvada 2011-07-11 13:58:39 UTC
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?

Comment 12 Jóhann B. Guðmundsson 2011-07-11 14:57:52 UTC
Created attachment 512230 [details]
New sendmail.service

Add the missing updateconf section before we start the service

Comment 13 Jóhann B. Guðmundsson 2011-07-11 15:10:45 UTC
(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 )

Comment 14 Jaroslav Škarvada 2011-07-11 15:25:53 UTC
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.

Comment 15 Jaroslav Škarvada 2011-07-12 10:20:45 UTC
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.

Comment 16 Jaroslav Škarvada 2011-07-12 10:26:05 UTC
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

Comment 17 Jaroslav Škarvada 2011-07-12 12:18:43 UTC
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.

Comment 18 Jóhann B. Guðmundsson 2011-07-12 12:55:27 UTC
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?

Comment 19 Jóhann B. Guðmundsson 2011-07-12 12:57:46 UTC
If you comment out the trigger run section does the error still appear?

Comment 20 Jaroslav Škarvada 2011-07-12 13:24:17 UTC
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.

Comment 21 Jaroslav Škarvada 2011-07-12 13:44:49 UTC
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.

Comment 22 Jaroslav Škarvada 2011-07-12 13:50:36 UTC
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, ...

Comment 23 Jaroslav Škarvada 2011-07-12 16:38:15 UTC
Any idea how to handle this? And what to use as replacement for alternatives? AFAIK the alternatives are part of chkconfig package.

Comment 24 Jóhann B. Guðmundsson 2011-07-12 17:26:15 UTC
%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

Comment 25 Jóhann B. Guðmundsson 2011-07-12 17:31:13 UTC
There is a bug open about the alternatives + --initscript #714830 so I guess remove it ?

Comment 26 Jaroslav Škarvada 2011-07-13 08:44:29 UTC
(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.

Comment 27 Jóhann B. Guðmundsson 2011-07-13 09:38:53 UTC
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.

Comment 28 Jaroslav Škarvada 2011-07-13 10:10:15 UTC
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.

Comment 29 Jaroslav Škarvada 2011-07-14 08:57:10 UTC
Created attachment 512832 [details]
Patch that Introduce systemd unit file, drop SysV support to the spec file..

Comment 30 Jaroslav Škarvada 2011-07-14 08:58:19 UTC
Created attachment 512834 [details]
New sendmail.service

Added conflicts

Comment 31 Paul Howarth 2011-07-15 08:11:57 UTC
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.

Comment 32 Jóhann B. Guðmundsson 2011-07-15 10:03:41 UTC
Please file a new bug for this we want to keep this tracker bug closed thanks

Comment 33 Jaroslav Škarvada 2011-07-18 09:12:41 UTC
Paul thanks for your suggestions. I will push it.

Comment 34 Jaroslav Škarvada 2011-07-18 12:24:48 UTC
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

Comment 35 Jóhann B. Guðmundsson 2011-07-18 12:36:48 UTC
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 ?

Comment 36 Paul Howarth 2011-07-18 12:42:42 UTC
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,

Comment 37 Paul Howarth 2011-07-18 12:49:38 UTC
(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.

Comment 38 Jaroslav Škarvada 2011-07-18 12:55:25 UTC
(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.

Comment 39 Jaroslav Škarvada 2011-07-18 12:58:32 UTC
(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.

Comment 40 Jóhann B. Guðmundsson 2011-07-18 13:36:30 UTC
(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.

Comment 41 Paul Howarth 2011-07-18 13:36:49 UTC
> 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.

Comment 42 Jóhann B. Guðmundsson 2011-07-18 14:11:44 UTC
You dont need want if you have BindTo ...

Comment 43 Jóhann B. Guðmundsson 2011-07-18 14:15:19 UTC
(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

Comment 44 Paul Howarth 2011-07-18 14:22:18 UTC
(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.

Comment 45 Jóhann B. Guðmundsson 2011-07-18 14:40:44 UTC
(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 )

Comment 46 Jaroslav Škarvada 2011-07-18 14:50:08 UTC
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.

Comment 47 Jaroslav Škarvada 2011-07-18 15:04:53 UTC
Created attachment 513629 [details]
New sendmail.service

Type=forking and Wants sm-client.service

Comment 48 Jaroslav Škarvada 2011-07-18 15:06:34 UTC
Created attachment 513630 [details]
Minor updates to sm-client.service

Type=forking, fix for PID creation and Wants sendmail.service


Note You need to log in before you can comment on or make changes to this bug.