`sleep 1` works fine for me, so I'd prefer a solution that doesn't guarantee 5-10 seconds of unnecessary downtime. The pid timeout solution seems much better.

This is a common problem with many init/rc scripts and systems, I would like to come up with a better solution that just making the script sleep.

Right now I see a number of cases, one is that if the service itself can be sent a quit command that blocks until the service has cleaned itself up properly then that is optimal, like in the moosefs rc scripts: http://projects.archlinux.org/svntogit/community.git/tree/mfs/trunk/mfsmaster

But in cases where this is not an option we should devise something more elegant than a sleep. I would propose a simple solution, we add a restart function to the /etc/rc.d/functions file that takes a PID as an arg, and then watches the pid for a configurable amount of time. Then if the timeout is reached the function can either send a SIGKILL to the process or just stat fail.

Actually, now that I am typing all of this out, it sounds to me a lot more like redhat's killproc function. Something that makes the kill just block until the process is ensured dead. But I think that we need a timeout and a decision.

If I am not mistaken, redhat will just block, for a very long time, I have seen redhat block for over 10 minutes when stopping a service. Ubuntu has a short timeout and then instead of stating a failure it sends a SIGKILL and destroys the service that way. The Ubuntu way has bitten me quite a few times and I would stongly discourage it - but I think that it should be an option for the developer of the rc script, since some processes can be safely sent a SIGKILL (I have seen dnsmasq for instance not die with a SIGTERM but it can be safely killed with a SIGKILL)

So in a nutshell, I think that we should provide a function in /etc/rc.d/functions for killing a process, and that the function will take 3 args, 1 required arg - The process PID, and then the 2 remaining args would be the timeout, (default to say 10 seconds), and then what to do if the timeout is reached, default to a stat fail and have the option to send the PID a SIGKILL.

I think that this would greatly benefit Arch rc scripts, I have run into this problem with a number of rc scripts when using automation tools like puppet and when using automation scripts.

If it is something that could be included in the functions file, then I will write up the function, just let me know.

There is also the option with nginx to upgrade the binary on the fly: http://wiki.nginx.org/NginxCommandLine, scroll down a ways.

ahh, yes, and the cli can send signals to nginx as well.

But there are a number of other rc scripts that have this problem, do you think that the solution I mentioned is potentially viable? Should I spend the time on it?

I think it would be a worthwhile addition to `functions`; I also think it belongs in it's own feature request once you come up with something though. Obviously you can link the two issues.

Thanks Dan, thats what I wanted to hear, I will get on these.

I will have a solution for this problem soon, thanks.

Should this bug be assigned to me? as lowly TU, can I assign bugs?

I have a proposed solution in a feature request.
https://bugs.archlinux.org/task/22946

Or at least something allong those lines would be an elegant solution