Re: daemon stop and start during upgrade
Hallo Florian, Florian Weimer [EMAIL PROTECTED] wrote: * Luis Rodrigo Gallardo Cruz: So in the end I agree that would be sensible to exit with 0, if the process is not running, cause their might be different errors to occur when stopping (even though I never met one), but that it would make sense to describe this more clear in the policy. IIRC, lsb requires exiting with 0 in this case. OTOH, if you want to avoid restarting a non-running service, you need to obtain somehow that piece of informati from the init.d script run. The exit status would be a way to do this. You should disable the service at all (remove the symlinks or put a - in /etc/runlevel.conf) and invoke-rc.d takes care of this. Bye, Jörg. -- [dpkg] We are the apt. Resistance is futile. You will be packaged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Felipe Sateler wrote: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running Ah.. yeah, that would be a possible interpretation of the policy. But formalizing something as to behave sensibly is not really exact, cause it is up to the reader how he interprets it. I do interpret it like this: - Don't do nasty things with 'start' when already running (like killing the firsts pidfiles, launching a seconds instance, etc.) - Don't do nasty things with 'stop' when not running (like killing other processes or changing something in the environment so it won't start the next time). I understand it so, that the third one is just there to describe it more exactly. Because exiting with zero or non-zero has absolutely nothing to do with behaving sensibly. Actually returning a non-zero exit code is the right thing to do, cause the action to stop a process _did_ fail, because the process has not been running. Then again it would be sensible not to let the upgrade process fail just because of this, but i think thats far from the scope. So in the end I agree that would be sensible to exit with 0, if the process is not running, cause their might be different errors to occur when stopping (even though I never met one), but that it would make sense to describe this more clear in the policy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
On Thu, Sep 13, 2007 at 08:33:16AM +0200, Patrick Schoenfeld wrote: Felipe Sateler wrote: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running So in the end I agree that would be sensible to exit with 0, if the process is not running, cause their might be different errors to occur when stopping (even though I never met one), but that it would make sense to describe this more clear in the policy. IIRC, lsb requires exiting with 0 in this case. signature.asc Description: Digital signature
Re: daemon stop and start during upgrade
Patrick Schoenfeld wrote: Because exiting with zero or non-zero has absolutely nothing to do with behaving sensibly. Actually returning a non-zero exit code is the right thing to do, cause the action to stop a process _did_ fail, because the process has not been running. Not really. It also depends on how you see it: if I ask some process to stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: stop: pre-requisites: none post-conditions: the service is stopped, or an error is reported -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Felipe Sateler schrieb: Not really. It also depends on how you see it: if I ask some process to Sure. Thats exactly what I'm saying. stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: Really? So maybe *you* don't care about the services state when you stop it. But *I* could expect it to be running, if I ask it to stop. Because something could be wrong, if the service is not running, I want to know if it isn't. OTOH its not me requesting the service to stop, but a process that can't know that I eventually stopped the service, because I wanted to do. Well doesn't matter, really. I agree to what you are saying. But the point is, that others could see that different. Thats were rules and policies come in handy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
On 13/09/2007, Patrick Schoenfeld [EMAIL PROTECTED] wrote: Felipe Sateler schrieb: Not really. It also depends on how you see it: if I ask some process to Sure. Thats exactly what I'm saying. stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: Really? So maybe *you* don't care about the services state when you stop it. But *I* could expect it to be running, if I ask it to stop. Because something could be wrong, if the service is not running, I want to know if it isn't. OTOH its not me requesting the service to stop, but a process that can't know that I eventually stopped the service, because I wanted to do. What about adding a 'status' target to the init.d script? I think that's the way to make sure the exit status is zero nomatter the daemon is running or not (it should only return a non-zero status if it failed to check whether the daemon is running or not). And about how to tell the postinst script whether the daemon was stopped by the prerm script I think the easiest and safest way to do it is by storing the information with debconf. Well doesn't matter, really. I agree to what you are saying. But the point is, that others could see that different. Thats were rules and policies come in handy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Just my two cents, hope it helps. Sincerely, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Justin Pryzby schrieb: It would be a pro to take this into the policy, wouldn't it? It is 9.3.2: | [...] No, it isn't. This part of the policy just says that it should not kill other processes, which are eventually named unfortunately, just because the process it *should* kill does not run. It does not say anything about how the init script should behave, if the application is not running. But, and thats important, this does again recommend to use start-stop-daemon which exits with a non-zero exit-code if there is nothing to stop. It's a very interesting question whether packages should inhibit starting a daemon that wasn't running when it would otherwise have been stopped. I guess the current state of affairs is that a That is another thing, but yes, I agree that this is very interestering as well. think the ideal situation is that a manually-stopped daemon would cause a message to be printed: Not starting food: not stopped at preinst time in the same style of messages that are shown with [...] ACK. I think this would be a good proposal. But how to realise this properly? It would need a change to the init script, would it? Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Patrick Schoenfeld wrote: Justin Pryzby schrieb: It would be a pro to take this into the policy, wouldn't it? It is 9.3.2: | [...] No, it isn't. Yes, it is. You can dissect the paragraph in 3 ideas: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running - Don't kill unfortunately named user processes. 2 and 3 are separated because of the comma before the 'and'. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
daemon stop and start during upgrade
Hello, Currently I am packaging a daemon. I used dh-make (0.43, Debian lenny) and did some small adjustments afterwards. Now came across two problems where I am not sure how they should solved properly, in other words: What is best practise? Given the following situation: The daemon was stopped manually. Now I want to install a new build, using dpkg -i. This invokes (among other) /var/lib/dpkg/info/daemon.prerm which contains only a few lines Automatically added by dh_installinit. They include a call of invoke-rc.d daemon stop || exit $?, this is basically a wrapper for /etc/init.d/daemon stop which calls start-stop-daemon. This program returns non-zero since the daemon is not running, that value is passed back through the chain and finally causes a dpkg error. dpkg tries the script from the new package instead which fails for the same reason. To deal with that mess I could modify /etc/init.d/daemon and add the --oknodo to start-stop-daemon, or || true. If this is the best way to do, why does not dh-make create the init script in such a way by default? An alternative approach was to ship my own version of prerm thus overriding dh_installinit. Not a good idea IMHO. Is there a better solution? A second question: I was told it was a wise idea to start the daemon after an upgrade only if it was running before the upgrade. This means catching the is it running? state in prerm and preserving it until postinst. Is there a framework available for that task? I am not keen on re-inventing the wheel. Christoph signature.asc Description: Digital signature
Re: daemon stop and start during upgrade
* Christoph Biedl [Tue, 11 Sep 2007 15:34:49 +0200]: Hello, Currently I am packaging a daemon. I used dh-make (0.43, Debian lenny) and did some small adjustments afterwards. Now came across two problems where I am not sure how they should solved properly, in other words: What is best practise? Given the following situation: The daemon was stopped manually. Now I want to install a new build, using dpkg -i. This invokes (among other) /var/lib/dpkg/info/daemon.prerm which contains only a few lines Automatically added by dh_installinit. They include a call of invoke-rc.d daemon stop || exit $?, this is basically a wrapper for /etc/init.d/daemon stop which calls start-stop-daemon. This program returns non-zero since the daemon is not running, that value is passed back through the chain and finally causes a dpkg error. dpkg tries the script from the new package instead which fails for the same reason. To deal with that mess I could modify /etc/init.d/daemon and add the --oknodo to start-stop-daemon, or || true. If this is the best way to do, why does not dh-make create the init script in such a way by default? An alternative approach was to ship my own version of prerm thus overriding dh_installinit. Not a good idea IMHO. Is there a better solution? Your init.d script should *not* exit with status non-zero if the daemon was already stopped. You can do that either by passing --oknodo to start-stop-daemon, or by checking by hand if the return status is 1. *Not*, in any case, by appending || true, since that would hide the case when a real errors occurs and the daemon can't be stopped. If you wrote your init.d script from some template that advocates returning directly the exit status of start-stop-daemon without --oknodo, that template needs fixing. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Hooverphonic - Heartbeat (Remix) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Adeodato Simó schrieb: Your init.d script should *not* exit with status non-zero if the daemon was already stopped. You can do that either by passing --oknodo to start-stop-daemon, or by checking by hand if the return status is 1. *Not*, in any case, by appending || true, since that would hide the case when a real errors occurs and the daemon can't be stopped. Hm. If i think about this topic it appears to make sense to let invoke-rc.d not fail (I actually do it like this), but I'm asking myself the question why this is not formalized in the policy? Cause it is a discuss able point if you think on it from this side: If nothing is there to be stopped, then the requested action (say: stopping something) obviously failed. But then again, we know that it does not make much sense to let an upgrade fail, just because any admin stopped a daemon. So rationale there are reasons for and against letting stop fail with a non-zero exit code if there is nothing running, which could be stopped. It would be a pro to take this into the policy, wouldn't it? If you wrote your init.d script from some template that advocates returning directly the exit status of start-stop-daemon without --oknodo, that template needs fixing. Hm. It would be better to fix start-stop-daemon, cause policy does *hardly* recommend to use it, while it does not have any recommends about which template you may use. So it seems like not the template is wrong, but the behavior of start-stop-daemon is wrong. Or not? But then again it makes it hard to decide that, because policy does not have a rule for this case. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
On Tue, Sep 11, 2007 at 08:06:42PM +0200, Patrick Schoenfeld wrote: Adeodato Simó schrieb: Your init.d script should *not* exit with status non-zero if the daemon was already stopped. You can do that either by passing --oknodo to start-stop-daemon, or by checking by hand if the return status is 1. *Not*, in any case, by appending || true, since that would hide the case when a real errors occurs and the daemon can't be stopped. Hm. If i think about this topic it appears to make sense to let invoke-rc.d not fail (I actually do it like this), but I'm asking myself the question why this is not formalized in the policy? It would be a pro to take this into the policy, wouldn't it? It is 9.3.2: |The `init.d' scripts must ensure that they will behave sensibly if |invoked with `start' when the service is already running, or with |`stop' when it isn't, and that they don't kill unfortunately-named |user processes. The best way to achieve this is usually to use |`start-stop-daemon'. It's a very interesting question whether packages should inhibit starting a daemon that wasn't running when it would otherwise have been stopped. I guess the current state of affairs is that a manually-stopped daemon which is started at postinst time will cause a message to be printed and the admin can stop it again if he wants. I think the ideal situation is that a manually-stopped daemon would cause a message to be printed: Not starting food: not stopped at preinst time in the same style of messages that are shown with increasing consistency when things are not enabled in etc/default. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
