On Fri, Jul 22, 2011 at 11:57 AM, Juliusz Chroboczek <j...@pps.jussieu.fr> wrote: >>>No, I don't think so. If these external tools double fork then they >>>are just wrong. > >> Double Forking has been the right way to do it for decades. > > It has been the default way for most daemons, granted. (Getty is > a notable exception.) > >> Demanding from upstreams that they change their software this >> fundamentally to cater for a new init system is [...] unrealistic > > Runit has been around for a decade or so. Most daemons known to me have > a command-line flag that prevents forking. > > Remember, preventing forking is about *removing* code from daemons, not > adding new code. Adding a flag to avoid forking is a trivial exercice, > and it's a rare upstream that will refuse the usually trivial patch.
Well, to be fair, preventing forking is *adding* code to parse the right option and skip the calls that do the double forking. It should be, though, a fairly simple change. >From what I've seen in Lennart's posts, adding systemd support doesn't seem to be too complicated. Some bigger changes may be required for more complex daemons. It's understandable that upstream might not accept them at first. In an hyphotetical scenario where systemd becomes the default init system in Debian, not having a systemd init file could be an overridable lintian warning or something like that. I'd like to stress that systemd apparently handles LSB scripts pretty well, even running them in parallel whenever possible. I find it perfectly natural that it'll take time for some upstreams to get confortable merging those patches. Package maintainers that prefer not to ship those patches could opt to ship a SysV init script instead. This backwards compatibility isn't going away in the foreseeable future. I also think it wouldn't be wise for an upstream to ignore systemd compatibility patches unless those require massive changes to the code (which could be a symptom of more serious upstream problems or perhaps bad design decisions). -- 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/canvyna83qdvm3x-6txuqbos0k_eqtec3-f_8dhx9a37pcqy...@mail.gmail.com
