Bug 722341

Summary: Provide native systemd unit file
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: dbmailAssignee: Bernard Johnson <bjohnson>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: bjohnson, gwync, k.georgiou, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-20 14:29:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 713562, 751869    
Attachments:
Description Flags
Native systemd service file for dbmail-imapd
none
Native systemd service file for dbmail-lmtpd
none
Native systemd service file for dbmail-pop3d
none
Native systemd service file for dbmail-timsieved none

Description Jóhann B. Guðmundsson 2011-07-14 22:38:52 UTC
Description of problem:

https://fedoraproject.org/wiki/Features/SysVtoSystemd

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-07-14 22:40:36 UTC
Created attachment 513279 [details]
Native systemd service file for dbmail-imapd

Comment 2 Jóhann B. Guðmundsson 2011-07-14 22:41:32 UTC
Created attachment 513282 [details]
Native systemd service file for dbmail-lmtpd

Comment 3 Jóhann B. Guðmundsson 2011-07-14 22:42:22 UTC
Created attachment 513283 [details]
Native systemd service file for dbmail-pop3d

Comment 4 Jóhann B. Guðmundsson 2011-07-14 22:43:09 UTC
Created attachment 513284 [details]
Native systemd service file for dbmail-timsieved

Comment 5 Bernard Johnson 2011-07-14 22:44:37 UTC
All of these services depend on the database with the dbmail schema being available.  This can be Postgresql, Oracle, MySQL, or SQLite... How can that be accounted for?

Comment 6 Jóhann B. Guðmundsson 2011-07-14 22:47:42 UTC
Note these are untested so the Type= field might need tweaking as in you might
need to add

Type=forking
PIDFile=/path/to/pid 

Or

Type=oneshot
RemainAfterExit=yes


https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d

Comment 7 Jóhann B. Guðmundsson 2011-07-14 22:49:17 UTC
(In reply to comment #5)
> All of these services depend on the database with the dbmail schema being
> available.  This can be Postgresql, Oracle, MySQL, or SQLite... How can that be
> accounted for?


Hum not seeing anything obvious in the legacy sysv initscript.

How did the legacy sysv script handle that ?

Comment 8 Bernard Johnson 2011-07-19 14:11:17 UTC
You mean by settings the start/stop levels I assume?  This guaranteed that dbmail daemons would not start before for example mysqld in this case and mysqld would not shutdown before dbmail daemons.

$ grep chkconfig /etc/init.d/mysqld /etc/init.d/dbmail*
/etc/init.d/mysqld:# chkconfig: - 64 36
/etc/init.d/dbmail-imapd:# chkconfig: - 81 19
/etc/init.d/dbmail-lmtpd:# chkconfig: - 81 19
/etc/init.d/dbmail-pop3d:# chkconfig: - 81 19
/etc/init.d/dbmail-timsieved:# chkconfig: - 81 19
$

Comment 9 Jóhann B. Guðmundsson 2011-07-19 15:06:20 UTC
(In reply to comment #8)
> You mean by settings the start/stop levels I assume?  This guaranteed that
> dbmail daemons would not start before for example mysqld in this case and
> mysqld would not shutdown before dbmail daemons.
> 
> $ grep chkconfig /etc/init.d/mysqld /etc/init.d/dbmail*
> /etc/init.d/mysqld:# chkconfig: - 64 36
> /etc/init.d/dbmail-imapd:# chkconfig: - 81 19
> /etc/init.d/dbmail-lmtpd:# chkconfig: - 81 19
> /etc/init.d/dbmail-pop3d:# chkconfig: - 81 19
> /etc/init.d/dbmail-timsieved:# chkconfig: - 81 19
> $

You will need to add what ever dbmail needs to after or before in the after line ( or in a Before= line ) so if we continue with the mysqld you would add mysqld.service in the After= line as in After=syslog.target network.target mysqld.service

That would start dbmail-* after mysqld got started and stopped before mysqld would be stopped.

Comment 10 Bernard Johnson 2011-07-20 17:41:55 UTC
So what I hear you saying is that there is no systemd equivalent?

You can't reasonably expect that I would automatically start multiple databases because dbmail *might* be configured for one of them (or neither).

Or perhaps, I don't understand...

What if I put:

After=syslog.target network.target mysqld.service postgresql.service


What is for example postgresql is not installed?  Will this be an error, or will systemd handle it gracefully?

Comment 11 Jóhann B. Guðmundsson 2011-07-20 21:27:54 UTC
(In reply to comment #10)
> So what I hear you saying is that there is no systemd equivalent?

The equallent is After=, Before ordering 

> You can't reasonably expect that I would automatically start multiple databases
> because dbmail *might* be configured for one of them (or neither).

You wont start anything with Before= or After=

> Or perhaps, I don't understand...
> 
> What if I put:
> 
> After=syslog.target network.target mysqld.service postgresql.service
> 
> 
> What is for example postgresql is not installed?  Will this be an error, or
> will systemd handle it gracefully?

Systemd will handle that gracefully with After= and Before= you are telling systemd to not start dbmail-* until After=postgresql.service mysqld.service or visa versa start it Before=$foo.service is started.

Comment 12 Jóhann B. Guðmundsson 2011-12-26 11:44:17 UTC
Ping what's the current status on this?

Comment 13 Gwyn Ciesla 2012-04-19 20:05:19 UTC
Any objection to my making this change?  Without the database lines, since they might be remote?

Comment 14 Bernard Johnson 2012-04-20 00:58:27 UTC
(In reply to comment #13)
> Any objection to my making this change?  Without the database lines, since they
> might be remote?

Any help would be greatly appreciated due to my very limited time right now.  I would like to see the database dependency resolved though.  Startup could check the /etc/dbmail.conf file and determine if a database daemon is being used (driver != ) and if it's located remotely or not (host = localhost, $(hostname)).

I guess now that I think about it, this applies to ldap as well if being used.

Comment 15 Bernard Johnson 2012-04-20 01:08:11 UTC
!= sqlite

Comment 16 Gwyn Ciesla 2012-04-20 14:29:08 UTC
After= does what you want.  Done.