Re: Issues with PID file renaming
On 10.12.2013 21.52, Eric Wong wrote: > Petteri Räty wrote: >> On 26.11.2013 3.20, Eric Wong wrote: >>> How about having the old process create a hard link to .oldbin, >>> and having the new one override the pid if Process.ppid == pid file? >>> The check is still racy, but that's what pid files are :< >> >> Isn't it possible to always keep a valid pid file by using the fact that >> mv is atomic? Basically the new process writes the pid first to a temp >> file and then moves it over the old pid file after having hard linked >> the file to .oldbin? >> >> $ echo "1" > foo.pid >> $ ln foo.pid foo.oldpid >> $ echo "2" > tmp >> $ mv tmp foo.pid >> $ cat *pid >> 1 >> 2 > > It's possible, but is it worth it? Having both pid files point to the > same pid is still wrong. > At least for pid based monitoring tools it is (I do agree with others that you should also be monitoring http though). For example monit requires that you give it a pid file. Why is it wrong for them to point to the same pid? Seems ok to me especially since they share the inode. Any way I think this is better than there being no pid file. After all we are doing a zero downtime deploy which means there's always a valid process. Regards, Petteri ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
Re: Issues with PID file renaming
Petteri Räty wrote: > On 26.11.2013 3.20, Eric Wong wrote: > > How about having the old process create a hard link to .oldbin, > > and having the new one override the pid if Process.ppid == pid file? > > The check is still racy, but that's what pid files are :< > > Isn't it possible to always keep a valid pid file by using the fact that > mv is atomic? Basically the new process writes the pid first to a temp > file and then moves it over the old pid file after having hard linked > the file to .oldbin? > > $ echo "1" > foo.pid > $ ln foo.pid foo.oldpid > $ echo "2" > tmp > $ mv tmp foo.pid > $ cat *pid > 1 > 2 It's possible, but is it worth it? Having both pid files point to the same pid is still wrong. ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
Re: Issues with PID file renaming
On 26.11.2013 3.20, Eric Wong wrote: >> >> I think the way 4.6.2 worked is better. There should be a pid file for >> the new master process the moment it's created. > >> What do you think? > > How about having the old process create a hard link to .oldbin, > and having the new one override the pid if Process.ppid == pid file? > The check is still racy, but that's what pid files are :< > Isn't it possible to always keep a valid pid file by using the fact that mv is atomic? Basically the new process writes the pid first to a temp file and then moves it over the old pid file after having hard linked the file to .oldbin? $ echo "1" > foo.pid $ ln foo.pid foo.oldpid $ echo "2" > tmp $ mv tmp foo.pid $ cat *pid 1 2 Regards, Petteri ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
