Hi Tuomas, Tuomas Noraef <tnor...@gmail.com> writes:
> Just two things I noted : > > - first thing in the "stop" stanza : the 15 seconds timeout to switch > from SIGTERM to SIGKILL may be a bit long, especially until the server > is patched to send the SIGTERM to its worker thread, but I don't know > : maybe it is a Debian guideline or something. I'll leave that up to > you to decide : just noting a systematic (at least for now) 15 seconds > is a tad long to wait, especially when testing things with the server > (did quite a few bcfg2-server restarts when I first tested SSL > bi-lateral authentication, and, well, this partly was already because > of that I had removed the 5 seconds sleep there was in the old init > script... so 15 seconds... : 5 seconds could be sufficient, I guess). Agreed, 15 seconds is a long time to wait for something that will never happen. There are a few reasons, though. Just straight up killing the daemon can be dangerous (it can for example stop it from writing some of it's database files completely, and corrupt the repository), and should not be done lightly. Under normal conditions the daemon is unlikely to require 15 seconds to stop properly, but under heavy io load or other less normal conditions it could take long. Since the daemon does not exit after receiving the TERM signal (due to the bugs), we have no way of knowing when it is actually done, and I prefer to be safe than sorry. I'm hoping that version 1.1 comes out with the fix for the actual bug before it's too late to get it into squeeze, or that I manage to backport the bugfix to the current version. I'm not willing to release with an RC version. > - other thing is in the "status" stanza : you make the init script > exit with a "3" error code, if the server was not running, which > outputs something like : > > "bcfg2-server is not running > invoke-rc.d: initscript bcfg2-server, action "status" failed." > > the second line of which I am not so sure is useful... basically, you > make the init script exit with a non-zero error code, even though it > is not the culprit, the bcfg2-server at most being the one : the > action "status" did not failed in itself - in that case, it only > failed our hopes, mostly. Maybe the status stanza should exit with a > "0" code whatever happens, and use a "log_daemon_msg" to signal > anything, would you find the need to ? The Debian Policy does not currently define the init script status action at all, but the LSB standard does. Returning 3 when the daemon is not running is what the LSB expects, and I prefer to stay relatively close to the standard (it also requires other return codes for cases when the pid file exists but the daemon is not running and such, but I haven't bothered to implement those yet). See http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html for the init script part of LSB. > Anyway, thanks for caring this bug, and maintaining bcfg2 in Debian : > after testing a bit more, I really felt in love with it (a few gripes, > like documentation [already bought the Sage short topics which is > rather good, albeit a tad outdated and, well... short], the > disappearance of a native agent-mode, XML [still... though I am > already trying to craft some XML files through auto-templating]... > but, still : IMHO far better than anything else I tried, and I tried > pretty much everything else in this domain). Oh, and thanks for > ditching the use of the LSB "init-functions", unwrapping the > start-stop-daemon from these horrors : highly appreciated :p The documentation situation is hopefully improving, there are people working on it upstream currently. I'm not really a fan of XML either, but Bcfg2 does work very well for what I'm doing with it. I'll mark this bug as pending for the time being, there are a few other issues I want to address before uploading (including the no longer existing agent mode). -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
