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:
Created attachment 491410 [details] Native systemd service file for amavis daemon socket
Created attachment 491411 [details] Native systemd service file for clamd amavis daemon
Created attachment 491412 [details] Native systemd service file for clamd amavis daemon socket
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...
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
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
*** This bug has been marked as a duplicate of bug 695584 ***
Triager please do some proper research before closing bugs as duplicates this report contains the native systemd service files for amavisd daemon
You might pay more attention to creating bugs. Three bugs with same summary on same component is confusing.
Steven, any objection to my making this change?
Ping?
Ping? Can we get clamd/amavisd rpms with native systemd service files to test?
Unless Steven objects I'll do this tonight or tomorrow.
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...
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
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
*** Bug 789571 has been marked as a duplicate of this bug. ***
Marking as FutureFeature so it doesn't get EOLed.
This bug is more than 2 years old and still open. Steven, Could you add the service unit, please? forget about the socket.
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.
Why has this not been orphaned then?
Because Steve's lack of activity in Fedora has included lack of orphaning packages perhaps?
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.
Created attachment 798653 [details] amavisd.service - without socket If clamav-server-systemd is installed, start clamd instance. [Unit] Wants=clamd
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
(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.
(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.
Could you point me to such FESCo ticket, where this direction was approved? The package is still working, right? So why should be removed?
(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.
(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?
(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.
amavisd-new 2.8.1-1 has been pushed to rawhide with systemd service files. http://koji.fedoraproject.org/koji/buildinfo?buildID=498502