Description of problem:
Let's get the ball rolling on this one...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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.
Robert, any objection to my taking a look at this an migrating it if I can?
Jon, have a look to it, if you want. But please avoid breaking it ;-) However
it would be trivial as Jóhann already mentioned.
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:
mimedefang has still no systemd unit file, any news about that?
What did upstream say?
@Robert: Any news? MIMEdefang 2.75 has also no systemd unit file...
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
(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.
(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.
> 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
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
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:
Based on discussions on the IRC, the icecream package provides a wrapper:
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
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.
This simple patch fixes the exit code problem.
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
@@ -3252,7 +3252,7 @@ sigterm(int sig)
if (Settings.useEmbeddedPerl) term_embedded_interpreter();