|Summary:||Provide native systemd service|
|Product:||[Fedora] Fedora||Reporter:||Jóhann B. Guðmundsson <johannbg>|
|Component:||mimedefang||Assignee:||Robert Scheck <redhat-bugzilla>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||dfs, gwync, mstevens, redhat-bugzilla|
|Fixed In Version:||mimedefang-2.78-5.fc24||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-01-04 20:59:57 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jóhann B. Guðmundsson 2012-02-12 22:10:53 UTC
Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd 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 2012-02-12 22:12:24 UTC
So looking at the legacy sysv init script it looks like this daemon desperately needs the ability to parse config file so it's a question if you dont want to contact upstream and see what they have to say about adding that ability to the daemon.
Comment 2 Gwyn Ciesla 2012-05-15 13:07:48 UTC
Robert, any objection to my taking a look at this an migrating it if I can?
Comment 3 Robert Scheck 2012-05-15 13:28:46 UTC
Jon, have a look to it, if you want. But please avoid breaking it ;-) However it would be trivial as Jóhann already mentioned.
Comment 4 Fedora End Of Life 2013-04-03 17:14:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 5 Morten Stevens 2013-09-10 14:34:05 UTC
mimedefang has still no systemd unit file, any news about that?
Comment 6 Jóhann B. Guðmundsson 2013-09-10 14:42:43 UTC
What did upstream say?
Comment 7 Morten Stevens 2014-05-25 15:40:51 UTC
@Robert: Any news? MIMEdefang 2.75 has also no systemd unit file...
Comment 8 Jóhann B. Guðmundsson 2014-05-26 09:42:25 UTC
Given that I have left the project and a new individual may or may not continue with systemd integration in the project by submitting new feature following whatever demands FPC and FESCo might have and thus new units in the process I'm closing this and all remaining bugs I had submitted for this particular feature as WONTFIX
Comment 9 Robert Scheck 2014-08-02 17:39:45 UTC
(In reply to Morten Stevens from comment #7) > @Robert: Any news? MIMEdefang 2.75 has also no systemd unit file... I thought asked upstream already before, but couldn't find any old mail. Thus I definately did this now, you are Cc: at this e-mail. Even Jóhann left the project I would like to get this solved, reopening.
Comment 10 DIanne Skoll 2014-08-06 15:40:54 UTC
(Upstream MIMEDefang author here...) I received an email from Robert Scheck. Below is my reply for the record. I will gratefully accept systemd wrappers from anyone familiar with systemd. I really do *not* want to make mimedefang or mimedefang-multiplexor have to parse a configuration file. Regards, David. ====================================================================== Hi, Robert, > you might receive this request again (because I thought I wrote it > already before but can't find any e-mail): MIMEDefang and systemd - > do you have any plans at upstream regarding that? I have vague plans, but nothing concrete. There are two problems: 1) MIMEDefang configuration is mostly done by command-line parameters, so yes... this will require a wrapper. 2) I do not run Red Hat or Fedora, and my preferred distro (Debian) still has not moved to systemd for the stable release. However, I do recognize that systemd is the way of the future. I really do NOT want to have to make mimedefang and mimedefang-multiplexor parse a configuration file; I'd like to keep everything in the command-line arguments. I will look at making a wrapper. I assume a shell script that sets the proper command-line arguments and then invokes the program using "exec" to avoid a fork will keep systemd happy? Both mimedefang and mimedefang-multiplexor have a command-line argument to avoid becoming a daemon, which (I think?) is useful for systemd to keep control of the process. Regards, David.
Comment 11 Jan Kurik 2015-07-15 15:11:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 12 Robert Scheck 2015-10-29 14:30:39 UTC
Based on discussions on the IRC, the icecream package provides a wrapper: http://pkgs.fedoraproject.org/cgit/icecream.git/tree/icecc-scheduler-wrapper
Comment 13 Robert Scheck 2016-01-04 20:59:57 UTC
My recent commit http://pkgs.fedoraproject.org/cgit/mimedefang.git/commit /?id=ff19808a40a279de8d65e4d297fff9f800a969f4 adds systemd support in a downstream only way to the mimedefang package. I am also not sure if this is perfect, however it is working. Socket-based activation can't be used because MIMEDefang needs to be patched before (see: http://0pointer.de/blog/projects/socket-activation.html), but I am not experienced enough to perform this myself. Non-forking model (preferred by systemd) does not work due to missing socket activation (if you start mimedefang and mimedefang-multiplexor non-forking, mimedefang will tell that it's unable to connect to mimedefang-multiplexor via the socket because mimedefang-multiplexor is slower during startup than mimedefang even there are (order) requirements between the two services. Current commit creates unit files mimedefang and mimedefang-multiplexor. The mimedefang one depends on mimedefang-multiplexor. Given I am not sure how happy users would be to reload/restart mimedefang-multiplexor, I bound the mimedefang unit file against mimedefang-multiplexor. That means: If you e.g. start, stop, enable or disable mimedefang, this applies to the multiplexor as well. Upstream should think about socket activation (if interested), the current systemd units could be used upstream, however ./configure should check via pkgconfig for systemd and then dig the systemdsystemunitdir and tmpfilesdir from that (e.g. "pkg-config systemd --variable=systemdsystemunitdir"). But without systemd, the regular initscript should be installed further on. The wrapper is based on the initscript as much as possible, but the permission changes have been moved to tmpfiles.d, the environment changes moved to the unit file (except for /etc/sysconfig/mimedefang). mimedefang-multiplexor is always quitting with exit code 1 - which is bad according to systemd, even for a daemon. This means every stop of mimedefang-multiplexor leads to a failed service (worked around in the unit file), this should be fixed at upstream as well.
Comment 14 DIanne Skoll 2016-01-04 21:17:31 UTC
This simple patch fixes the exit code problem. Regards, Dianne. commit 1b02d5912e3cdc94e330ffb560d87cbddf5d1161 Author: Dianne Skoll <email@example.com> Date: Mon Jan 4 16:14:27 2016 -0500 Make multiplexor exit with success status when sent a TERM signal. Partly fixes Red Hat bug https://bugzilla.redhat.com/show_bug.cgi?id=789768 diff --git a/mimedefang-multiplexor.c b/mimedefang-multiplexor.c index 5fde8cf..bec0e1d 100644 --- a/mimedefang-multiplexor.c +++ b/mimedefang-multiplexor.c @@ -3252,7 +3252,7 @@ sigterm(int sig) #ifdef EMBED_PERL if (Settings.useEmbeddedPerl) term_embedded_interpreter(); #endif - exit(1); + exit(EXIT_SUCCESS); } /**********************************************************************