Bug 695589 - Providing native systemd file for amavisd-new
Providing native systemd file for amavisd-new
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: amavisd-new (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Juan Orti
Fedora Extras Quality Assurance
: FutureFeature, Reopened
: 789571 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
  Show dependency treegraph
 
Reported: 2011-04-12 02:11 EDT by Jóhann B. Guðmundsson
Modified: 2014-02-16 11:38 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-16 11:38:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Jóhann B. Guðmundsson 2011-04-12 02:11:28 EDT
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 02:12:19 EDT
Created attachment 491410 [details]
Native systemd service file for amavis daemon socket
Comment 2 Jóhann B. Guðmundsson 2011-04-12 02:12:47 EDT
Created attachment 491411 [details]
Native systemd service file for clamd amavis daemon
Comment 3 Jóhann B. Guðmundsson 2011-04-12 02:13:11 EDT
Created attachment 491412 [details]
Native systemd service file for clamd amavis daemon socket
Comment 4 Jóhann B. Guðmundsson 2011-04-12 02:18:07 EDT
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 13:35:43 EDT
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 03:39:53 EDT

*** This bug has been marked as a duplicate of bug 695584 ***
Comment 8 Jóhann B. Guðmundsson 2011-08-02 05:14:29 EDT
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 06:35:37 EDT
You might pay more attention to creating bugs. Three bugs with same summary on same component is confusing.
Comment 10 Jon Ciesla 2012-02-13 14:42:34 EST
Steven, any objection to my making this change?
Comment 11 Jon Ciesla 2012-03-14 12:23:57 EDT
Ping?
Comment 12 Michael J. Chudobiak 2012-04-03 16:20:06 EDT
Ping? Can we get clamd/amavisd rpms with native systemd service files to test?
Comment 13 Jon Ciesla 2012-04-03 16:27:31 EDT
Unless Steven objects I'll do this tonight or tomorrow.
Comment 14 Jóhann B. Guðmundsson 2012-04-03 17:20:04 EDT
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 Jon Ciesla 2012-04-03 22:03:34 EDT
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 15:44:52 EDT
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 12:47:13 EDT
*** Bug 789571 has been marked as a duplicate of this bug. ***
Comment 18 Adam Williamson 2013-05-10 12:48:06 EDT
Marking as FutureFeature so it doesn't get EOLed.
Comment 19 Juan Orti 2013-09-12 17:26:00 EDT
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 14:14:20 EDT
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 14:17:17 EDT
Why has this not been orphaned then?
Comment 22 Paul Howarth 2013-09-16 14:20:39 EDT
Because Steve's lack of activity in Fedora has included lack of orphaning packages perhaps?
Comment 23 Juan Orti 2013-09-17 02:55:53 EDT
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 03:37:08 EDT
Created attachment 798653 [details]
amavisd.service - without socket

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

[Unit]
Wants=clamd@amavisd.service
Comment 25 Jóhann B. Guðmundsson 2013-09-17 03:41:00 EDT
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 03:56:16 EDT
(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 04:05:40 EDT
(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 04:28:38 EDT
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 04:35:06 EDT
(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 05:32:43 EDT
(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 06:57:31 EDT
(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 11:38:13 EST
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.