On Mon, Feb 23, 2015 at 12:17:39PM +0900, Alan Mizrahi wrote:
On 2015-02-22 19:04, James Mills wrote:
Introducing start-stop-daemon and then changing openssh's rc script (/etc/rc.d/ssh) to use /sbin/start-stop-daemon and not listing start-stop-daemon IHMO is wrong.
But the Port guidelines say not to do this which I think in this case is a bit silly or at least ambiguous.
So all this aside... Let's discuss what we can here...
Do we need to update our Polices? I think so.
Should we list run-time dependencies that are not linked against? I definitely think so - otherwise you end up with a potentially broken system.
I think it is reasonable to assume a core set of ports are installed, but we should keep that list as small as possible. I wouldn't miss reiserfsprogs, xfsprogs, jfsutils or tcp_wrappers if they were moved to opt.
The problem here was: 1. introducing start-stop-daemon now instead of waiting for a new CRUX release
Introducing it now was intentionally, to give all maintainers time to familiarize with it. I admit that it was a bit/too? fast to change the sshd start script 3 days after adding start-stop-daemon to core.
2. not discussing it or announcing it properly (eg: mailing list instead of IRC)
it was announced to the mailing list, see https://lists.crux.nu/pipermail/crux/2015-February/004357.html
That said, the commits that introduced the changes had a [notify], perhaps it was not enough.
What else?
Lastly, Why are we introducing (already have) start-stop-daemon from Debian's ecosystem? What are we trying to solve with this tool that we can't otherwise solve in other ways or have issues with certain softwared fixed upstream?
Our init scripts have some problems, and while most of them can be solved with shell-scripting, for some people the KISS principle is incompatible with a reliable init script. Some of our scripts looks like this:
case $1) in start) /usr/sbin/somedaemon ;; stop) pkill somedaemon ;; restart) $0 stop sleep 2 $0 start ;; esac
Looks clean, simple and elegant.
Some observations though: 1. start: No check if /usr/sbin/somedamon was already running beforehand 2. stop: pkill is potentially dangerous 3. stop: did the daemon really stop? We have to check manually. 4. stop: did the daemon stop by the time the init script finished? Possibly not. 5. restart: "$0 stop" can finish before the daemon has, so there is a sleep. Are 2 seconds long enough? If not, the daemon will run twice concurrently (because of point 1).
Some daemons take care of these things by themselves, but not all.
If the daemon writes a pidfile, it should be easy for the script to do things correctly, but I have seen this kind of script used even when the daemon writes a pidfile.
That is why I maintain private ports for every daemon that I use, but it would be nice if the official ports were better.
My init scripts will kill the daemon, wait a prudential time for it to finish, and inform you if it didn't. Some of them also start the daemon with reduced permissions via sudo.
These things are easier to do correctly with start-stop-daemon.
So we have two options: 1. Start writing init scripts properly 2. Start using start-stop-daemon
I think start-stop-daemon would preserve the KISS principle better, but I would like to point out that Debian has moved to the dark side (aka systemd) already.
Gentoo's openrc is using a clone of start-stop-daemon as weel, so it would be possible to use this one instead.
Personally I will only start using start-stop-daemon it if I really need it, and so far I have managed without it.
Best regards,
best regards Juergen