Bug 720175 - Provide native systemd unit file for ipvsadm
Provide native systemd unit file for ipvsadm
Product: Fedora
Classification: Fedora
Component: ipvsadm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
Depends On:
Blocks: SysVtoSystemd
  Show dependency treegraph
Reported: 2011-07-10 11:59 EDT by Jóhann B. Guðmundsson
Modified: 2012-04-19 14:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-19 14:54:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Native systemd service file for ipvsadm (375 bytes, text/plain)
2011-07-10 12:04 EDT, Jóhann B. Guðmundsson
no flags Details
Native systemd service file ipvsadm (382 bytes, text/plain)
2011-07-11 08:52 EDT, Jóhann B. Guðmundsson
no flags Details

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


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

How reproducible:

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

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