Patrick Lauer <patr...@gentoo.org> writes: > Just for fun, here's all the logic we need to get rsyncd started, *and* > it only starts once network is properly up (where the definition of "up" > is user-configurable as we often disagree on it):
> #!/sbin/runscript > # Copyright 1999-2012 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: > /var/cvsroot/gentoo-x86/net-misc/rsync/files/rsyncd.init.d-r1,v 1.1 > 2012/03/22 22:01:21 idl0r Exp $ > command="/usr/bin/rsync" > command_args="--daemon ${RSYNC_OPTS}" > pidfile="/var/run/${SVCNAME}.pid" > depend() { > use net > } That's all nice and good from a syntax perspective, but we already have the virtual facility $network in our current system. The question is: what does "use net" *do*? If it doesn't wait until the interface is fully configured via DHCP, it's useless for solving the problem that I'm talking about, and that's much more complicated than just doing init script ordering since it involves more than just waiting for daemons to start. As mentioned before, I really don't care what init system we use and I'm happy to adjust my packages to use whatever. I just want to make sure that it will *actually solve the problems*, not just add another level of hand-waving. The problems that I'm particularly concerned about are: * Tracking the processes started by an init script so that they can be killed properly without doing bogus matching on process names, using /proc information to see if they're a particular executable (which is fragile when what you're doing is upgrading that executable and you may not want to stop it first), or particularly PID files. * Automatically restarting services that crash, similar to what daemontools or runit can do. * Real event awareness at the kernel level so that it knows when parts of the system are *actually* available without guessing, using random delays, or making assumptions about the implications of other daemons having been started. * Getting rid of all the boilerplate in init scripts and reducing them to only the information that's actually interesting and might change. I know upstart and systemd do all of those things for the platforms for which they're available. I know that the current init system does none of those things. According to this thread, I know OpenRC does do several of those things. If it also does all of those things, great! That makes it a very interesting contender. If it doesn't do all of those things and can't be made to do all those things with roughly the same amount of effort it would take to port upstart or systemd to kFreeBSD, it ceases to be an interesting contender for me personally. The conversation has gotten a bit frustrating, so I feel compelled to say explicitly (not aimed at you, Patrick) that I'm completely uninterested personally in arguments that I shouldn't care about those features. I do, and I'm extremely unlikely to change my mind. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk9ykkmx....@windlord.stanford.edu