Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On Sun, Feb 16, 2014 at 10:19:24PM +0100, Wouter Verhelst wrote: On Sun, Feb 16, 2014 at 03:28:30PM +0400, Sergey B Kirpichev wrote: Kevin Chadwick ma1l1i...@yahoo.co.uk: Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? I wouldn't be surprised if rc.local has been around longer than Debian and is meant to run at the end. Particularly for a service that isn't packaged it may be useful and expected to run last. Why you can't just write a regular init-script to start (and stop!) this service? rc.local is not flexible to this. Doesn't matter. rc.local is an interface that has been around since forever, and which is *meant* for local admins to use. But not to abuse this interface and use one in a wrong way. Whether it is flexible or not may be true, but is irrelevant for this discussion. No, we should not depend on it for Debian; but we should provide the interface for system administrators who wish to use it, because it is not Debian's place to tell them that they cannot use that interface. The point is that I'm aware about such drawbacks of using Should-Start/Should-Stop $all for monit, but I don't see a better solution. -- 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/20140218100036.ga19...@darkstar.order.hcn-strela.ru
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
previously on this list Matthias Urlichs contributed: discussion. No, we should not depend on it for Debian; but we should provide the interface for system administrators who wish to use it, because it is not Debian's place to tell them that they cannot use that interface. It's not our place to tell people that they _cannot_ use it, but it's a good place to add a consider writing a .service file if you start daemons here; read the XXX manpages to learn more. I agree but more than that why should I waste my time, I have no intention of ever writing a .service file or anything much longer than one-liners else I'd say that something is wrong in one of a few places and most likely the program design. I get the plus of my scripts running on any system, even Windows or a c loop embedded device. Plus I stop services with the likes of pkill as when service stop fails I would prefer to know how anyway and can use them on any system or with any favourite of myself or others whether it's monit, nagios etc. etc. or any shell. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/879291.41062...@smtp141.mail.ir2.yahoo.com
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On Tue, Feb 18, 2014 at 02:00:36PM +0400, Sergey B Kirpichev wrote: On Sun, Feb 16, 2014 at 10:19:24PM +0100, Wouter Verhelst wrote: On Sun, Feb 16, 2014 at 03:28:30PM +0400, Sergey B Kirpichev wrote: Kevin Chadwick ma1l1i...@yahoo.co.uk: Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? I wouldn't be surprised if rc.local has been around longer than Debian and is meant to run at the end. Particularly for a service that isn't packaged it may be useful and expected to run last. Why you can't just write a regular init-script to start (and stop!) this service? rc.local is not flexible to this. Doesn't matter. rc.local is an interface that has been around since forever, and which is *meant* for local admins to use. But not to abuse this interface and use one in a wrong way. It's not abuse. It cannot be abuse! It is an interface that is meant for the local administrator to use. It is trivially easy to support, and many many _many_ local admins will use it for whatever they want to. And that's fine, because that is _exactly_ what it's for. It is not Debian's place to decide what is the right or the wrong way for local administrators to use. Debian ships an empty rc.local file, and expects a local administrator to have fun using it. I will agree with you that bypassing the init script system and just dumping hundreds of lines in rc.local is a bad idea. But if a local administrator decides that this is what they want to use, then by all means they should use it. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/20140218202944.ga23...@grep.be
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On Tue, Feb 18, 2014 at 09:29:44PM +0100, Wouter Verhelst wrote: On Tue, Feb 18, 2014 at 02:00:36PM +0400, Sergey B Kirpichev wrote: On Sun, Feb 16, 2014 at 10:19:24PM +0100, Wouter Verhelst wrote: Doesn't matter. rc.local is an interface that has been around since forever, and which is *meant* for local admins to use. But not to abuse this interface and use one in a wrong way. It's not abuse. It cannot be abuse! It is an interface that is meant for the local administrator to use. It is trivially easy to support, and many many _many_ local admins will use it for whatever they want to. And that's fine, because that is _exactly_ what it's for. It is not Debian's place to decide what is the right or the wrong way for local administrators to use. Debian ships an empty rc.local file, and expects a local administrator to have fun using it. I will agree with you that bypassing the init script system and just dumping hundreds of lines in rc.local is a bad idea. But if a local administrator decides that this is what they want to use, then by all means they should use it. And please do not break it, or you'll have hordes of sysadmins with torches and pitchforks after you. I for one tend to write a whole /etc/init.d/ script for a minor at-boot task[1], but I'd join the lynch mob because I see it being used everywhere and _I_ would have to fix some resulting breakage. So whatever init system you ship, please execute rc.local, mm'kay? [1]. With IIRC two exceptions. One just to run df /dev/null, the reason that's not a no-op involving a noisy disk and slow spin-up. -- A tit a day keeps the vet away. -- 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/20140218212020.ga31...@angband.pl
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Hi, Wouter Verhelst: discussion. No, we should not depend on it for Debian; but we should provide the interface for system administrators who wish to use it, because it is not Debian's place to tell them that they cannot use that interface. It's not our place to tell people that they _cannot_ use it, but it's a good place to add a consider writing a .service file if you start daemons here; read the XXX manpages to learn more. Well, just my two cents: There are other (IMHO) legitmiate uses for rc.local _except_ starting daemons. For example I (mis)use it to tweak flashcache settings after booting is complete or on my Raspberry Pi (used DLNA media renderer) to play a jingle to indicate boot complete, you may now interact -- 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/e24b34a9ad4f59de2acdaa76822c0bc4.squir...@isengard.is-a-geek.net
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Kevin Chadwick ma1l1i...@yahoo.co.uk: Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? I wouldn't be surprised if rc.local has been around longer than Debian and is meant to run at the end. Particularly for a service that isn't packaged it may be useful and expected to run last. Why you can't just write a regular init-script to start (and stop!) this service? rc.local is not flexible to this. -- 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/20140216112830.ga15...@darkstar.order.hcn-strela.ru
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On Sun, Feb 16, 2014 at 03:28:30PM +0400, Sergey B Kirpichev wrote: Kevin Chadwick ma1l1i...@yahoo.co.uk: Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? I wouldn't be surprised if rc.local has been around longer than Debian and is meant to run at the end. Particularly for a service that isn't packaged it may be useful and expected to run last. Why you can't just write a regular init-script to start (and stop!) this service? rc.local is not flexible to this. Doesn't matter. rc.local is an interface that has been around since forever, and which is *meant* for local admins to use. Whether it is flexible or not may be true, but is irrelevant for this discussion. No, we should not depend on it for Debian; but we should provide the interface for system administrators who wish to use it, because it is not Debian's place to tell them that they cannot use that interface. of course, if it would be difficult to provide rc.local functionality in a given init system, then that would be a different matter entirely, in which case it might make sense to stop providing rc.local functionality; but I doubt that is the case, since rc.local is just a script, and calling it when everything else has been started should be ridiculously easy in any init system. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/20140216211924.gb6...@grep.be
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Hi, Wouter Verhelst: discussion. No, we should not depend on it for Debian; but we should provide the interface for system administrators who wish to use it, because it is not Debian's place to tell them that they cannot use that interface. It's not our place to tell people that they _cannot_ use it, but it's a good place to add a consider writing a .service file if you start daemons here; read the XXX manpages to learn more. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
previously on this list Sergey B Kirpichev contributed: Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? I wouldn't be surprised if rc.local has been around longer than Debian and is meant to run at the end. Particularly for a service that isn't packaged it may be useful and expected to run last. It seems perfectly logical for a user to expect a local service or command to run last ie as if a user did so after boot up. The special hurd case should run after rc.local as a special case perhaps an include ./rc.local.oddball. The arguments online of services should be shutdown gracefully in case they have problems on the next bootup by upstart and systemd seems to be nonsense. On OpenBSD you have rc.shutdown but in any case if the system dies or crashes, plug pulled etc., then services should start just fine on reboot or be re-written rather than being flaky rubbish In fact in that case abusing rc.local means a higher likelihood of testing for and removing flaky services or fixing bugs before that annoying time of things breaking which almost always happens at the worst time possible. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/863947.50998...@smtp124.mail.ir2.yahoo.com
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Le 6 févr. 2014 14:37, Thomas Goirand z...@debian.org a écrit : On 02/06/2014 07:06 PM, Petter Reinholdtsen wrote: Since last summer, OpenRC has full support for LSB headers. Also, I believe that OpenRC is the only init system replacement which allows to mix dependencies with LSB or it's own implementation. That is not the case. Both systemd and upstart allow this as well. I knew that both systemd and upstart can use LSB header scripts. But I read that upstart (at least) would launch these only at the end of the boot process, not mixing them in the boot order with upstart jobs. Can any Upstart specialist (Steve maybe?) can tell if this is right or wrong? What is systemd doing exactly with the LSB dependencies? With OpenRC, what happens is that the LSB headers are transformed into the internal syntax of OpenRC (eg: use, need, after, provide, etc.), which makes it possible to have LSB header scripts be integrated within the ordering calculation, just as if they were native OpenRC runscripts. They are also involved in the dependency loop breaking system that has recently been added to OpenRC. BTW, Debian has a way too many LSB header scripts with Required-Start: $all, which is very bad. A decent init system has to deal with this, and there's no sane way to do so but arbitrarily breaking what the author of the script wrote. A lintian warning telling that $all is just bad would be a very nice thing. Please report it against Lintian. I will fix it. Bastien How does systemd upstart deal with this pile of garbage that Required-Start: $all is? Cheers, Thomas -- 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/52f38ff3.7010...@debian.org
The meaning of $all in init.d scripts dependencies (Was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))
[Tollef Fog Heen] I'm pointing out why $all doesn't do what you want. «$all» means «after everything else has started» and if you have two of those, you have a loop. Loops are bugs. That is a common misunderstanding of what $all means, and probably the reason why insserv, systemd and openrc handle it differently. $all was introduced by SuSe in the insserv package, which Debian also uses to order init.d scripts, and for me that mean insserv is the one defining what $all mean. The $all facility is not defined in the LSB 3.1.0. In insserv, $all means after all scripts not depending on $all. This is how it has been used in the two only distributions where the facility has been in use (Debian and SuSe - are there others?). I thus suspect most or all init.d scripts in Debian today are based on how insserv uses $all to order init.d scripts, given that this has been the reference implementation when dependencies were introduced in init.d scripts. A better definition of $all, which to me make more sense than the current definition in insserv, and which I suspect also would be less confusing, could be all scripts not depending directly or indirectly on $all. This would allow scripts depending on $all to also depend on each other, and ensure correct ordering also in this case. According to Tollef, systemd simply ignore $all, inserting scripts with that dependency as if $all were not present. And according to Thomas, OpenRC assume scripts depending on $all also depend on other scripts depending on $all, conclude there is a loop and try to break the loop at some random point in the perceived loop. If I understand correctly, Upstart leave it to insserv to order init.d scripts. Here are some examples how this will lead to incorrect ordering. Given scripts A, B and C, where B depend on $all and C depend on $all, both the correct order would be (A, B, C) and (A, C, B) - both are correct, B and C can be started in parallel. systemd can end up with the ordering (B, A, C), (C, B, A), (B, C, A) and (C, A, B) in addition to the correct ones, because it ignore $all and there are no other dependencies to take into account. OpenRC see a dependency loop B - C - B and will break it at a random point, ending by chance up with on of the correct orderings. Luckily there are not too many scripts with $all listed as its dependency. But those that use it, really need to run after most of the scripts in the boot sequence, without being able to list them all. rc.local is one example, which by definition should be among the last scripts to run. -- Happy hacking Petter Reinholdtsen -- 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/2fl61orqntp.fsf...@ulrik.uio.no
Re: The meaning of $all in init.d scripts dependencies (Was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))
On 02/07/2014 05:22 PM, Petter Reinholdtsen wrote: And according to Thomas, OpenRC assume scripts depending on $all also depend on other scripts depending on $all, conclude there is a loop and try to break the loop at some random point in the perceived loop. That is correct, however, the way it is done currently, it does approximately what one would expect in Debian! :) Anyway, that's not a clean implementation. So, thanks a lot for this definition matching sysv-rc. So this may lead to newer code. The author of lsb2rcconf (eg: Dmitry Yu Okunev) will work on it. What will be done is scanning all LSB header scripts for $all, and fix the conversion to the OpenRC internal format (at least that's what he wrote on IRC). Cheers, Thomas Goirand (zigo) -- 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/52f4b801.7010...@debian.org
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Sergey B Kirpichev skirpic...@gmail.com writes: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. The question is, before or after rc.local? -- 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/86ha8avpsh@moguhome00.in.awa.tohoku.ac.jp
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On Sat, Feb 08, 2014 at 01:41:18AM +0900, hero...@gentoo.org wrote: Sergey B Kirpichev skirpic...@gmail.com writes: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. The question is, before or after rc.local? Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? On Sat, Feb 08, 2014 at 01:43:59AM +0900, hero...@gentoo.org wrote: Sergey B Kirpichev skirpic...@gmail.com writes: So, lets start services first, then start monitoring. Do we want to play races with sysvinit? No. Now can you see the point? We don't have to race it: by telling service managers other than monit (sysvinit, openrc, sysv-rc, etc. etc.) to leave what monit concerns alone can do the trick. Yes, that's easy. For human. -- 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/20140207181402.ga12...@darkstar.order.hcn-strela.ru
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On 02/06/2014 07:06 PM, Petter Reinholdtsen wrote: Since last summer, OpenRC has full support for LSB headers. Also, I believe that OpenRC is the only init system replacement which allows to mix dependencies with LSB or it's own implementation. That is not the case. Both systemd and upstart allow this as well. I knew that both systemd and upstart can use LSB header scripts. But I read that upstart (at least) would launch these only at the end of the boot process, not mixing them in the boot order with upstart jobs. Can any Upstart specialist (Steve maybe?) can tell if this is right or wrong? What is systemd doing exactly with the LSB dependencies? With OpenRC, what happens is that the LSB headers are transformed into the internal syntax of OpenRC (eg: use, need, after, provide, etc.), which makes it possible to have LSB header scripts be integrated within the ordering calculation, just as if they were native OpenRC runscripts. They are also involved in the dependency loop breaking system that has recently been added to OpenRC. BTW, Debian has a way too many LSB header scripts with Required-Start: $all, which is very bad. A decent init system has to deal with this, and there's no sane way to do so but arbitrarily breaking what the author of the script wrote. A lintian warning telling that $all is just bad would be a very nice thing. How does systemd upstart deal with this pile of garbage that Required-Start: $all is? Cheers, Thomas -- 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/52f38ff3.7010...@debian.org
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
]] Thomas Goirand BTW, Debian has a way too many LSB header scripts with Required-Start: $all, which is very bad. A decent init system has to deal with this, and there's no sane way to do so but arbitrarily breaking what the author of the script wrote. A lintian warning telling that $all is just bad would be a very nice thing. How does systemd upstart deal with this pile of garbage that Required-Start: $all is? $all obviously (as you point out) doesn't work well. Semantically, it doesn't make sense to have more than one script depending on $all. IIRC, systemd just ignores it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d2j0qpw9@xoog.err.no
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
$all obviously (as you point out) doesn't work well. Semantically, it doesn't make sense to have more than one script depending on $all. What I should use instead? Use case: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. -- 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/20140206145958.ga9...@darkstar.order.hcn-strela.ru
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
]] Sergey B Kirpichev $all obviously (as you point out) doesn't work well. Semantically, it doesn't make sense to have more than one script depending on $all. What I should use instead? Use case: http://packages.qa.debian.org/m/monit.html That's not a use case. Usually, you want to start this service last and stop first. Why should it start last? (Stopping first I can see the point of, to avoid spuriously restarting a daemon that's just been shut down, but it should probably then just integrate with the init system so it knows if the system is about to shut down and then avoid restarting daemons.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/878utoqnru@xoog.err.no
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Usually, you want to start this service last and stop first. Why should it start last? Because monit is not systemd. monit - is only an utility for proactive monitoring, not yet another init-replacement. So, lets start services first, then start monitoring. Do we want to play races with sysvinit? No. Now can you see the point? but it should probably then just integrate with the init system so it knows if the system is about to shut down and then avoid restarting daemons. The above use case is just a simplest example of such integration. It's sysvinit responsibility to start/stop monit as appropriate. -- 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/20140206155156.gb18...@darkstar.order.hcn-strela.ru
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On 02/06/2014 10:59 PM, Sergey B Kirpichev wrote: $all obviously (as you point out) doesn't work well. Semantically, it doesn't make sense to have more than one script depending on $all. What I should use instead? Use case: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. Let's say you want to run monit in Hurd, then it must *not* start last. The last one must always be the hurd console. Thomas -- 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/52f3bdec.8050...@debian.org
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
]] Sergey B Kirpichev Usually, you want to start this service last and stop first. Why should it start last? Because monit is not systemd. monit - is only an utility for proactive monitoring, not yet another init-replacement. So, lets start services first, then start monitoring. Do we want to play races with sysvinit? No. Now can you see the point? An init system that doesn't handle the case of something going «please start $service» when it's already in the process of starting that service, is buggy. but it should probably then just integrate with the init system so it knows if the system is about to shut down and then avoid restarting daemons. The above use case is just a simplest example of such integration. It's sysvinit responsibility to start/stop monit as appropriate. Sure, worst case is that monit, in the middle of shutting down, requests a service start which won't ever happen (because the machine will be shut down by then). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/871tzgqev4@xoog.err.no
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
An init system that doesn't handle the case of something going «please start $service» when it's already in the process of starting that service, is buggy. It's not the problem, as all (most) debian's init-scripts use start-stop-daemon. The real problem - email notifications. You don't want them while normal system startup, but if you start monit in the middle of system initialization - you will got them. Are you trying to sell me yet another init or do you suggest some alternative solution *with* Debian's sysvinit, not using Should-Start/Stop: $all? If the first, please stop. If the second - please go ahead. -- 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/20140206191501.ga18...@darkstar.order.hcn-strela.ru
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
]] Sergey B Kirpichev Are you trying to sell me yet another init or do you suggest some alternative solution *with* Debian's sysvinit, not using Should-Start/Stop: $all? If the first, please stop. If the second - please go ahead. No. I'm pointing out why $all doesn't do what you want. «$all» means «after everything else has started» and if you have two of those, you have a loop. Loops are bugs. In your particular case (and sysvinit), I'd say the admin should just add dependencies on the monit script for the monitored services since I don't think sysvinit support dynamically generating those dependencies on boot. (If it does, I'm sure somebody will chime in with how to do it for sysvinit.) With systemd, I'd say a generator that adds After+Wants: $monitored_services would be the right (and better) solution (this would also solve the shutdown problem). I assume upstart has a reasonable way to solve this, but I'm not familiar with what it should be. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87txccovwy@xoog.err.no
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Excerpts from Tollef Fog Heen's message of 2014-02-06 11:58:37 -0800: ]] Sergey B Kirpichev Are you trying to sell me yet another init or do you suggest some alternative solution *with* Debian's sysvinit, not using Should-Start/Stop: $all? If the first, please stop. If the second - please go ahead. No. I'm pointing out why $all doesn't do what you want. «$all» means «after everything else has started» and if you have two of those, you have a loop. Loops are bugs. In your particular case (and sysvinit), I'd say the admin should just add dependencies on the monit script for the monitored services since I don't think sysvinit support dynamically generating those dependencies on boot. (If it does, I'm sure somebody will chime in with how to do it for sysvinit.) With systemd, I'd say a generator that adds After+Wants: $monitored_services would be the right (and better) solution (this would also solve the shutdown problem). I assume upstart has a reasonable way to solve this, but I'm not familiar with what it should be. Correct me if I'm wrong, but there are basically two problems. 1) Some services are fragile and will behave badly if started before some explicit services (nfsd needs nis-things running if nis is in use) 2) Some services are meant to be started after the system has reached a steady state (monit, cron, etc). For (1), upstart uses an upstart job I wrote, called wait-for-state. This should be built into upstart, but ENOROUNDTUITS. You basically put this in your pre-start: pre-start exec start wait-for-state WAITER=$JOB WAIT_FOR=thingtowaitfor This job will wait for the job if it is starting, or start it if it is stopped, but can work in reverse for stopping/stopped things as well. This works fairly reliably, but it is somewhat confusing. Ideally upstart would just have a 'while' condition instead of or in addition to 'start on'. It is, btw, a myth that Upstart is not state based. It is, it just makes it a huge PITA to actually use the state it tracks quite nicely. For (2), the system startup itself needs some re-working from the way Ubuntu has done it and upstart works in Debian. Right now, you basically have carefully orchestrated plumbing events that lead up to the system reaching the default runlevel. At that point, we go into hyper-parallel mode because most daemons should be: start on runlevel [2345] stop on runlevel [016] This works fine for things like apache and mysql, because they can start in parallel and if your web app doesn't work for a few seconds while mysql gets its stuff together oh-well. Trying really hard to get all of the relationships right for all of the daemons in Debian is not going to work well. There is no reason that anything that normally communicates over the network should ever assume its dependent services are already up. For the things that matter a lot, the wait-for-state method exists. But for monit, we want to start after basically everything, so we go after sysvinit is completely done: start on stopped rc RUNLEVEL=[2345] stop on starting rc RUNLEVEL=[016] This will at least start those things after mysql and apache are starting, but rc is not blocked on them being _started_. To do that, one just needs to create some grouping jobs like this: --/etc/init/network-services.conf-- start on runlevel [2345] stop on runlevel [016] description All Network Services --end-- Then all the jobs that used runlevel just migrate to this: start on starting network-services stop on stopped network-services Aside from making more sense to humans, that would allow things like monit to say: start on started network-services stop on stopping network-services This is just one of those things that requires time, and only fixes really subtle bugs. -- 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/1391718159-sup-4...@fewbar.com
Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
I'm pointing out why $all doesn't do what you want. It's exactly what I want. «$all» means «after everything else has started» and if you have two of those You have a bug. Yes, some packages abuse $all, I admit this, but not all of them (e.g. monit). In your particular case (and sysvinit), I'd say the admin should just add dependencies on the monit script for the monitored services since I don't think sysvinit support dynamically generating those dependencies on boot. (If it does, I'm sure somebody will chime in with how to do it for sysvinit.) AFAIK, this can be done with /etc/insserv/overrides/ That is not a problem *for human* to add a file in /etc/insserv/overrides/ and override monit's LSB-headers. With systemd, I'd say a generator that adds After+Wants: The problem is not the mechanisms, like after+wants, not the output format for this generator (systemd stuff or LSB-headers) - but the generator itself. So, I don't buy this solution, sorry. -- 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/20140206221006.gb22...@darkstar.order.hcn-strela.ru
Re: Process spervision with Monit support in init systems (was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))
On 02/07/2014 03:58 AM, Tollef Fog Heen wrote: ]] Sergey B Kirpichev Are you trying to sell me yet another init or do you suggest some alternative solution *with* Debian's sysvinit, not using Should-Start/Stop: $all? If the first, please stop. If the second - please go ahead. No. I'm pointing out why $all doesn't do what you want. «$all» means «after everything else has started» and if you have two of those, you have a loop. Loops are bugs. In your particular case (and sysvinit), I'd say the admin should just add dependencies on the monit script for the monitored services since I don't think sysvinit support dynamically generating those dependencies on boot. (If it does, I'm sure somebody will chime in with how to do it for sysvinit.) With systemd, I'd say a generator that adds After+Wants: $monitored_services would be the right (and better) solution (this would also solve the shutdown problem). I assume upstart has a reasonable way to solve this, but I'm not familiar with what it should be. The only viable solution is to integrate monit support inside the init system, like what's currently happening in OpenRC: http://qnikst.github.io/posts/2013-11-06-openrc-supervision.html with patch available here: https://github.com/qnikst/openrc/compare/s-vision Note that it is on my todo list to evaluate this patch, but I didn't have the time to do that work yet. Any contribution would be welcome from anyone willing to test it, and see if it integrates well with the current OpenRC package. Note that this has verry little to do with *process* supervision, like it would be done with s6 (http://skarnet.org/software/s6/) which is also on the OpenRC upstream todo list. Cheers, Thomas Goirand (zigo) -- 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/52f44bac.70...@debian.org
