Bug 720175

Summary: Provide native systemd unit file for ipvsadm
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: ipvsadmAssignee: Matthias Saou <matthias>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: johannbg, limburgher, matthias
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-19 14:54:42 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 713562    
Attachments:
Description Flags
Native systemd service file for ipvsadm
none
Native systemd service file ipvsadm none

Description Jóhann B. Guðmundsson 2011-07-10 11:59:30 EDT
Description of problem:

https://fedoraproject.org/wiki/Features/SysVtoSystemd


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 Matthias Saou 2011-07-11 07:28:24 EDT
I started having a look at this, and wanted to compare with what the iptables service was doing, since the pending sysvinit scripts for ipvsadm do very similar things (see #593276 : load modules only when needed, optionally reload them on restart, optionally save on stop...)... and I saw that the current Rawhide iptables package does not contain an iptables.service file yet.
Comment 3 Jóhann B. Guðmundsson 2011-07-11 08:04:05 EDT
Yeah Thomas and Lennart are working something + I think the plan is to use firewalld from now on so I'm not so sure what the future holds for iptables in it's current form anyway iptables is far more complex beast than ipvsadm and status is handled completely by systemd thus cannot be "customised" hence you only have one option and that is to run "ipvsadm-save -n > /etc/sysconfig/ipvsadm" when the service is stopped and or administrators have to run it manually and afaik modules should be loaded via autoloading based on bus information, or via /etc/modules-load.d/*.conf. and unloading a module from the kernel should not be done except for debugging purposes. 

Now it would be good if "-f --file" parameter was added to ipvsadm-restore ipvsadm-save so we would not have to jump into bash ( which because of the redirects  < > ) and run this as we could do... 

/sbin/ipvsadm-restore -f /etc/sysconfig/ipvsadm 
/sbin/ipvsadm-save -f /etc/sysconfig/ipvsadm
Comment 4 Jóhann B. Guðmundsson 2011-07-11 08:49:05 EDT
After looking at that bug report I think neither the legacy sysvinit script is the culprit nor ipvsadm but RHEL sosreport thus sosreport should be fixed anyway since the issue there was when service status was called in the legacy sysv init script it ran "ipvsadm -L -n" and that no longer applies since you no longer can create custom status output.
Comment 5 Jóhann B. Guðmundsson 2011-07-11 08:52:21 EDT
Created attachment 512207 [details]
Native systemd service file ipvsadm

Giving full path to ipvsadm-save on ExecStop
Comment 6 Matthias Saou 2011-07-11 14:48:29 EDT
Note that both /sbin/ipvsadm-restore and /sbin/ipvsadm-save are bash scripts, so forking bash from systemd but then running them as "exec" might not be wasting any extra forks.

From there, a quick look reveals that they don't do much (nearly nothing!), and that :
1) It's not needed to "ExecStartPre=/sbin/ipvsadm -C" since ipvsadm-restore does it.
2) It's ipvsadm itself which would need to be modified to support loading rules from a file instead of stdin, and writing them to a file too.
Comment 7 Jóhann B. Guðmundsson 2012-02-12 07:40:00 EST
Ping what's the current status of this?
Comment 8 Jon Ciesla 2012-04-18 16:02:02 EDT
Nothing in git.  Matthias, any objection to my doing this?
Comment 9 Matthias Saou 2012-04-19 03:53:59 EDT
(In reply to comment #8)
> Nothing in git.  Matthias, any objection to my doing this?

I'm perfectly fine if you have a stab at it! I haven't looked at this in a long while, nor have I checked how iptables was doing it now.
Comment 10 Jon Ciesla 2012-04-19 14:54:42 EDT
Done, thanks.  I pulled out the ExecStartPre line, and the rest looks correct for how this is intended to work.