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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
Hi, On Freitag, 17. Januar 2014, Lars Wirzenius wrote: 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. while piuparts now indeed supports other virtualisation methods, no support for dealing with starting, stopping evaluating(!) daemons has been added yet. I wrote patches welcome already :) cheers, Holger signature.asc Description: This is a digitally signed message part.
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
On 16/01/14 06:09, Martin Pitt wrote: There's no practical way to drop sysv of course, at least as long as we have non-Linux ports. If maintainers are particularly keen to drop support for SysV, that encourages porters to go with either OpenRC or a port of Upstart. Then you could drop SysV support as long as your package has a native init definition for whichever of those is used on ports. Porters could test or even write that for you. On 16/01/14 09:03, Anthony Towns wrote: It's reasonable to semi-continuously test installation scripts for thousands of packages -- that's what piuparts does The modern init systems likely have a clearer idea of whether the daemon started successfully or not, so this seems to make sense. If tests can be run on every port, that would also catch daemon startup bugs that are not even due to the init script. A really nice dashboard may also show a diff of changes in the default init script, to keep track of when the others might need updating. Maybe that's similar to how translators' work is done. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 pgplLIq_I0lop.pgp Description: PGP signature
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Steven Chamberlain dixit: 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 I would like to express a preference for one init system that is able to do that to be supported. allows for some limited/controlled amount of concurrency to happen, for extra speed. I would like to express a *strong* preference for one init system that allows *disabling* parallel boot to be supported. Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
Martin Pitt mp...@debian.org writes: 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). One of the init systems is the *default*, and that's likely the only one that will see testing and quality that is up to debian's standards. 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. Then there are differences of course. On one hand, I imagine both upstart and systemd are more mature than the hurd, and they definitely have more users. And on the other hand, the needed porting to get a random daemon to work well with a new init system might be slightly more work than for porting the same random daemon to work on the hurd or kfreebsd. (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). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
ni...@lysator.liu.se (Niels Möller) writes: (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). If OpenRC proves to be of broad interest and becomes supported, at least at the non-default level, I doubt we would continue to support sysv without OpenRC for very long (quite possibly not even in jessie+1). My impression is that OpenRC provides a strict superset of sysv init script features in a way that's backwards-compatible, so the upgrade path from sysvinit only to sysvinit with OpenRC should be fairly smooth. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
On 15/01/14 21:48, Russ Allbery wrote: If OpenRC proves to be of broad interest and becomes supported, at least at the non-default level, I doubt we would continue to support sysv without OpenRC for very long [...] the upgrade path from sysvinit only to sysvinit with OpenRC should be fairly smooth. I do hope for something like this. Continuing to support SysV doesn't have to be a requirement. A comfortable transition away from SysV initscripts is possible, as long as native init definitions are provided for the official init system[s], and for whatever the ports have. (That's also why GNU/kFreeBSD and Hurd ought to pick the same). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Martin Pitt mp...@debian.org writes: 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). I think it would be helpful for the discussion if people would first define what they mean with support (and default), and then discuss whether it's desirable or not. Support could mean anything from packages not shipping init scripts using the full functionality of each available init systems are not accepted to the archive to packages of alternate init systems are allowed in the archieve, but integration has to be done completely by the local administrator. I'm pretty sure most people's opinions on whether Debian should support multiple init systems would be quite different for those two cases. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Bdale Garbee writes (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. Perhaps the resolution should have this stated prominently. I think supporting an init system X (whether X is the default or not) means that: - No non-init-system part of the system requires a particular init system to be in use - so the user has a free choice. - When a non-default init system is in use, functionality and correctness is at least equivalent to that provided by sysvinit. - There may however be degraded functionality, for example UIs to init system Y != X (or to features provided only by system Y) may be missing or nonfunctional. - Functionality and correctness improvements contributed by people who care about init system X are accepted by the project into whatever are the appropriate packages for that support. Or to put it another way: I think it should be made clear that we are committed to supporting at least upstart and systemd. Not just for jessie, but into the foreseeable future, as long as their communities remain healthy. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Hi Adrian, Adrian Bunk b...@stusta.de writes: 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. Agreed. Effectively, this puts a lot of burden on individual maintainers (and also on some external packagers) to test their packages with 2+ init systems and become familiar with how to properly mask units/handle diverting names, what features each system supports, what the best practices for each are, etc. Of course, to some degree, this also needs to happen when we transition. But having a one-time transition and doing something forever are two very different things, and I’d be really sad if we were to impose this kind of work on our contributors. 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? One could implement a GRUB boot menu (or multiple boot entries) or some sort of switcher, but the more important point about this is the synchronization of init system state, i.e. which units/scripts are enabled/disabled. The idea here is that if you disable lighttpd on sysvinit, it should not start when you reboot into systemd and vice versa. Having written deb-systemd-helper (shipped in the init-system-helpers package), I know very well how many corner cases and rough edges¹ are out there in that respect. deb-systemd-helper was written with the intention of getting rid of it after Debian switched to systemd. Supporting/using it indefinitely is certainly not a good idea, and I think this is not implementation-specific, but a general issue. In conclusion, I’d hate a situation where we’d support multiple init systems. I strongly recommend deciding for one init system. ① The mapping of service file names (and socket file names!) to init script names is just one of them, but a fairly obvious and easy to understand one. Note that there are Alias= directives in service files, too. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Adrian Bunk writes (Bug#727708: Bits from linux.conf.au): There are at least three tricky areas: 1. init systems will have to cope with packages supplying init scripts in several formats they support. Perhaps. I'm certainly not expecting to solve this problem in the general case in jessie. In jessie we'll do this by having each init fall back to sysvinit for packages which don't supply native support. That may well be suitable indefinitely. 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, Implicit in supporting multiple init systems is that such dependencies would have to be avoided. But that doesn't mean they have to work equally well - see my other message. 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.) And I don't mind very much if service disablement (or even to an extent service configuration) isn't translated. It's probably better to have the sysadmin redo that manually than have some kind of unreliable and complicated automatic scheme. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Michael Stapelberg writes (Bug#727708: Bits from linux.conf.au): Adrian Bunk b...@stusta.de writes: 1. init systems will have to cope with packages supplying init scripts in several formats they support. Agreed. Effectively, this puts a lot of burden on individual maintainers (and also on some external packagers) to test their packages with 2+ init systems and become familiar with how to properly mask units/handle diverting names, what features each system supports, what the best practices for each are, etc. 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. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Adrian Bunk b...@stusta.de writes: There are at least three tricky areas: 1. init systems will have to cope with packages supplying init scripts in several formats they support. This doesn't seem that tricky to me. If a package provides init functionality in the preferred native format for a given init system, that would take precedence over functionality provided in a supported but not preferred format, right? 2. How to ensure that both systemd systems and non-systemd systems work equally well? This for me immediately gets hung up in how one defines equally well, as expectations are clearly going to differ between init systems. 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. 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? 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. Bdale pgpEaOGLX2zf4.pgp Description: PGP signature
Bug#727708: Bits from linux.conf.au
On Tue, Jan 14, 2014 at 06:05:47PM +, Ian Jackson wrote: Michael Stapelberg writes (Bug#727708: Bits from linux.conf.au): Agreed. Effectively, this puts a lot of burden on individual maintainers (and also on some external packagers) to test their packages with 2+ init systems and become familiar with how to properly mask units/handle diverting names, what features each system supports, what the best practices for each are, etc. 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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Adrian Bunk writes (Bug#727708: Bits from linux.conf.au): 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. Then perhaps that's not the right answer. Do we really need to design a good solution to this problem right away ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
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. What is supposed to happen when I do apt-get install sysvinit-core? 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. Only one thing comes to mind when reading about supporting multiple init systems and how to switch between them: http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
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. And all such statements are mere parroting of systemd upstream propaganda. The interfaces that desktops require do not dictate an init system. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
On Tue, Jan 14, 2014 at 06:32:48PM +, Ian Jackson wrote: 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. And who is supposed to redirect the problem to the right community? User? Maintainer? Keep in mind that problems may be not easily debuggable and not trivial in general. Should I just ask user if he/she uses upstart/systemd and if so - just reassign bugreport to the right community? Everything more then this - will take maintainer's time more or less. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
There was a talk on January 08, 2014 at linux.conf.au Linux conference by Marc Merlin, Google server sysadmin and software engineer. Quoting the description [1]: This talk will look at how we upgraded our ancient linux distribution on all the Google production servers to a more modern one based on debian stripped down and built from source. In his talk [2] at 13:50 Marc briefly touched the init system choice question. Perhaps it's worth taking into account. [1] http://linux.conf.au/schedule/30014/view_talk?day=wednesday [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 -- Алексей Шилин
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
On 2014-01-13 13:15:07 +, Steven Chamberlain wrote: In the slides[0] 13 to 15, he summarises init systems something like: * SysV - simple, familiar and deterministic Deterministic? Well, the scripts may be started sequentially, but this doesn't mean that the daemons will be and always in the same order. And they don't, as shows in the following log: [...] Sat Dec 24 17:09:45 2011: Starting SpamAssassin Mail Filter Daemon: Starting Network connection manager: wicd. Sat Dec 24 17:09:50 2011: Starting OpenBSD Secure Shell server: sshd. Sat Dec 24 17:09:52 2011: spamd. [...] and still now (but less readable): (1) [...] Thu Aug 1 10:24:51 2013: Starting SpamAssassin Mail Filter Daemon: [] Starting Network connection manager: wicd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. Thu Aug 1 10:24:59 2013: [] Starting OpenBSD Secure Shell server: sshd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. Thu Aug 1 10:25:08 2013: spamd. Thu Aug 1 10:25:08 2013: [] Starting Postfix Mail Transport Agent: postfix^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. [...] (2) [...] Sun Aug 18 12:18:21 2013: Starting SpamAssassin Mail Filter Daemon: [] Starting OpenBSD Secure Shell server: sshd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. Sun Aug 18 12:18:26 2013: [] Starting Network connection manager: wicd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. Sun Aug 18 12:18:34 2013: spamd. Sun Aug 18 12:18:34 2013: [] Starting Postfix Mail Transport Agent: postfix^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. [...] In (1): spamd start wicd start/OK sshd start/OK spamd OK postfix start/OK In (2): spamd start sshd start/OK wicd start/OK spamd OK postfix start/OK This isn't deterministic at all. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
On 13/01/14 13:48, Vincent Lefevre wrote: On 2014-01-13 13:15:07 +, Steven Chamberlain wrote: In the slides[0] 13 to 15, he summarises init systems something like: * SysV - simple, familiar and deterministic Deterministic? Only the traditional SysV. Debian since squeeze uses startpar so will start *some* things concurrently (same Sxx number). And where that happens, it's much simpler to see/control it as files in /etc/rc2.d, than e.g. events being triggered and such. Well, the scripts may be started sequentially, but this doesn't mean that the daemons will be and always in the same order. 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. In (1): spamd start wicd start/OK sshd start/OK spamd OK postfix start/OK In (2): spamd start sshd start/OK wicd start/OK spamd OK postfix start/OK This isn't deterministic at all. I think that's just because insserv+startpar was being used here, not the traditional SysV. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Vincent Lefevre dixit: Well, the scripts may be started sequentially, but this doesn't mean that the daemons will be and always in the same order. And they don't, as shows in the following log: That’s due to the (now default with sysv-rc) use of parallel boot in combination with insserv. It used to be possible to still use sequential boot even with insserv, and file-rc enabled that auto‐ matically (which is why I kept using it even with insserv) but I don’t recall where the switch for sysv-rc is. If you disable “makefile-style concurrent whatever”, sysv-rc is deterministic even with insserv. bye, //mira“tys”bilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Thorsten Glaser t...@mirbsd.de writes: 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. If the daemon itself is ill-behaved, you generally have to do some additional work to make this happen beyond just writing a better init script. Well-behaved daemons will provide some synchronization point (not exiting in the parent until the daemon is started and ready, ideally, but this requires a pipe or some other method to coordinate, so more common is to have the child not write out its PID file until it's ready). If they don't, then it requires upstream patching, and can be tricky. This doesn't change across the various init systems, although upstart and systemd provide less tricky and racy ways of synchronizing than writing PID files. That said, most of the race conditions involved in the PID file approach are rare. Mostly you get into trouble if two copies of the process are started at the same time, particularly if they're racing each other to write the PID file. Synchronizing on the PID file is my personal preference for old-style daemons since it's so much easier to implement than controlling when the parent process exits. I *think* that start-stop-daemon properly implements PID-file-based synchronization based on the description of the --pidfile option, but I'm not positive and haven't checked the source. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.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 pgp4djWBVtYED.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
