Bug 789768 - Provide native systemd service
Summary: Provide native systemd service
Alias: None
Product: Fedora
Classification: Fedora
Component: mimedefang
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Robert Scheck
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 751869
TreeView+ depends on / blocked
Reported: 2012-02-12 22:10 UTC by Jóhann B. Guðmundsson
Modified: 2016-01-04 21:17 UTC (History)
4 users (show)

Fixed In Version: mimedefang-2.78-5.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-01-04 20:59:57 UTC
Type: ---

Attachments (Terms of Use)

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...


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
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:

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.



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

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.



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:

Comment 12 Robert Scheck 2015-10-29 14:30:39 UTC
Based on discussions on the IRC, the icecream package provides a 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.



commit 1b02d5912e3cdc94e330ffb560d87cbddf5d1161
Author: Dianne Skoll <dfs@roaringpenguin.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();
-    exit(1);
+    exit(EXIT_SUCCESS);

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