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:
Created attachment 513279 [details] Native systemd service file for dbmail-imapd
Created attachment 513282 [details] Native systemd service file for dbmail-lmtpd
Created attachment 513283 [details] Native systemd service file for dbmail-pop3d
Created attachment 513284 [details] Native systemd service file for dbmail-timsieved
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?
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
(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 ?
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 $
(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.
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?
(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.
Ping what's the current status on this?
Any objection to my making this change? Without the database lines, since they might be remote?
(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.
!= sqlite
After= does what you want. Done.