Bug 720175 - Provide native systemd unit file for ipvsadm
Summary: Provide native systemd unit file for ipvsadm
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: ipvsadm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2011-07-10 15:59 UTC by Jóhann B. Guðmundsson
Modified: 2012-04-19 18:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-19 18:54:42 UTC
Type: ---
Embargoed:


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

Description Jóhann B. Guðmundsson 2011-07-10 15:59:30 UTC
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 11:28:24 UTC
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 12:04:05 UTC
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 12:49:05 UTC
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 12:52:21 UTC
Created attachment 512207 [details]
Native systemd service file ipvsadm

Giving full path to ipvsadm-save on ExecStop

Comment 6 Matthias Saou 2011-07-11 18:48:29 UTC
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 12:40:00 UTC
Ping what's the current status of this?

Comment 8 Gwyn Ciesla 2012-04-18 20:02:02 UTC
Nothing in git.  Matthias, any objection to my doing this?

Comment 9 Matthias Saou 2012-04-19 07:53:59 UTC
(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 18:54:42 UTC
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.