On Thu, May 23, 2013 at 12:47:46AM +0200, Kurt Roeckx wrote: > Note that such conversion to a sysv init script is not supposed to > provide all the features that upstart and systemd provide. Else > there would be no need to move to systemd or upstart in the first > place.
That is true, and I already pointed out some of that functionality as non-essential (e.g. resource limits). > On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote: > > * stdout/stderr to syslog redirection > > This is possibly implementable, but needs more than a line of shell. > > Do you know about logger(1)? If that itself is not good enough, > it should be easy enough to make something that does what you > want. Good catch. Having it integrate with e.g. start-stop-daemon appears slightly harder, but yeah this surely is not a blocker. > > * missing dependencies > > Due to the use of socket activation it is to be expected that > > services stop declaring their dependencies. In .service files this > > information commonly is not present, because it is not needed. > > It's not because it's not needed that we can't add this. If we > already have this information there is no need to throw it away. Yeah, we do have this information in our init scripts, but it already is being dropped on the way to .service files. One reason to use .service files is that someone else (e.g. RedHat) does the work of creating them. Just they don't need those dependencies. I am not sure that it is feasible to maintain this information on our own and keep it tested and working. > > * socket activation cont'd > > I guess that at some point services will expect that their sockets > > are already open when they are started, because this eliminates a > > privileged bind() operation. > > That would just mean that those don't work at all with sysv > anymore, and since I think we still have to support sysv, > we should fix them. The question here is: What is less work? Fixing N services to support sysv or creating a program that creates the environment that those N services expect? And how large is N? Also consider the insane amount of code duplication due to every service implementing daemonization on its own. (libdaemon0 has about 10 rdeps) One of the major reasons to go to either systemd or upstart was to get rid of that code, now we add it back for sysv? > I would argue that if such a conversion script would exist, we can > probably have more consistent init script implementations, and > less bugs in them. You appear to not be aware that such a thing does exist: https://github.com/akhilvij/systemd-to-sysvinit-converter > I'm also not sure why fixing a conversion script is that much > work. We currently have about 400 Arch:all packages shipping init scripts. Let me guess that at some point 1/4 would use such a conversion utility. Are you going to binNMU those 100 Arch:all packages? How to track such a transition when the converter will not end up in the runtime dependencies? Helmut -- 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/20130523062829.ga10...@alf.mars
