Bug 695589 - Providing native systemd file for amavisd-new
Summary: Providing native systemd file for amavisd-new
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: amavisd-new
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Juan Orti
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 789571 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2011-04-12 06:11 UTC by Jóhann B. Guðmundsson
Modified: 2014-02-16 16:38 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-16 16:38:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Native systemd service file fo amavis daemon (310 bytes, text/plain)
2011-04-12 06:11 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for amavis daemon socket (118 bytes, text/plain)
2011-04-12 06:12 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for clamd amavis daemon (369 bytes, text/plain)
2011-04-12 06:12 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for clamd amavis daemon socket (166 bytes, text/plain)
2011-04-12 06:13 UTC, Jóhann B. Guðmundsson
no flags Details
amavisd.service - without socket (265 bytes, text/plain)
2013-09-17 06:55 UTC, Juan Orti
no flags Details
amavisd.service - without socket (293 bytes, text/plain)
2013-09-17 07:37 UTC, Juan Orti
no flags Details

Description Jóhann B. Guðmundsson 2011-04-12 06:11:28 UTC
Created attachment 491409 [details]
Native systemd service file fo amavis daemon

Description of problem:

The attached file is a native systemd file for upcoming F15 Feature [1]

Please read [2] on how to packaging and installing systemd Service files.

To learn more about Systemd daemon see [3].

To view old SysV with the new Systemd site by site see for your component see [4]

If you have any question dont hesitate to ask them on this bug report.

1.http://fedoraproject.org/wiki/Features/systemd

2.https://fedoraproject.org/wiki/Systemd_Packaging_Draft

3.http://0pointer.de/public/systemd-man/daemon.html

4.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability 

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-04-12 06:12:19 UTC
Created attachment 491410 [details]
Native systemd service file for amavis daemon socket

Comment 2 Jóhann B. Guðmundsson 2011-04-12 06:12:47 UTC
Created attachment 491411 [details]
Native systemd service file for clamd amavis daemon

Comment 3 Jóhann B. Guðmundsson 2011-04-12 06:13:11 UTC
Created attachment 491412 [details]
Native systemd service file for clamd amavis daemon socket

Comment 4 Jóhann B. Guðmundsson 2011-04-12 06:18:07 UTC
Note that /var/spool/$foo is not a runtime directory so please fix and set the correct path pointing to /var/run in relevant configuration files and be advices that  in the future /run and $XDG_RUNTIME_DIR are the only places where sockets are OK, yup not even /tmp anymore...

Comment 5 Bill Nottingham 2011-04-26 17:35:43 UTC
Moving systemd service RFEs to rawhide.

At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades.

We therefore request:
- wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes.
- work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release.
- do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy

Comment 7 Marcela Mašláňová 2011-08-02 07:39:53 UTC

*** This bug has been marked as a duplicate of bug 695584 ***

Comment 8 Jóhann B. Guðmundsson 2011-08-02 09:14:29 UTC
Triager please do some proper research before closing bugs as duplicates this report contains the native systemd service files for amavisd daemon

Comment 9 Marcela Mašláňová 2011-08-02 10:35:37 UTC
You might pay more attention to creating bugs. Three bugs with same summary on same component is confusing.

Comment 10 Gwyn Ciesla 2012-02-13 19:42:34 UTC
Steven, any objection to my making this change?

Comment 11 Gwyn Ciesla 2012-03-14 16:23:57 UTC
Ping?

Comment 12 Michael J. Chudobiak 2012-04-03 20:20:06 UTC
Ping? Can we get clamd/amavisd rpms with native systemd service files to test?

Comment 13 Gwyn Ciesla 2012-04-03 20:27:31 UTC
Unless Steven objects I'll do this tonight or tomorrow.

Comment 14 Jóhann B. Guðmundsson 2012-04-03 21:20:04 UTC
You dont need rpms to be able to test submitted units against various components. 

It's enough for you to copy the relevant unit(s) to the /etc/systemd/system directory and run systemctl daemon-reload. 

Those units will then take precedence over the legacy sysv init scripts that bears the same name as the unit...

Comment 15 Gwyn Ciesla 2012-04-04 02:03:34 UTC
Nearly ready, but are we supposed to be shipping .socket files at this point?  I'm unclear on this.  The service won't be enabled by default.

http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

Comment 16 Fedora End Of Life 2013-04-03 19:44:52 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 17 Adam Williamson 2013-05-10 16:47:13 UTC
*** Bug 789571 has been marked as a duplicate of this bug. ***

Comment 18 Adam Williamson 2013-05-10 16:48:06 UTC
Marking as FutureFeature so it doesn't get EOLed.

Comment 19 Juan Orti 2013-09-12 21:26:00 UTC
This bug is more than 2 years old and still open. Steven, Could you add the service unit, please? forget about the socket.

Comment 20 Paul Howarth 2013-09-16 18:14:20 UTC
Has anybody using amavisd tested the service file attached to this bug?

I don't think there's going to be any response from Steve - I think he's been inactive in Fedora for over a year now.

Comment 21 Jóhann B. Guðmundsson 2013-09-16 18:17:17 UTC
Why has this not been orphaned then?

Comment 22 Paul Howarth 2013-09-16 18:20:39 UTC
Because Steve's lack of activity in Fedora has included lack of orphaning packages perhaps?

Comment 23 Juan Orti 2013-09-17 06:55:53 UTC
Created attachment 798640 [details]
amavisd.service - without socket

This is the service unit I use for amavisd-new, the same as Jóhann, but without the socket unit.

Comment 24 Juan Orti 2013-09-17 07:37:08 UTC
Created attachment 798653 [details]
amavisd.service - without socket

If clamav-server-systemd is installed, start clamd instance.

[Unit]
Wants=clamd

Comment 25 Jóhann B. Guðmundsson 2013-09-17 07:41:00 UTC
That's not sufficient and I tried to start a discussion at the package list how we should be dealing with these components but that turned out to be a waste of my time in any case I'm going to ping someone at the admin group and have this package removed or atleast orphaned

Comment 26 Petr Pisar 2013-09-17 07:56:16 UTC
(In reply to Jóhann B. Guðmundsson from comment #25)
> That's not sufficient and I tried to start a discussion at the package list
> how we should be dealing with these components but that turned out to be a
> waste of my time in any case I'm going to ping someone at the admin group
> and have this package removed or atleast orphaned

You cannot orphan other's package. You have to start unresponsive maintainer process, and after finishing that positively, the package will be orphaned.

Comment 27 Jóhann B. Guðmundsson 2013-09-17 08:05:40 UTC
(In reply to Petr Pisar from comment #26)
> (In reply to Jóhann B. Guðmundsson from comment #25)
> > That's not sufficient and I tried to start a discussion at the package list
> > how we should be dealing with these components but that turned out to be a
> > waste of my time in any case I'm going to ping someone at the admin group
> > and have this package removed or atleast orphaned
> 
> You cannot orphan other's package. You have to start unresponsive maintainer
> process, and after finishing that positively, the package will be orphaned.

I thought fesco had been spending time on fixing the orphaning and cleanup process inefficiency since for feature owners and others doing work that span multiple release cycles we need to have this essentially done by alpha ( as in removing and or finding other maintainers ) so people wont be spending time on fixing packages that already are in essence "dead" within the distribution.

Comment 28 Marcela Mašláňová 2013-09-17 08:28:38 UTC
Could you point me to such FESCo ticket, where this direction was approved? 

The package is still working, right? So why should be removed?

Comment 29 Jóhann B. Guðmundsson 2013-09-17 08:35:06 UTC
(In reply to Marcela Mašláňová from comment #28)
> Could you point me to such FESCo ticket, where this direction was approved? 

Which direction would that be? and given that you are on fesco and are unaware of anywork on fesco behalf on fixing the cleanup process I think it safe to assume that fesco is not working on it...

> The package is still working, right? So why should be removed?

Since you need to ask in the first place despite the countless discuss about this through several reoccurring threads on devel over the years then there is no point in explaining why it should be remove to you.

Comment 30 Nicolas Mailhot 2013-09-17 09:32:43 UTC
(In reply to Jóhann B. Guðmundsson from comment #25)
> That's not sufficient and I tried to start a discussion at the package list
> how we should be dealing with these components but that turned out to be a
> waste of my time in any case I'm going to ping someone at the admin group
> and have this package removed or atleast orphaned

What's not sufficient in the systemd rules people posted and that work for them?

Comment 31 Jóhann B. Guðmundsson 2013-09-17 10:57:31 UTC
(In reply to Nicolas Mailhot from comment #30)
> (In reply to Jóhann B. Guðmundsson from comment #25)
> > That's not sufficient and I tried to start a discussion at the package list
> > how we should be dealing with these components but that turned out to be a
> > waste of my time in any case I'm going to ping someone at the admin group
> > and have this package removed or atleast orphaned
> 
> What's not sufficient in the systemd rules people posted and that work for
> them?

Because it brings inconsistency between these components in anycase do what you want I'm not interesting in repeating something I pointed out and tried to reach conscious about in 2011.

Comment 32 Juan Orti 2014-02-16 16:38:13 UTC
amavisd-new 2.8.1-1 has been pushed to rawhide with systemd service files.

http://koji.fedoraproject.org/koji/buildinfo?buildID=498502


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