Re: Can insserv made better?
Gunnar Wolf writes (Re: Can insserv made better?): As it was already pointed out to you, such occurences were due to incomplete dependencies declared in the initscripts - And as such, they were bugs in the respective packages. The right way to fix them is to provide the needed dependency information in the startup scripts. That is the right way in the medium and long term for us as the developers to fix those problems, certainly. But in the short term, the right thing for a user to do is surely simply not to move their working system to insserv ? Yes, upgrades (specially upgrades of complex, production systems) should be faced with care and after having thoroughly studied the relevant release notes. Now, there is a real intention from Debian's part to getting out of the 1980s Sxx/Kxx scheme. It is an obsolete scheme, not suitable for our amount of packages, which had effectively been squished to much less because of the inability to declare what depended on what, and assuming a flat world. Dependency-based boot ordering gives important benefits to our users. What direct, concrete, benefit does the new arrangement give to the user on an existing working system being upgraded to squeeze ? Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19765.43522.760976.361...@chiark.greenend.org.uk
Re: Can insserv made better?
On Tue January 18 2011 06:56:02 Ian Jackson wrote: What direct, concrete, benefit does the new arrangement give to the user on an existing working system being upgraded to squeeze ? For some sysadmins insserv will simplify the process of managing startup dependencies. Therefore insserv should be available as an option for those sysadmins. For others, it will break systems. That is why the option should be accompanied by accurate and unbiased information outlining the relevant pros and cons. --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101181312.35277.mgb-deb...@yosemite.net
Re: Can insserv made better?
At the risk of contributing to what is already often an ill-tempered and unconstructive thread: Roger Leigh writes (Re: Can insserv made better?): You're saying that an unwieldy ad-hoc fixed list of numbers and names is superior to detailed dependency information? This is patently untrue. The ad-hoc fixed list of numbers does in some sense contain or represent some information which is not captured in the explicit dependencies. This is because the fixed list of numbers has been debugged (including, when irreconcilable problems arise due to different setups needing different orders, by having arguments about which setup is more common) to include a lot of dependencies which are not necessarily declared for the new scheme. Or to put it another way the fact that the new paradigm is more powerful and correct does not mean that the _actual data_ we are using is more correct. Indeed it seems that the actual data for the dependency-based setup is in many respects less good than the actual data for the old sequence with the result that arguably the _actual_ old sequence has fewer bugs than the _actual_ new dependencies. (Even though some of the old sequence's bugs cannot be fixed without introducing new ones.) Why are we insisting on the change to insserv being recommended by the debconf question ? It seems to me that we should be giving accurate guidance to the user about a decision that they are to make. That guidance is probably that: - On a simple system with default configuration, insserv will produce a faster boot and is unlikely to break, so is probably a good idea. - On a complicated or unusual system, insserv involves a significant risk of breakage which can be difficult to fix - and the change cannot be reverted. So it is not a good idea. Furthermore, why does this debconf question have such a high priority? High-priority questions should be used only for matters where there is no good default. But existing systems which are currently working will not be broken by doing the squeeze upgrade but not switching to insserv - so there is a perfectly good default, which is not to switch. Your (rejected) patch was not addressing the issue. Documenting the pros and cons of moving to dependency-based boot is entirely beside the point: we have moved to dependency-based boot. *Your* choice is not if to move, but when. [...] New installs get insserv by default. During the lifetime of squeeze we can hope that users of those new installs will file bugs for missing dependencies as they discover them. It seems to me that for existing installs, the best choice would be to wait _at least_ until after sqeeze. I can't say I'm the biggest fan of insserv myself, but that's what is currently supported, and if you want something different, then you'll need to step up and start doing the work yourself. I do hope we'll have systemd (preferred) or upstart post-squeeze, but I don't see /any/ value in returning to fixed-order scripts: No-one is suggesting returning to them, in the sense that no-one is suggesting that any system which has changed to insserv (and still works!) should be changed back. But perhaps it would be wise to review our choice of defaults in the light of our experience of the quality of the software ? we lived with their multitude of deficiencies for decades, and now we have a working solution to that. Your efforts would be best focussed on finding, fixing and reporting any issues which are causing you problems, not griping about decisions which were already taken. It was changed in July 2009 for crying out loud! You've had 18 months to report any issues? That some people here did not report and/or fix bugs, is no excuse for giving all of Debian's users suboptimal defaults. Even if not fixing bugs in insserv is somehow blameworthy, it isn't the users' fault. The failure of some people here to report and/or fix bugs is no excuse ramming through a hasty transition to software which may not be of acceptable quality. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19764.13849.75483.511...@chiark.greenend.org.uk
Re: Can insserv made better?
Mike Bird dijo [Sun, Jan 16, 2011 at 01:09:39PM -0800]: No, I'm saying that Snn/Knn values boot some systems where insserv fails. Therefore Snn/Knn is superior in some cases. I readily concede that insserv is superior in some cases. In order to avoid breaking Debian systems we should give people a balanced overview of the pros and cons rather than blindly telling them that insserv is recommended when it is unnecessary and may break their systems. I'm not asking for insserv to be removed. I'm asking that Debian users be given accurate information upon which to base their decisions rather than dangerously misleading information. As it was already pointed out to you, such occurences were due to incomplete dependencies declared in the initscripts - And as such, they were bugs in the respective packages. The right way to fix them is to provide the needed dependency information in the startup scripts. Yes, upgrades (specially upgrades of complex, production systems) should be faced with care and after having thoroughly studied the relevant release notes. Now, there is a real intention from Debian's part to getting out of the 1980s Sxx/Kxx scheme. It is an obsolete scheme, not suitable for our amount of packages, which had effectively been squished to much less because of the inability to declare what depended on what, and assuming a flat world. Dependency-based boot ordering gives important benefits to our users. And yes, benefits will sometimes require an experienced sysadmin to learn a new trick, scratch a bit his head. The change is worth a little re-learning. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117195524.gc23...@gwolf.org
Re: Can insserv made better?
On Mon January 17 2011 11:55:24 Gunnar Wolf wrote: As it was already pointed out to you, such occurences were due to incomplete dependencies declared in the initscripts - And as such, they were bugs in the respective packages. The right way to fix them is to provide the needed dependency information in the startup scripts. Were Debian to replicate all of the dependencies implicit in the Snn/Knn approach it would require enormous numbers of dependencies, most of which have no value for most users. OTOH, to omit any of those dependencies could cause a failure on some systems. You simply do not know and cannot know what dependencies are out in the world in the Snn/Knn approach, and which can safely be removed on any given system. That is why sysadmins should be able to decide if and when to enable insserv based on accurate and unbiased information. --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101171427.43947.mgb-deb...@yosemite.net
Re: Can insserv made better?
On Sun, Jan 16, 2011 at 2:47 AM, Mike Bird mgb-deb...@yosemite.net wrote: On Sat January 15 2011 16:33:28 Olaf van der Spek wrote: If insserv meses up so bad, shouldn't it be able to detect that things will go wrong too? insserv completely discards the Snn/Knn values and generates a new boot ordering based on much less information and which consequently fails more often. AFAIK insserv doesn't guess. Much less info is the dependencies listed in the scripts themselves, right? Isn't this enough? Is the problem insserv itself or wrong dependency lists? Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim6fe6be7lwnckidg9nudvnqtxqv8_mrijac...@mail.gmail.com
Re: Can insserv made better?
On Sat, Jan 15, 2011 at 05:47:24PM -0800, Mike Bird wrote: [...] Got a concrete example of a case that fails? We ran into the Apache-Bind problem and the RequestTracker-Apache-Mysql problems and then stopped using insserv. This one was reported and solved thanks to RT maintainers: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595054 [...] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110116143722.GT5713@localhost.localdomain
Re: Can insserv made better?
On Sun January 16 2011 04:40:02 Olaf van der Spek wrote: AFAIK insserv doesn't guess. Much less info is the dependencies listed in the scripts themselves, right? Isn't this enough? That is correct. However there are far fewer dependencies listed in the headers than implicit in the Snn/Knn numbers, so some but not all previously working systems are broken. Is the problem insserv itself or wrong dependency lists? The problem is wrong thinking. Snn/Knn implicitly contain many dependencies which are not needed on most systems, so they are not included in the scripts. However removing those dependencies breaks some but not all systems. That is why people should be given accurate information in order to be able to make an informed choice, instead of being tricked into using insserv and breaking their systems. I filed a bug[1] with a simple patch[2] to give people fair notice of the pros and cons of insserv but unfortunately Julien Cristau simply closed the bug without explanation[3]. --Mike Bird [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610185 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=sysv-rc-postinst-clarification.patch;att=1;bug=610185 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=7;bug=610185 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101161048.24614.mgb-deb...@yosemite.net
Re: Can insserv made better?
On Sat, Jan 15, 2011 at 05:47:24PM -0800, Mike Bird wrote: On Sat January 15 2011 16:33:28 Olaf van der Spek wrote: If insserv meses up so bad, shouldn't it be able to detect that things will go wrong too? insserv completely discards the Snn/Knn values and generates a new boot ordering based on much less information and which consequently fails more often. If you want insserv not to mess up then the solution a to have insserv generate dependencies from the Snn/Knn values and then allow sysadmins to delete/disable dependencies that aren't relevant. (I don't recommend this but it is a solution.) This is complete and utter rubbish. Please consider whether what you are writing is adding anything useful or constructive before wasting the time of all the people reading this list. This is factually incorrect, adds nothing new to the discussion, and the last paragraph is just provocative trolling. Bringing legitimate problems to our attention in a non-provocative and constructive manner is acceptable; pointless trolling is *not*. You're saying that an unwieldy ad-hoc fixed list of numbers and names is superior to detailed dependency information… This is patently untrue. But whatever you personally believe, the reality is that the broad consensus of the project has been to move to a dependency-based boot system, and this was done nearly *18 months* ago. At this point complaining will achieve nothing: if you find any remaining dependency issues the solution is to report bugs so that the issues are fixed. We *have* moved to a dependency-based boot system, and you really don't have a say in the matter at this point. It's *done*, and you'll have to live with it. Your (rejected) patch was not addressing the issue. Documenting the pros and cons of moving to dependency-based boot is entirely beside the point: we have moved to dependency-based boot. *Your* choice is not if to move, but when. I can't say I'm the biggest fan of insserv myself, but that's what is currently supported, and if you want something different, then you'll need to step up and start doing the work yourself. I do hope we'll have systemd (preferred) or upstart post-squeeze, but I don't see /any/ value in returning to fixed-order scripts: we lived with their multitude of deficiencies for decades, and now we have a working solution to that. Your efforts would be best focussed on finding, fixing and reporting any issues which are causing you problems, not griping about decisions which were already taken. It was changed in July 2009 for crying out loud! You've had 18 months to report any issues… Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Can insserv made better?
On Sun January 16 2011 12:49:20 Roger Leigh wrote: You're saying that an unwieldy ad-hoc fixed list of numbers and names is superior to detailed dependency information… This is patently untrue. No, I'm saying that Snn/Knn values boot some systems where insserv fails. Therefore Snn/Knn is superior in some cases. I readily concede that insserv is superior in some cases. In order to avoid breaking Debian systems we should give people a balanced overview of the pros and cons rather than blindly telling them that insserv is recommended when it is unnecessary and may break their systems. I'm not asking for insserv to be removed. I'm asking that Debian users be given accurate information upon which to base their decisions rather than dangerously misleading information. --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101161309.39302.mgb-deb...@yosemite.net
Re: Can insserv made better?
Hi, Mike: On Sunday 16 January 2011 19:48:24 Mike Bird wrote: [...] I filed a bug[1] with a simple patch[2] to give people fair notice of the pros and cons of insserv but unfortunately Julien Cristau simply closed the bug without explanation[3]. Regarding your patch, I find the first part of it being quite to the point while the second paragraph is unneeded as long as the information is included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be added to the package, maybe rewritten like this: This is an irreversible step. While it is recommended because It allows the boot process to be optimized for speed and efficiency providing a more resilient framework for development, it may not correctly transition in complex systems without further effort on your part. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101162240.58850.jesus.nava...@undominio.net
Re: Can insserv made better?
On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote: Regarding your patch, I find the first part of it being quite to the point while the second paragraph is unneeded as long as the information is included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be added to the package, maybe rewritten like this: This is an irreversible step. While it is recommended because It allows the boot process to be optimized for speed and efficiency providing a more resilient framework for development, it may not correctly transition in complex systems without further effort on your part. That's an excellent suggestion. Would you care to post it to #610185[1] to be sure the maintainer sees it? --Mike Bird [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610185 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101161437.20216.mgb-deb...@yosemite.net
Re: Can insserv made better?
Hi, Mike: On Sunday 16 January 2011 23:37:20 Mike Bird wrote: On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote: Regarding your patch, I find the first part of it being quite to the point while the second paragraph is unneeded as long as the information is included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be added to the package, maybe rewritten like this: This is an irreversible step. While it is recommended because It allows the boot process to be optimized for speed and efficiency providing a more resilient framework for development, it may not correctly transition in complex systems without further effort on your part. That's an excellent suggestion. Would you care to post it to #610185[1] to be sure the maintainer sees it? Done. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101170421.03984.jesus.nava...@undominio.net
Re: Can insserv made better?
Mike Bird schrieb: No, I'm saying that Snn/Knn values boot some systems where insserv fails. Therefore Snn/Knn is superior in some cases. Does insserv fail then because it is inherently unable to mimic the Snn/Knn behaviour or due to wrong (missing, ...) dependency info in the initscripts? If it's the latter, the right solution would be fixing the scripts, I think. -thh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ldd.1101170041@thorondor.akallabeth.de
Re: Can insserv made better?
On Sun January 16 2011 15:41:40 Thomas Hochstein wrote: Mike Bird schrieb: Does insserv fail then because it is inherently unable to mimic the Snn/Knn behaviour or due to wrong (missing, ...) dependency info in the initscripts? If it's the latter, the right solution would be fixing the scripts, I think. Nobody knows all the different configurations that are out there. To avoid all failures the initial insserv install would have to examine the system's Snn/Knn (not the script headers) and then create dependencies to replicate the same startup order. The sysadmin could later delete any dependencies she didn't want. I do not recommend this but it is the only solution to avoid all failures. A better solution is to avoid misleading sysadmins - to give them fair and balanced information so that they can decide if and when to enable insserv. --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101162305.52619.mgb-deb...@yosemite.net
Re: Can insserv made better?
Hi, Mike: On Saturday 15 January 2011 19:51:43 Mike Bird wrote: On Sat January 15 2011 01:59:06 Julien BLACHE wrote: insserv has issues, but it's still an improvement over the previous situation and, unlike the other new init systems, it's actually backward-compatible. I have no objection to you using insserv. I object to people being tricked into using insserv. It tends to break complex systems and people should be warned about this danger rather than being told that insserv is recommended and then making a bad decision based on sysv-rc.postinst's faulty recommendation. Well, we can try to be positive and change a lose for a win here, can't we? I'd say that insserv main problem now is that of transtition: yes, it can break your system in the worst possible way, making it unable to boot, specially if you happen to be a professional system administrator caring about complex Debian servers. But that's more a symptom of the problems of the old system which the new rises, than of the new system itself, and once your system is properly recovered, insserv tends to work properly (as it will work properly for newly installed systems) and it's expected to be easier to maintain for the years to come than the old one. So the main problem is only transitioning the system, isn't it? Why don't you have then a look at Squeeze's release notes (which any wise Debian system administrator will read upon upgrade) and make sure that it states the problem in the most clear way and/or propose the changes to that document that you percieve to be needed? That would be feasible in current freeze condition of the distribution and it would be a good effort/benefit ratio for your effort. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101152221.33941.jesus.nava...@undominio.net
Re: Can insserv made better?
Hi Jesús, On Sat January 15 2011 13:21:33 Jesús M. Navarro wrote: So the main problem is only transitioning the system, isn't it? Why don't you have then a look at Squeeze's release notes (which any wise Debian system administrator will read upon upgrade) and make sure that it states the problem in the most clear way and/or propose the changes to that document that you percieve to be needed? That would be feasible in current freeze condition of the distribution and it would be a good effort/benefit ratio for your effort. I have looked at the release notes, what little documentation there is, and much but not all of the source code. It would certainly help if a warning were included in the release notes but the most critical fix is to the misleading statement in sysv-rc.postinst that enabling insserv is recommended with no warning about the potential adverse consequences. I have attached a proposed patch. --Mike Bird diff -ruN sysvinit-2.88dsf/debian/sysv-rc.templates sysvinit-2.88dsf.NEW/debian/sysv-rc.templates --- sysvinit-2.88dsf/debian/sysv-rc.templates 2011-01-15 14:30:43.0 -0800 +++ sysvinit-2.88dsf.NEW/debian/sysv-rc.templates 2011-01-15 14:38:16.0 -0800 @@ -12,13 +12,18 @@ Default: true _Description: Migrate legacy boot sequencing to dependency-based sequencing? The boot system is prepared to migrate to dependency-based sequencing. - This is an irreversible step, but one that is recommended: it allows - the boot process to be optimized for speed and efficiency, and provides - a more resilient framework for development. + This is an irreversible step - restoring your /etc will not undo it. It + affords slightly faster booting and a different framework for sequencing + system start up which some people prefer. However it may not correctly + boot a complex system without further effort on your part. . A full rationale is detailed in /usr/share/doc/sysv-rc/README.Debian. If you choose not to migrate now, you can do so later by running dpkg-reconfigure sysv-rc. + . + If you do need to manually reverse this irreversible step first + touch /etc/init.d/.legacy-bootordering and then the files in + /var/lib/update-rc.d will help you to recover most of the way. Template: sysv-rc/unable-to-convert Type: note
Re: Can insserv made better?
On Sat, Jan 15, 2011 at 11:39 PM, Mike Bird mgb-deb...@yosemite.net wrote: I have looked at the release notes, what little documentation there is, and much but not all of the source code. It would certainly help if a warning were included in the release notes but the most critical fix is to the misleading statement in sysv-rc.postinst that enabling insserv is recommended with no warning about the potential adverse consequences. If insserv meses up so bad, shouldn't it be able to detect that things will go wrong too? Got a concrete example of a case that fails? Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=A1DBU10W5SQzeTq+0n0ybEX9Laf=h+8tqz...@mail.gmail.com
Re: Can insserv made better?
On Sat January 15 2011 16:33:28 Olaf van der Spek wrote: If insserv meses up so bad, shouldn't it be able to detect that things will go wrong too? insserv completely discards the Snn/Knn values and generates a new boot ordering based on much less information and which consequently fails more often. If you want insserv not to mess up then the solution a to have insserv generate dependencies from the Snn/Knn values and then allow sysadmins to delete/disable dependencies that aren't relevant. (I don't recommend this but it is a solution.) Got a concrete example of a case that fails? We ran into the Apache-Bind problem and the RequestTracker-Apache-Mysql problems and then stopped using insserv. Fortunately we have good sysadmins who can read the source code as insserv is mostly undocumented and there is no policy on which overrides are for Debian packagers and which are sysadmins so many future conflicts will arise there too. If you check on bugs.debian.org you'll see many more. I had to read through nearly 400 bugs on sysv-rc before submitting a proposed fix [1]. As we no longer enable insserv this is no longer a problem for us. It is, however, a big problem for Squeeze and it needs to be fixed. --Mike Bird [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610185 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101151747.24174.mgb-deb...@yosemite.net
