From: Patrick Schaaf <netdev@bof.de>
To: netdev@vger.kernel.org
Subject: RFC: pid "ownership" of ip config information
Date: Fri, 21 Jan 2011 10:28:11 +0100 [thread overview]
Message-ID: <1295602091.3582.1.camel@lat1> (raw)
Dear netdev,
I want to solicit comments on a feature enhancement that occured
to me recently.
Feature:
- For "ip addr add", "ip route add", "ip rule add", and maybe "ip link
add",
implement an option 'pid XXXXX' to specify a PID
- if that PID is not currently existing, fail the operation
- if, at a later time, that PID dies, automatically remove the
configuration,
as if a corresponding "ip ... del" would have been given
The feature would be useful in any kind of "IP takeover" scenario.
I'm concretely working on deployment of keepalived (VRRP address
takeover) and memcachedb (address takeover after berkeley DB master
selection).
It would also apply to all kinds of routing daemons (zebra, quagga...).
In all these cases, for as long as the process is working normally,
it can trigger the relevant address withdrawal, but when the process
dies unexpectedly (oom killer or whatever), addresses are left
configured,
while a partner on another host might take them over, resulting in
actively duplicate IPs and the application breaking.
The alternative to such a feature, would be to have an additional
monitoring process, which would watch the PID somehow, and need to
be configured to know what to withdraw when it dies.
Before I go ahead and try to implement that, I would like to have
some feedback regarding the idea
- has it been discussed before?
- would it be accepted by the relevant maintainers?
- did I overlook alternative solutions to the problem?
best regards
Patrick
next reply other threads:[~2011-01-21 9:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-21 9:28 Patrick Schaaf [this message]
2011-01-21 10:17 ` RFC: pid "ownership" of ip config information Nicolas de Pesloüan
2011-01-23 10:24 ` Patrick Schaaf
2011-01-23 12:32 ` Nicolas de Pesloüan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1295602091.3582.1.camel@lat1 \
--to=netdev@bof.de \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).