Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
Hi, On Donnerstag, 16. Januar 2014, Anthony Towns wrote: it's not realistic for a porter to continously test startup scripts for thousands of packages. It's reasonable to semi-continuously test installation scripts for thousands of packages -- that's what piuparts does, and we have sponsored cloud resources to support that. It seems like that would be fairly straightforward to duplicate for testing packages with alternative init systems. piuparts has /sbin/policy.rc.d in place with the content of exit 0, IOW, it does not execute init scripts at all. Running, monitoring and killing arbitrary daemons is not trivial. Help and patches welcome! :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
On Fri, Jan 17, 2014 at 12:05:22PM +0100, Holger Levsen wrote: Hi, On Donnerstag, 16. Januar 2014, Anthony Towns wrote: it's not realistic for a porter to continously test startup scripts for thousands of packages. It's reasonable to semi-continuously test installation scripts for thousands of packages -- that's what piuparts does, and we have sponsored cloud resources to support that. It seems like that would be fairly straightforward to duplicate for testing packages with alternative init systems. piuparts has /sbin/policy.rc.d in place with the content of exit 0, IOW, it does not execute init scripts at all. Running, monitoring and killing arbitrary daemons is not trivial. Indeed. Early on in my original development of piuparts I realised that testing, in a chroot, code that starts arbitrary daemons is a bad idea in oh so many ways. I haven't followed piuparts development in recent years, so I don't know if it still uses chroot, but unless it's started using containers or virtual machines, it should continue to NOT allow init.d scripts to run. At all. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117111506.gd5...@mavolio.codethink.co.uk
Bug#727708: Bits from linux.conf.au
On 15 January 2014 20:36, Martin Pitt mp...@debian.org wrote: It's not realistic for a maintainer to continuously test three init systems; It's not realistic for a maintainer to continuously test against 13 architectures (including three different kernel trees) either. So we don't do that and instead let maintainers make their best effort when packaging, expect them to test locally, and then rely on porters and users to report bugs when there are problems. it's not realistic for a porter to continously test startup scripts for thousands of packages. It's reasonable to semi-continuously test installation scripts for thousands of packages -- that's what piuparts does, and we have sponsored cloud resources to support that. It seems like that would be fairly straightforward to duplicate for testing packages with alternative init systems. Cheers, aj -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajs_lcu0jw2cupw7bynnq2laxhdrzc4hbj8ouot9o9qpdfe...@mail.gmail.com
Bug#727708: Bits from linux.conf.au
Bdale Garbee [2014-01-16 8:44 -0700]: But having more than $DEFAULT and sysv just boils down to we can't make a decision. I understand your point, but the more I learn about OpenRC the more likely it seems to me that supporting it as an enhancement of sysvinit makes sense as the other init system than just sysvinit alone. Yes, I actually meant SysV init scripts, not necessarily the SysV init package itself; OpenRC still works with SysV init scripts AFAIUI, so from the point of view of package maintainers it doesn't lead to duplication in the same way as provide an upstart script AND a systemd unit AND a SysV init script does. Whether you choose to think of that as meaning we have 3 or 2 after a transition interval is debatable. Right, and I don't want to quibble over that. In that sense we already support classic sysvinit and startpar, but they don't use different startup scripts in packages. If your real point is pick systemd *or* upstart and don't try to assert that we should support both, I can easily agree with that. That indeed is my main point. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#727708: Bits from linux.conf.au
Le jeudi 16 janvier 2014 à 08:44 -0700, Bdale Garbee a écrit : I understand your point, but the more I learn about OpenRC the more likely it seems to me that supporting it as an enhancement of sysvinit makes sense as the other init system than just sysvinit alone. This assumes that OpenRC can be fixed to have parallel boot, otherwise this is a big regression from the current insserv setup. If your real point is pick systemd *or* upstart and don't try to assert that we should support both, I can easily agree with that. Amen. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389889104.28396.581.camel@dsp0698014
Bug#727708: Bits from linux.conf.au
Martin Pitt mp...@debian.org writes: But having more than $DEFAULT and sysv just boils down to we can't make a decision. I understand your point, but the more I learn about OpenRC the more likely it seems to me that supporting it as an enhancement of sysvinit makes sense as the other init system than just sysvinit alone. Whether you choose to think of that as meaning we have 3 or 2 after a transition interval is debatable. If your real point is pick systemd *or* upstart and don't try to assert that we should support both, I can easily agree with that. Bdale pgp2t2dCnyZen.pgp Description: PGP signature
Bug#727708: Bits from linux.conf.au
Bdale Garbee [2014-01-13 13:57 -0700]: Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow just too hard really haven't swayed me. The tricky bit, I think, is to define just what support means in the context of non-default init systems. I think that would be the worst possible (non-)decision that could be made. We already have more than enough bugs in Debian; officially trying to support 3 init systems is going to end up being a combinatorial explosion of testing and bugs, for no obvious benefit for the user (pick your set of bugs). It's not realistic for a maintainer to continuously test three init systems; it's not realistic for a porter to continously test startup scripts for thousands of packages. So I would expect the community for that init system to do the work is not a plan; it's a vague hope at best and not realistic at all in my opinion. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#727708: Bits from linux.conf.au
I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow just too hard really haven't swayed me. The tricky bit, I think, is to define just what support means in the context of non-default init systems. Too hard is a lousy defined thing. But it is an enormous amount of extra work added to all maintainers of packages with init $things. They basically get pressed into maintaining three widely different ways of starting their daemons. It's nice to say community of $system will support it, but does anyone really believe that whichever of the X (currently 3) communities commit to maintain their systems init $things in all our packages? Maybe in a very ideal world, but thats not where we are in. Likewise I think one can forget the porters of an arch to do so. The only way, IMO, to really support this way would be to come up with something like our menu support. The maintainer puts a metafile somewhere, triggers let the installed init system know there is something new, and it converts that metadata into a working init $thing. And the maintainers of init systems have to, similar like the window manager ones had to, come up with the converter metadata - init $thing. And yes, I realize that lets a lot to be desired. Starting with WTH to do with software that really needs one over the other systems? and a lot more points, which all had been mentioned times and again. As much as it may be hated, a clean decision this is it, the rest is officially not supported, no matter for which of the candidates the decision goes, is IMO the best for the project longterm. -- bye, Joerg Ubuntu: An ancient african word meaning I can't configure Debian signature.asc Description: PGP signature
Bug#727708: Bits from linux.conf.au
On Tue, Jan 14, 2014 at 11:19:38AM -0800, Steve Langasek wrote: On Tue, Jan 14, 2014 at 08:03:50PM +0100, Josselin Mouette wrote: Le mardi 14 janvier 2014 à 11:31 -0700, Bdale Garbee a écrit : If dependencies like installing GNOME enforces systemd as init system would be legal, then after a few more such dependencies it would turn out that systemd will be the only option available for virtually all users - and that all the hassle of supporting multiple init systems was a waste of effort. Please be careful about stacking assumptions like this. Equating GNOME to virtually all users completely ignores the vast number of Debian instances on servers, virtual machines, and embedded systems. And even if you only think about client systems, in my own circle of friends there's a lot more XFCE4 than GNOME these days. As their maintainers have stated, Xfce4 and KDE are most likely going to require systemd soon. There has been no such statement from the XFCE maintainers in this discussion. If you're really interested in the opinion of Xfce maintainers, it might be wise to add us to CC:. I try to look at the bug from time to time, but there's simply too much mails and it's running for too long, I just can't follow. I've added the pkg-xfce mailing list for that subthread, please keep things Xfce-related and drop the pkg-xfce list when needed. About systemd. Right now, Xfce in unstable doesn't have any systemd specific support. Actually, Xfce is pretty much unrelated to the init system. What Xfce uses right now is actually the PolicyKit/ConsoleKit, in order to manage: - power events in xfce4-power-manager (lid switch, power button) - power actions in xfce4-power-manager and xfce4-session (suspend, hibernate, shutdown/reboot), using upower - volume management (USB keys etc.) in Thunar and xfdesktop4, through gvfs and udisks *Right now*, it's perfectly possible to use Xfce without consolekit installed, but you will lose the above features (for shutdown and reboot there's actually a shutdown helper which can be run through sudo). Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained, and the recommended alternative is to use logind. That means in the future, it's likely that upstream Xfce will have to move away from consolekit. That's not something they really like, considering the support was added not so long ago, but there's not much choice, unless someone wants to maintain consolekit in the long run. And it seems that the only choice right now is to go with logind. No patch have already been merged for that, but there are patches for various components (xfce4-power-manager and xfce4-session mostly, since for Thunar it's actually done in gvfs and/or udisks, so we won't have a choice anyway). Those patches have mostly been contributed by distros who already use systemd/logind and have dropped consolekit, so they want the nice features back and a consistent environment. Right now I've refrained to integrate and upload them because I'm still waiting for the tech-ctte to decide on the issue. Because in the end (as I guess it's been already said multiple times on this bug), even though the stuff we'll most likely require in the future is in logind, it seems that there'll be no way to use it without systemd post-204 (but I might be wrong). And I have no idea what's the Xubuntu plan. TL;DR it's most likely Xfce upstream will move from consolekit to logind (and thus systemd) at one point. Not because they really like it, but because indeed everyone else is moving to it, and there's simply not enough manpower to rebuild the whole freedesktop.org stack. I hope (and some people in the Xfce developers community too) it won't be a hard dependency, and I guess it's likely that a non-logind Xfce will continue to work the same as a non-consolekit Xfce right now. Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140115211717.ga9...@scapa.corsac.net
Bug#727708: Bits from linux.conf.au
On 15/01/14 21:01, Joerg Jaspert wrote: Likewise I think one can forget the porters of an arch to do so. [...] As much as it may be hated, a clean decision this is it, the rest is officially not supported [...] If the decision were something like that, and only systemd were officially supported, don't expect porters of non-Linux arches to down tools and give up. We may have to drop lots of stuff if we can't get it working without systemd. But I expect we'd still put out a release (official or not) with some other compatible init system and our own init scripts for whatever we have to. I also think some people would care enough about running GNU/Linux without systemd, that we could combine our efforts in that case. I'd like to know as soon as possible if non-Linux ports ought to focus efforts on our existing SysV init, switching to OpenRC, or be trying to port Upstart. I'm personally undecided and the tech-ctte decision could easily sway my opinion on this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: Bits from linux.conf.au
Hey Yves-Alexis, Yves-Alexis Perez [2014-01-15 22:17 +0100]: Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained, and the recommended alternative is to use logind. To clarify, ConsoleKit has been deprecated for a while, and logind is the official successor (and roughly equivalent in terms of what a desktop environment needs from it). polkit is a different beast and is *not* deprecated; it has been switched over to use logind for checking is that process on an active foreground console, which it previously used ConsoleKit for. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116060405.ga21...@piware.de
Bug#727708: Bits from linux.conf.au
Niels Möller [2014-01-15 22:34 +0100]: Users should not select a non-default init system lightly. I think it's going to be a bit like using the non-default kfreebsd or hurd kernel. It's not for the average user who wants as much software as possible to work as well as possible. It's for the user who is curious, or really likes to use or hack that piece of software, or maybe hopes that it's going to replace the current default component sometime in the future. That's not something I'd call supported then. So either that non-default init system does get a certain amount of interest, and many maintainers add an init script for that system to their packages -- then there's the additional maintenance/testing/subpar quality problem for that. Or they don't, and then having that init system doesn't make much sense in the first place. (And it's going to be at least 4 init systems, not 3, right? systemd, upstart, sysv and openrc. With support for sysv possibly dropped after a few release cycles). There's no practical way to drop sysv of course, at least as long as we have non-Linux ports. So this is already 2, and that at least still has some technical justification. But having more than $DEFAULT and sysv just boils down to we can't make a decision. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116060937.ga21...@piware.de
Bug#727708: Bits from linux.conf.au
On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow just too hard really haven't swayed me. The tricky bit, I think, is to define just what support means in the context of non-default init systems. There are at least three tricky areas: 1. init systems will have to cope with packages supplying init scripts in several formats they support. 2. How to ensure that both systemd systems and non-systemd systems work equally well? If dependencies like installing GNOME enforces systemd as init system would be legal, then after a few more such dependencies it would turn out that systemd will be the only option available for virtually all users - and that all the hassle of supporting multiple init systems was a waste of effort. 3. Switching init systems after installation. Assume I am currently using systemd. What is supposed to happen when I do apt-get install sysvinit-core? Bdale cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114173644.gf1...@bunk.dyndns.info
Bug#727708: Bits from linux.conf.au
Sergey B Kirpichev writes (Re: Bug#727708: Bits from linux.conf.au): On Tue, Jan 14, 2014 at 06:05:47PM +, Ian Jackson wrote: I would expect the community for that init system to do the work. So the burden on maintainers ought to be minimal. All they ought to be required to do is ship the init-system-specific config thingy supplied by the community who are interested in that init system. That might even be done by NMU so the maintainer would often not have to do anything at all. Clearly, that's not the end of the job. systemd/upstart/whatever configs could be buggy as everything other. Currently, if maintainer provides sysv init script - he is responsible for related bugreports. Who is responsible for supporting this in your scheme? Or systemd/upstart configs supposed to be written once and work well forever? It seems to me that the community for the particular init system ought to fix this. It's obviously not practical to ask the maintainer to debug each of these scripts. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21205.33488.480274.856...@chiark.greenend.org.uk
Bug#727708: Bits from linux.conf.au
Bdale Garbee writes (Bug#727708: Bits from linux.conf.au): That's a great question. I suspect most of the effort in thinking about init system transitions so far has gone in to figuring out how to replace sysvinit. But if we're truly going to support alternatives, ensuring we have a robust mechanism for deciding which of several init systems that may be simultaneously installed is active and will control the next boot is clearly a requirement. Yes. I don't think this is particularly difficult, if we are relatively relaxed about our requirements. (For example, we don't require that daemon enablement is preserved across such a transition, and we don't require that daemon management works properly after such a transition has been initiated but not yet completed by a reboot.) Or to put it another way: obviously it has to be possible for people to switch, but I don't think it has to be easy. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21205.33891.354420.631...@chiark.greenend.org.uk
Bug#727708: Bits from linux.conf.au
Hello. On 01/14/2014 10:32 PM, Ian Jackson wrote: Sergey B Kirpichev writes (Re: Bug#727708: Bits from linux.conf.au): On Tue, Jan 14, 2014 at 06:05:47PM +, Ian Jackson wrote: I would expect the community for that init system to do the work. So the burden on maintainers ought to be minimal. All they ought to be required to do is ship the init-system-specific config thingy supplied by the community who are interested in that init system. That might even be done by NMU so the maintainer would often not have to do anything at all. Clearly, that's not the end of the job. systemd/upstart/whatever configs could be buggy as everything other. Currently, if maintainer provides sysv init script - he is responsible for related bugreports. Who is responsible for supporting this in your scheme? Or systemd/upstart configs supposed to be written once and work well forever? It seems to me that the community for the particular init system ought to fix this. It's obviously not practical to ask the maintainer to debug each of these scripts. IMHO, that means almost no support for the most of packages. -- Best regards, Dmitry, head of UNIX-tech department NRNU MEPhI, tel. 8 (495) 788-56-99, add. 8255 signature.asc Description: OpenPGP digital signature
Bug#727708: Bits from linux.conf.au
On Tue, Jan 14, 2014 at 06:03:33PM +, Ian Jackson wrote: Adrian Bunk writes (Bug#727708: Bits from linux.conf.au): ... 3. Switching init systems after installation. Assume I am currently using systemd. What is supposed to happen when I do apt-get install sysvinit-core? I think that if you want to switch init system after installation, I don't mind at all if you are expected to reboot. (With the possible exception of switching away from sysvinit.) ... I definitely expect that you have to reboot. The tricky part is how to reboot. With a naïve Breaks/Conflicts between the different init systems you would be calling the sysvinit reboot(8) with a running systemd init and with all files from systemd already removed. Ian. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114184029.gg1...@bunk.dyndns.info
Bug#727708: Bits from linux.conf.au
On Tue, Jan 14, 2014 at 11:31:09AM -0700, Bdale Garbee wrote: Adrian Bunk b...@stusta.de writes: ... If dependencies like installing GNOME enforces systemd as init system would be legal, then after a few more such dependencies it would turn out that systemd will be the only option available for virtually all users - and that all the hassle of supporting multiple init systems was a waste of effort. Please be careful about stacking assumptions like this. Equating GNOME to virtually all users completely ignores the vast number of Debian instances on servers, virtual machines, and embedded systems. And even if you only think about client systems, in my own circle of friends there's a lot more XFCE4 than GNOME these days. That's why I wrote after a few more such dependencies: GNOME is only the first case, and likely not the last case. When thinking about worst cases, I wonder how many non-systemd users would be left if udev (part of the systemd sources) would ever get a dependency on systemd being the init system... If you want to support multiple init systems, then something like Ian's proposal is really needed. And unless I misread it, that implies e.g. that Debian would also have to provide GNOME for people not using systemd as init system. ... Bdale cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114192741.gh1...@bunk.dyndns.info
Bug#727708: Bits from linux.conf.au
Steve Langasek vor...@debian.org writes: And all such statements are mere parroting of systemd upstream propaganda. The interfaces that desktops require do not dictate an init system. Please extend to your fellow Debian developers the courtesy of assuming that they arrive at their personal positions with the same care and thought that you use to arrive at yours. You may believe that they're wrong; that's fine, and by all means debate the point. But dismissing the opinions of other Debian developers as parroting or implying that they have not done any of their own research or drawn any of their own conclusions is arguing in bad faith. It's far more likely that they are simply weighing future risks differently than you are, or performing different cost/benefit analyses. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874n56uyv5@windlord.stanford.edu
Bug#727708: Bits from linux.conf.au
Hello. On 01/13/2014 03:57 PM, Алексей Шилин wrote: In his talk [2] at 13:50 Marc briefly touched the init system choice question. Perhaps it's worth taking into account. [2] http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/71-Live_upgrading_many_thousands_of_servers_from_an_ancient_RedHat_7.1_to_a_10_year_newer_Debian_-_Marc_MERLIN.mp4 [2] is placed in Australia, so I've mirrored it to [3]. [3] http://mirror.mephi.ru/other/2014/71-Live_upgrading_many_thousands_of_servers_from_an_ancient_RedHat_7.1_to_a_10_year_newer_Debian_-_Marc_MERLIN.mp4 I hope this will be useful for somebody. -- Best regards, Dmitry, head of UNIX-tech department NRNU MEPhI, tel. 8 (495) 788-56-99, add. 8255 signature.asc Description: OpenPGP digital signature
Bug#727708: Bits from linux.conf.au
On Mon, Jan 13, 2014 at 12:15:02PM +, Thorsten Glaser wrote: Алексей Шилин dixit: In his talk [2] at 13:50 Marc briefly touched the init system choice question. Can you please provide a transcript, for those among us who do not watch any video? This talk in article format: http://marc.merlins.org/linux/talks/ProdNG-LCA2014/Paper/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140113124350.ga21...@darkstar.order.hcn-strela.ru
Bug#727708: Bits from linux.conf.au
On 13/01/14 12:15, Thorsten Glaser wrote: Алексей Шилин dixit: In his talk [2] at 13:50 Marc briefly touched the init system choice question. Can you please provide a transcript, for those among us who do not watch any video? In the slides[0] 13 to 15, he summarises init systems something like: * SysV - simple, familiar and deterministic * Upstart - fast boot, makes sense on laptops, but inherently racey * systemd - interesting concept, but too disruptive/complex to buy into Then he gives a preference for Debian's own insserv and startpar. It allows for boot order to be fixed (after running insserv once, the same /etc/rc2.d/Sxx numbering may be rsync'd out to many machines). startpar allows for some limited/controlled amount of concurrency to happen, for extra speed. For servers, their priority is in reliability/reproducibility of boot (especially for pre-deployment testing), as the machines are so rarely rebooted, and engineer time to debug any boot problem is so costly. It's worth mentioning their boot is customised already for their environment. Before the root filesystem is mounted, there seems to be some centralised logging, and an sshd started in the initrd, for human or automated intervention in case the machine doesn't finish booting. That may have pushed them in favour of a simpler init system. [0]: http://marc.merlins.org/linux/talks/ProdNG-LCA2014/ProdNG.odp Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d3e6db.9040...@pyro.eu.org
Bug#727708: Bits from linux.conf.au
Steven Chamberlain writes (Bug#727708: Bits from linux.conf.au): Then he gives a preference for Debian's own insserv and startpar. It allows for boot order to be fixed (after running insserv once, the same /etc/rc2.d/Sxx numbering may be rsync'd out to many machines). startpar allows for some limited/controlled amount of concurrency to happen, for extra speed. I think that what this shows is how valuable it is for our downstreams that Debian is flexible and doesn't impose a particular approach. I'm coming round to the view that we should be planning to support multiple systems indefinitely. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21203.59708.160009.777...@chiark.greenend.org.uk
Re: Bug#727708: Bits from linux.conf.au
Steven Chamberlain dixit: Actually, even if they forked in the same order every time, they might not be *ready* in the same order. That would be the rationale for readiness protocols and other features of the more complex init systems. Strong disagree. This actually is a bug in the initscripts in question that they return before the service is operational. Fixing this does not require exchanging PID 1 at all. In fact, there was some posting on Planet Debian where someone used #!/path/to/some-initscriptwriting-helper instead of shell for them. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (268 (291) bugs: 0 RC, 188 (204) IN, 80 (87) MW, 0 FP) ‣ src:dash (89 (106) bugs: 2 RC, 43 (49) IN, 44 (55) MW, 0 FP) ‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1401131414090.25...@herc.mirbsd.org
Bug#727708: Bits from linux.conf.au
Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow just too hard really haven't swayed me. The tricky bit, I think, is to define just what support means in the context of non-default init systems. Bdale pgpVSTN_p1_Qt.pgp Description: PGP signature
Bug#727708: Bits from linux.conf.au
On 13/01/14 20:57, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow just too hard really haven't swayed me. The tricky bit, I think, is to define just what support means in the context of non-default init systems. IIRC, when kfreebsd became a release goal for squeeze, there was some policy that certain fixes were allowed to be handled as RC bugs, especially during the freeze. That allowed porters to potentially get something NMUd or unblocked if it was important to getting things working on that system. Could each proposed/approved init system for jessie be handled like this, generally? The respective teams would contribute the necessary work to make sure things work with that system. Maintainers would need to accommodate reasonable changes (mostly adding native init scripts) if they haven't already. That to me sounds enough like 'supporting' an init system. After committing to such goals, once the work really gets underway, any specific disagreements between teams over how to do things or what's reasonable, could be handled separately as they arise, and escalated to the ctte where necessary? It wouldn't matter to me which is ultimately chosen as the default in that case, if I only knew I wouldn't be wasting my time working on a particular init system. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
