On Wed, Oct 22, 2014 at 03:09:12PM +0200, Dejan Muhamedagic wrote:
> On Wed, Oct 22, 2014 at 06:50:37AM -0600, Alan Robertson wrote:
> > On 10/22/2014 03:33 AM, Dejan Muhamedagic wrote:
> > > Hi Alan,
> > >
> > > On Mon, Oct 20, 2014 at 02:52:13PM -0600, Alan Robertson wrote:
> > >> For the Assimilation code I use the full pathname of the binary from
> > >> /proc to tell if it's "one of mine". That's not perfect if you're using
> > >> an interpreted language. It works quite well for compiled languages.
> > > Yes, though not perfect, that may be good enough. I supposed that
> > > the probability that the very same program gets the same recycled
> > > pid is rather low. (Or is it?)
> > From my 'C' code I could touch the lock file to match the timestamp of
> > the /proc/pid/stat (or /proc/pid/exe) symlink -- and verify that they
> > match. If there is no /proc/pid/stat, then you won't get that extra
> > safeguard. But as you suggest, it decreases the probability by orders
> > of magnitude even without the
> >
> > The /proc/pid/exe symlink appears to have the same timestamp as
> > /proc/pid/stat
>
> Hmm, not here:
>
> $ sudo ls -lt /proc/1
> ...
> lrwxrwxrwx 1 root root 0 Aug 27 13:51 exe -> /sbin/init
> dr-x------ 2 root root 0 Aug 27 13:51 fd
> -r--r--r-- 1 root root 0 Aug 27 13:20 cmdline
> -r--r--r-- 1 root root 0 Aug 27 13:18 stat
We can not rely on properties of the inodes in /proc/.
These inodes get dropped and recreated as the system sees fit.
and their properties re-initialized to "something".
Ok, the uid/gid is consistent, obviously.
But neither inode numbers or a,m,ctime is "stable".
I demo'ed that in my first email,
I demo it again here:
sleep 120 & k=$! ; stat /proc/$k ; echo 3 > /proc/sys/vm/drop_caches ; sleep 2;
find /proc/ -ls &> /dev/null; stat /proc/$k
File: `/proc/8862'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 4295899 Links: 8
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-10-23 18:43:25.535000006 +0200
Modify: 2014-10-23 18:43:25.535000006 +0200
Change: 2014-10-23 18:43:25.535000006 +0200
File: `/proc/8862'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 4296016 Links: 8
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-10-23 18:43:27.561002753 +0200
Modify: 2014-10-23 18:43:27.561002753 +0200
Change: 2014-10-23 18:43:27.561002753 +0200
Note how the inode number and a,m,ctime changes.
the "starttime" I was talking about is the 22nd field of /proc/$pid/stat
see proc(5):
starttime %llu (was %lu before Linux 2.6)
(22) The time the process started after system boot.
In kernels before Linux 2.6, this value was expressed in jiffies.
Since Linux 2.6, the value is expressed in clock ticks
(divide by sysconf(_SC_CLK_TCK)).
Thats a monotonic time counting from system boot.
Which makes it so attractive.
Even if someone fiddles with date --set (or ntp or ...),
even if that would be done on purpose, this field would not care.
Anyways: making this "somebody elses problem",
using (a tool like) start-stop-daemon,
require that to be present,
and help make that do the best thing possible,
and as portable as possible, could be a good way to go.
Still the "cd /proc/$pid", then work from there
would avoid various race conditions nicely.
Where available, open() then openat() will do nicely, as well,
no need to chdir.
So the "quick fix" to solve the issue that triggered the discussion
(not noticing that a pid has died):
is my first suggestion:
# wait for pid to die:
- while kill -0 $pid; do sleep 1; done
+ ( if cd /proc/$pid ; then while test -d . ; do sleep 1; done ; fi ) &>
/dev/null
Should we do an ocf-shellfuncs helper for this?
Suggested names?
What should go in there -- only the waiting, the kill TERM?
A timeout? Escalation to kill KILL?
Lars
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
