Re: [DNG] Init scripts in packages
Simplification of init scripts can be done by replacing them with a text file containing the following: a) preliminary logic tests to verify whether daemon can be started b) command to start daemon together with parameters c) command to stop daemon with parameters if applicable Only two lines will do as init scripts have essentially always the same skeleton. Basically, they are some preliminary logic tests followed by a case statement. A generic executable can do execute these the above following the same skeleton as init scripts. 'a' can be done away with if daemon dependency management is somehow provided. On 07/08/2015, Miles Fidelman wrote: > Alexey Rochev wrote >> *Date: *2015-08-05 07:29 -400 >> *To: *dng >> *Subject: *[DNG] Init scripts in packages >> Currently Debian packages contains both systemd units and init scripts. >> However, Debian developers refused to support several init systems. So >> it's >> only a matter of time when they remove init scripts from packages. >> What will Devuan developers do when it happens? We can use sysvinit and >> Devuan because these init scripts exist. > > It occurs to me that nobody raised the obvious questions: > > 1. Are we seeing upstream developers shipping systemd scripts, or > systemd scripts w/o sysv init scripts? I'm not sure I have. > 2. What the heck are Debian developers (packagers, actually), doing > removing init scripts? > > Me, I've been installing key packages from upstream sources for years - > avoids having to deal with out-of-date packages and such. (The basic > environment is certainly easier to install and maintain via apt - but > key production packages, hell no.) > > Miles Fidelman > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. Yogi Berra > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Miles Fidelman writes: > Alexey Rochev wrote >> *Date: *2015-08-05 07:29 -400 >> *To: *dng >> *Subject: *[DNG] Init scripts in packages >> Currently Debian packages contains both systemd units and init scripts. >> However, Debian developers refused to support several init >> systems. So it's >> only a matter of time when they remove init scripts from packages. >> What will Devuan developers do when it happens? We can use sysvinit and >> Devuan because these init scripts exist. > > It occurs to me that nobody raised the obvious questions: > > 1. Are we seeing upstream developers shipping systemd scripts, or > systemd scripts w/o sysv init scripts? I'm not sure I have. > 2. What the heck are Debian developers (packagers, actually), doing > removing init scripts? There's an answer to that and it's "it doesn't matter" (I tried to point that out in an earlier reply). On the wheezy system I'm using to write this, 'init scripts' make up 6789 LOC, nobody has the power to make them disintegrate and I'd be very much surprised if there are more than 2000 LOC in there which actually do something useful. Actually, I expect yes. init scripts should be trivial and if they're not, something else is amiss. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Hi, sorry for picking up on this edge while the thread's general discussion has advanced further. The "status" command matters to me; that is why I would like to address its handling in a more detailed manner. Laurent Bercot wrote on 06/08/2015 at 14:21 CEST: [...] And "status". This is very service-dependent: since there is no global API, no service manager, scripts will query the daemon's status in a daemon-specific way. More vagueness again, because "status" doesn't define exactly what you should say, and the lowest common denominator is "is it alive?" but even for this basic check, daemon-specific interfaces are used. [...] From the discussion in this thread so far, I can determine at least the following two problems with "status": #1 There are not just plain, singular-per-service "daemons" involved (extreme, but valid examples include programs hosted inside application servers, even more extreme is a cumulative service called "networking" that might involve all sorts of stuff to be done), and #2 not all softwares that are providing "services" provide "specific interfaces" to query them even for a most basic information on them being "alive" or not. I personally am, however, a fan of simple semantics, and it is my understanding that UN*X has always done well when it provided simple semantics: * Simple semantics are good for implementing simple scripts. * Simple scripts that have means to implement difficult setups make such environments favorable for engineers, auditors and economists alike. I do understand SystemD's approach as one of trying to enforce an API into all that is capable of providing "service". The goal is that such software is required to, by design, provide a mechanism to report on something called a "status", and that "status" is one of (I use an own unofficial terminology here): * The status is "off" (the service is not alive, and this is not due to the service having failed at a previous attempt to run it), * the status is "on" (the service is alive), or * the status is "failed" (the service is alive, and this is due to it having failed to start on a previous attempt to do so). My question is, did I understand that correctly? Before engaging further into a discussion, I want to determine if my assumptions are right or wrong. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Apologies, a typo: I wrote myself on 07/08/2015 at 15:21 CEST: [...] * the status is "failed" (the service is *NOT* alive, and this is due to it having failed to start on a previous attempt to do so). My question is, did I understand that correctly? [...] Kind regards. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup
On 07/08/2015 14:58, Rainer Weikusat wrote: There's obviously a TOCTOU race here because "A is ready now" doesn't mean "A is still ready" at any later time. Of course. That's why you need a supervisor to receive death notifications and publish them to whomever subscribes. If there's something B can't do without A, it can't do that but it should try to cope as good as possible, be it only by retrying until A becomes available or delaying any 'expensive steps' until A became availabe. That's why you run B under a supervisor: worst case, it will be retried. This does not preclude optimizing the common case, which is "A will succeed at some point, don't try starting B before that point". But since the whole situation is hypothetical, this is nothing but a speculation. It may be hypothetical to you, but it's very real to some people. It has been very real to me in a few professional environments. start-stop-daemon is a less ambitious "solve everything somehow related to process startup in one program" (or a set of tightly coupled programs) and that's something I consider to be the wrong approach. So do I. | daemon chdir / monitor -n ca-server u-listen -g $GROUP -m g -l "$SOCKET" ca-server I agree with your script skeleton, except on this line. Here, your instance of "monitor" is forked by your script. It can behave differently when you run your script by hand from when it is run at boot time. Also, "monitor" itself is not monitored; if it dies, you can't control ca-server anymore. And despite you not believing in dependencies, this is important. If "daemon" or "monitor" do not support readiness notification and return as soon as their child is spawned, ca-server may not be ready when your script returns, and if some ca-client is started right afterwards, it will fail. True, it will be restarted by "monitor" until it succeeds, but it's polling that can be avoided by proper dependency management. As someone else pointed out, the control flow code could be abstracted away into some kind of 'universal init script' and individual ones would just need to define the start and stop commands. That, or they may need to define service directories for a supervision system. Just sayin'. 1) Keep a relatively simple init which kicks off execution of commands in response to 'change the system state' request and nothing else (get rid of as much of /etc/inittab as possible at some point in time) 2) Generally, keep the run-level directories, but with better management tools. 3) Keep using the shell for everything it can easily handle. It's a highly-level programming language capable enough of handling the job. "But I don't want to learn an additional programming language, especially not one which looks like THIS and was designed in the 1970s!" is not a sensible reason for discarding it. Programming has its fashions and fads, just like everything else, but since "90% of everything is crap" 'new stuff' is mainly going to be just as bad as 'old stuff', only in a yet unknown way. 4) Provide the acutally missing features, ie "demonstrably required ones" in form of additional tools which integrate with the existing system. You keep hammering that down as if 1), 2), 3) and 4) were not obvious to me. Would it be possible for you to stop feeling threatened by what I'm saying and realize that we're after the same goals, so we can have some constructive discussion ? If you can't, I'll simply let you argue in front of a mirror and go back to coding. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
I'm not sure how systemd does it, but in my vision, there should be two different states for the service: the *wanted* state, and the *current* state. The wanted state is what is set by the administrator when she runs a command such as "rc thisrunlevel". The command should set all the services in "thisrunlevel" in the "wanted up" state. The current state is exactly what it says: is the service actually alive or not, ready or not? A service manager's job is to perform service state transitions until the current state matches the wanted state - or an unrecoverable error happens, in which case the admin should have easy access to the current state in order to diagnose and fix the problems. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Rainer Weikusat wrote: Miles Fidelman writes: Alexey Rochev wrote *Date: *2015-08-05 07:29 -400 *To: *dng *Subject: *[DNG] Init scripts in packages Currently Debian packages contains both systemd units and init scripts. However, Debian developers refused to support several init systems. So it's only a matter of time when they remove init scripts from packages. What will Devuan developers do when it happens? We can use sysvinit and Devuan because these init scripts exist. It occurs to me that nobody raised the obvious questions: 1. Are we seeing upstream developers shipping systemd scripts, or systemd scripts w/o sysv init scripts? I'm not sure I have. 2. What the heck are Debian developers (packagers, actually), doing removing init scripts? There's an answer to that and it's "it doesn't matter" (I tried to point that out in an earlier reply). On the wheezy system I'm using to write this, 'init scripts' make up 6789 LOC, nobody has the power to make them disintegrate and I'd be very much surprised if there are more than 2000 LOC in there which actually do something useful. Actually, I expect yes. init scripts should be trivial and if they're not, something else is amiss. Well... it kind of does, if the idea is to leverage Debian package repos as much as possible. Right now, init script come from upstream, Debian "developers" (I really can't bring myself to call a packager a developer) test & tweak the upstream scripts to fit the Debian environment. If they stop doing that, someone is going to have to do that for Devuan. Worse, if "refuse to support multiple init systems" means that the Debian packagers start stripping out the init scripts from Debian packages, those, those packages become useless in Devuan. (Note: I did a little checking re. packages re. code that I use - postfix doesn't seem to ship systemd files, nor does sympa; Apache puts its systemd support in a module; mysql has to compiled -WITHSYSTEMD --- judging from that small sample, it seems to me that we're going to see more and more Debian packages that won't work with other init systems). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup
Laurent Bercot writes: [...] >> 1) Keep a relatively simple init which kicks off execution of commands in >> response to 'change the system state' request and nothing else (get >> rid of as much of /etc/inittab as possible at some point in time) [...] > You keep hammering that down as if 1), 2), 3) and 4) were not obvious > to me. Would it be possible for you to stop feeling threatened by what > I'm saying and realize that we're after the same goals, so we can have > some constructive discussion ? If you can't, I'll simply let you argue > in front of a mirror and go back to coding. I do not know how you came up with the idea that "me wasting my time trying to explain something to you don't want to listen to" would result in any benefit to me, but I assure you, "it ain't so.". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
tilt! writes: [...] > Laurent Bercot wrote on 06/08/2015 at 14:21 CEST: >> [...] >> And "status". This is very service-dependent: since there is no >> global API, no service manager, scripts will query the daemon's >> status in a daemon-specific way. More vagueness again, because >> "status" doesn't define exactly what you should say, and the lowest >> common denominator is "is it alive?" but even for this basic check, >> daemon-specific interfaces are used. >> [...] > > From the discussion in this thread so far, I can determine at least > the following two problems with "status": > > #1 There are not just plain, singular-per-service "daemons" > involved (extreme, but valid examples include programs > hosted inside application servers, even more extreme > is a cumulative service called "networking" that might > involve all sorts of stuff to be done), and > > #2 not all softwares that are providing "services" provide > "specific interfaces" to query them even for a most > basic information on them being "alive" or not. > > I personally am, however, a fan of simple semantics, and it is > my understanding that UN*X has always done well when it provided > simple semantics: [systemd status] > * The status is "off" (the service is not alive, and this >is not due to the service having failed at a previous >attempt to run it), > * the status is "on" (the service is alive), or > * the status is "failed" (the service is alive, and this >is due to it having failed to start on a previous attempt >to do so). > > My question is, did I understand that correctly? Short reply because I have a bunch of grotty Java-code I need to deal with: off/ on/ failed is an ill-defined notion someone pulled out of his posterior while thinking about the issue 'in abstract' (eg, does dpkg --remove mean 'off'). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup
Good grief . . . this is turning into some sort of battle of the titans . . . would be nice to take the egos down a notch . . . On Fri, 8/7/15, Rainer Weikusat wrote: Subject: Re: [DNG] ideas for system startup To: dng@lists.dyne.org Date: Friday, August 7, 2015, 10:19 AM Laurent Bercot writes: [...] >> 1) Keep a relatively simple init which kicks off execution of commands in >> response to 'change the system state' request and nothing else (get >> rid of as much of /etc/inittab as possible at some point in time) [...] > You keep hammering that down as if 1), 2), 3) and 4) were not obvious > to me. Would it be possible for you to stop feeling threatened by what > I'm saying and realize that we're after the same goals, so we can have > some constructive discussion ? If you can't, I'll simply let you argue > in front of a mirror and go back to coding. I do not know how you came up with the idea that "me wasting my time trying to explain something to you don't want to listen to" would result in any benefit to me, but I assure you, "it ain't so.". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Miles Fidelman writes: > Rainer Weikusat wrote: >> Miles Fidelman writes: >> >>> Alexey Rochev wrote *Date: *2015-08-05 07:29 -400 *To: *dng *Subject: *[DNG] Init scripts in packages Currently Debian packages contains both systemd units and init scripts. However, Debian developers refused to support several init systems. So it's only a matter of time when they remove init scripts from packages. What will Devuan developers do when it happens? We can use sysvinit and Devuan because these init scripts exist. >>> It occurs to me that nobody raised the obvious questions: >>> >>> 1. Are we seeing upstream developers shipping systemd scripts, or >>> systemd scripts w/o sysv init scripts? I'm not sure I have. >>> 2. What the heck are Debian developers (packagers, actually), doing >>> removing init scripts? >> There's an answer to that and it's "it doesn't matter" (I tried to point >> that out in an earlier reply). On the wheezy system I'm using to write >> this, 'init scripts' make up 6789 LOC, nobody has the power to make them >> disintegrate and I'd be very much surprised if there are more than 2000 LOC >> in there which actually do something useful. Actually, I expect >> yes. init scripts should be trivial and if they're not, something else >> is amiss. [...] > Right now, init script come from upstream, Debian "developers" (I > really can't bring myself to call a packager a developer) test & tweak > the upstream scripts to fit the Debian environment. If they stop > doing that, someone is going to have to do that for Devuan. Do they actually come 'from upstream'? When debianizing a package via dh_make, one of the debian/ template files generated by it is 'something which should become your init script'. This suggests that 'the Debian scripts' ultimatively come from the respective package maintainers (who may have written them or may have gotten a working script from elsewhere and adapted that). In any case, they'll be part of the Debian-specific package files afterwards. Also, to re-iterate this: What an init script needs to do is really only 'start a process'/ 'stop a process'. Most of the other code which crept in there during the last 15 - 20 years will fall into one of two categories 1) Never did anything useful 2) Should never have been implemented in this way. This is a non-tempest in a teapot nobody ever really saw. > Worse, if "refuse to support multiple init systems" means that the > Debian packagers start stripping out the init scripts from Debian > packages, those, those packages become useless in Devuan. Last time I looked, the point of Apache was "it's a web server" and not "it comes with an init script" so this seems to have been blown somewhat out of proportion. Even if 'Debian developers' should stop shipping 'init scripts' as part of their packages at some point in time in the future, this won't cause them to disappear from packages people already installed. And even in the extremely unlikely case to $evil_debian_developper invades your computer in the middle of the night and steals $mission_critical_init_script (this happening simultaneously on all computers in the world), they'll be trivial to replace. This is actually such an absurd idea that I have some trouble considering it a serious concern (no disrespect intended --- I'm a developer and this seems 'a trifle' to me but maybe not to everybody else). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
- Original Message - > From: "Rainer Weikusat" > Miles Fidelman writes: >> Worse, if "refuse to support multiple init systems" means that the >> Debian packagers start stripping out the init scripts from Debian >> packages, those, those packages become useless in Devuan. > > This is actually such an absurd idea that I have some trouble > considering it a serious concern (no disrespect intended --- I'm a > developer and this seems 'a trifle' to me but maybe not to everybody > else). I get that an init script is very minor compared to the software it starts/stops. The problem, though, is one of scale. If the handful of people who work on Devuan suddenly have to create init scripts for hundreds or thousands of packages, that job will take a long time. Even if it's just a matter of finding an old init script and verifying that it works. That said, I am doubtful that this scenario will happen. But even if it did, it would not be an insurmountable problem. It would be a big pain in the neck, though. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] multichannel audio i/o management w/o pulse/dbus
richard white wrote: > I have use OSS4 on a few machine and have been very satisfied, but not a > lot with multichannel. I appreciate the separate volume controls for each > application, > > Maybe this could help: > http://manuals.opensound.com/developer/multichannel.html Glad to hear that OSS4 works for you. I look forward to experimenting with it on my new installation (currently blocking on problems getting it to boot.) FWIW, if you need a stereo to 5.1 converter or something similar, we have one for Ecasound, developed by Patrick Shirkey. And also in Nama, an Ecasound-based DAW. Hope you can find a way to get what you want. The Linux Audio Users list is the authoritative forum. > Also, here's is some good information for supporting OSS (Although a little > old): > http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html thanks for posting this. cheers, Joel > -Rich > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Unmingling kdbus and the Linux kernel
If I might add my two cents a few days late, I really do not think that kdbus matters overly much and that people (including myself in the past) have assigned too much concern to the topic. Kdbus is little more than an implementation of dbus, which is a fairly neutral protocol. The concern of course is that kdbus might mean the use of systemd. I personally do not believe that we have cause for concern. Linux is used in many areas were the use of systemd simply is not appropriate, such as embedded Linux devices. As long as there are commercial interests funding Linux developers in providing a working version of the kernel sans systemd, then we have nothing to worry about. I don't think that Linus T. is going to let kdbus into the kernel mainline anytime soon, and if he does, it will remain optional. Thanks T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
>James Powell Thu, 06 Aug 2015 01:02:56 -0700 >Currently Debian packages contains both systemd units and init scripts. >However, Debian developers refused to support several init systems. So it's >only a matter of time when they remove init scripts from packages.What will >Devuan developers do when it happens? We can use sysvinit and Devuan because >these init scripts exist Honestly? I think that it is a "no brainer" as my brothers would say. I do agree, but with a proviso. I think that System 5 init scripts will disappear from Debian packages while systemd becomes the Debian standard. Please do not think badly of me when I say this, but the subject has been "beat to death" many times in the past on the DNG list. On many occasions I've commented that I think init scripts should be provided entirely separate from the other files that Debian bundles them with, so that the user might select whatever init they want to use. I see no technical reason why Devuan cannot detect whatever init is installed and then select the appropriate init scripts as a package or meta-package. The majority of the repository is applications - which have nothing to do with the init process, so it would only be a limited number of upstream Debian packages that would have to be modified or replaced in this way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GTK (was Will there be a MirDevuan \"WTF\"?)
Roger, I haven't had a chance, but I wanted to thank you for your insights regarding C++ last month. I've not used it as a "main language" in some time. I was coding in C++ long before smart pointers were introduced. Old habits die hard I suppose. Your comments made me reconsider many things, and encouraged me to review what I knew on the subject. While I still think that C++ has some design flaws, and smart pointers are not a perfect solution, you are right - they do mitigate a number of problems. Anyway, I just wanted to say "thank you" and I hope we have many more useful discussions in the future. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup (was: Init scripts in packages)
On Fri, Aug 07, 2015 at 01:58:19PM +0100, Rainer Weikusat wrote: > As someone else pointed out, the control flow code could be abstracted > away into some kind of 'universal init script' and individual ones would > just need to define the start and stop commands. And there's nothing > horrible about that because anything which can't easily be done with the > Bourne shell language is supposed to provided in from of a 'process/ > service management command' written in C which can be used as part of a > complex service invocation command (the one not mentioned so far creates > a listening AF_UNIX stream socket and executes a program for each > connection --- much like inetd but with the 4.2BSD "have to get the > number of processes down, the kernel can't handle that many" > optimizations). > > The general idea would be > > 1) Keep a relatively simple init which kicks off execution of commands in >response to 'change the system state' request and nothing else (get >rid of as much of /etc/inittab as possible at some point in time) This is something that systemd did, and one of the things about it that really ticked me off. Let me provide a couple of examples: 1. One of the things I did when playing with debian jessie was to install a virtual machine which would be accessed only via serial console and ssh (this is a real use case for me). I discovered that there is no /etc/inittab in debian jessie! Second, I discovered that while I can remove agetty on tty1, I can't do so on tty2-tty6, because systemd insists I should have a login console wherever possible. 2. I want ctrl+alt+del to do shutdown -h, instead of shutdown -r (another real use case on another virtual system). I couldn't figure out a way to do this in debian jessie. Now, what you proposed above from what I understand should work for my first example. The admin would do something like tty1.agetty stop, followed by tty1.agetty disable. Nice, simpler then open inittab in an editor, and commenting out lines, followed by telinit q. However, I don't see how your proposal above would deal with defining what ctrl+alt+del does per my second example. Handling such events isn't as simple as starting/stopping a daemon with a universal init script. Since you mentioned getting rid of most of inittab but not all of it, would ctrl+alt+del be one of the things you envision inittab still being useful for? Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup (was: Init scripts in packages)
On Friday, August 07, 2015 05:06:14 PM Gregory Nowak wrote: > 2. I want ctrl+alt+del to do shutdown -h, instead of shutdown -r > (another real use case on another virtual system). I couldn't figure > out a way to do this in debian jessie. > > Now, what you proposed above from what I understand should work for my > first example. The admin would do something like tty1.agetty stop, > followed by tty1.agetty disable. Nice, simpler then open inittab in an > editor, and commenting out lines, followed by telinit q. However, I > don't see how your proposal above would deal with defining what > ctrl+alt+del does per my second example. Handling such events isn't > as simple as starting/stopping a daemon with a universal init > script. Since you mentioned getting rid of most of inittab but not all > of it, would ctrl+alt+del be one of the things you envision inittab > still being useful for? > Greg, I am just curious, but did you try installing sysvinit and systemd-shim? Theoretically, it should give you System 5 startup and shutdown, while keeping compatibility with things that depend on systemd, like Gnome. I haven't actually looked if it installs an old fashioned Debian inittab, but it might be worth a shot. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup (was: Init scripts in packages)
On Fri, Aug 07, 2015 at 07:25:50PM -0500, T.J. Duchene wrote: > I am just curious, but did you try installing sysvinit and systemd-shim? > Theoretically, it should give you System 5 startup and shutdown, while > keeping > compatibility with things that depend on systemd, like Gnome. No. If it was just a matter of doing without inittab, I might have done that. As we know though, systemd takes over more than just that, and I didn't like this either. I also did do an aptitude search sysv when I had debian jessie freshly installed, but didn't get a match. If I could have installed sysvinit or sysvinit-core in a fresh installed, I might have tried that just to see what I got. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup (was: Init scripts in packages)
On Friday, August 07, 2015 05:46:00 PM Gregory Nowak wrote: > > I also did do an aptitude search sysv when I had debian jessie freshly > installed, but didn't get a match. If I could have installed sysvinit > or sysvinit-core in a fresh installed, I might have tried that just to > see what I got. =( Bummer! There must be a way to get what you want, although I honestly do not know enough about systemd to help you out. Like yourself, I am more familiar with the System 5 way of doing things. Wish I could be more help. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup (was: Init scripts in packages)
On Fri, Aug 07, 2015 at 07:53:37PM -0500, T.J. Duchene wrote: > =( Bummer! > > There must be a way to get what you want, although I honestly do not know > enough about systemd to help you out. Like yourself, I am more familiar with > the System 5 way of doing things. > > Wish I could be more help. Thanks, I appreciate the sentiment and willingness to help. I actually got a lot of useful advice from a number of folks here, and have found the various discussions to be quite interesting. If it wasn't for systemd, that might not have happened! I actually don't mind dropping gnome. It does depend on systemd by defacto, and is bulky. I did try xfce in a fresh install of debian jessie, and found it gave me speech when I rebooted after the install. It also is more snappy than gnome, and felt more like gnome2 for me, which I didn't mind. This gives me hope that I should find xfce useable in devuan. The only thing I'm not sure about is the slim login manager. I was able to get speech in the graphical login manager debian jessie provides when installing the xfce task, but I didn't investigate what that manager is. I did plan to do another fresh install of debian jessie in a virtual machine, install slim (if it is there), and see what happens, but I didn't get around to that yet. In the worst case scenario, I should be able to disable the graphical login manager from starting in devuan, and should be able to just use startx from a text console when I need the GUI. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On Thu, Aug 06, 2015 at 05:14:28PM +0200, Laurent Bercot wrote:
> On 06/08/2015 16:31, Isaac Dunham wrote:
> >If differences in environment can cause problems, it's a problem with
> >design. A program that changes what it does just due to differences
> >between the init environment and a login environment is going to be
> >hard to debug.
>
> There are tons of those, and you can't fix them all. Stupid example:
> less. Behaves differently when its stdout is a terminal and when it's
> not.
> The only way to ensure reproducible behaviour for a program, no matter
> what it is, is to start it in a reproducible environment.
Which, fortunately, is pretty easy to do: I wrote an environment
sanitizer yesterday, because I was curious how easily solved that is.
Usage is
cautenv [-c DIR] [-u] [-x] COMMAND [COMMAND_ARGS...]
and it cleans the environment (saving some user variables if -u is
specified and DISPLAY/XAUTH if -x is specified), closes all fds above 2,
changes directory to DIR ("/" if that's not specified, and calls
execvp(argv[optind], argv+optind).
It comes out at 123 lines, and could probably be made shorter.
If one wants to use this in an init script, just change the shebang to
#!/path/to/cautenv /bin/sh
and you know that there are no extra variables or fds.
> >It took me ... less than a minute to find "pgrep -F".
> >That solves the problem of stale pidfiles.
>
> Do you think so? See for yourself:
> https://gitlab.com/procps-ng/procps/blob/master/pgrep.c
>
> It just reads the pid in the pidfile, and does its matching with
> the read pid. Unless you also give other options to narrow the match,
> it will have the exact same problem.
I meant "the -F option that pgrep has solves the problem of stale
pidfiles".
I assumed that the reader would know to use that in addition to the
standard options, for which I apologize.
> Now, of course, you can give the executable name, and add even more
> guards to make sure you don't find the wrong process. At the end of
> the day, you wrote a nice and complex pgrep command line, you're
> *almost* 100% sure that it will nail your process and only yours,
> and you just scanned /proc to send a goddamn signal to a daemon.
If someone finds "pgrep -F /var/run/$PIDFILE -x $NAME" complex,
I don't expect that they'd be competent to write any init script,
nor even a systemd unit.
And the only way that could be wrong is if:
-you have a stale pidfile
AND
-that stale pidfile happens to contain the same PID as a running process
AND
-that running process has the same executable name as the process that
created the pidfile, while being distinct.
I will acknowledge that whoever implemented -F did so in a lame way.
What I'd assumed that it did, because it's the right thing to do, is
make "-F $PIDFILE" check /proc//* to determine if there's a match
where is strictly any pid specified in $PIDFILE.
But this could be solved, if one did a little refactoring.
> I'd rather type "s6-svc -d /run/service/my-daemon" and kill my
> process with absolute certainty, using 10 or 20 times fewer system
> calls than pgrep and a small fraction of the CPU time.
Fair enough.
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ideas for system startup (was: Init scripts in packages)
On Friday, August 07, 2015 06:13:10 PM Gregory Nowak wrote: > > I actually don't mind dropping gnome. It does depend on systemd by > defacto, and is bulky. I did try xfce in a fresh install of debian > jessie, and found it gave me speech when I rebooted after the > install. I'm sorry, I don't know anything about the speech generation. > It also is more snappy than gnome, and felt more like gnome2 > for me, which I didn't mind. This gives me hope that I should find > xfce useable in devuan. Since Debian Jessie uses an older version of XFCE, you may have a few glitches in the way things work. Multi-monitor setups can have problems. Video playback may experience visual tearing. If you have an Nvidia or AMD card, you can use the proprietary video driver as it can counteract many of these problems. Starting with XFCE 4.12, they fixed the vsync problems. > The only thing I'm not sure about is the slim login manager. I was able to > get speech in the graphical login manager debian jessie provides when > installing the xfce task, but I didn't investigate what that manager > is. I would guess lightdm by default? T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
Rainer Weikusat wrote: Miles Fidelman writes: Rainer Weikusat wrote: Miles Fidelman writes: Alexey Rochev wrote *Date: *2015-08-05 07:29 -400 *To: *dng *Subject: *[DNG] Init scripts in packages Currently Debian packages contains both systemd units and init scripts. However, Debian developers refused to support several init systems. So it's only a matter of time when they remove init scripts from packages. What will Devuan developers do when it happens? We can use sysvinit and Devuan because these init scripts exist. It occurs to me that nobody raised the obvious questions: 1. Are we seeing upstream developers shipping systemd scripts, or systemd scripts w/o sysv init scripts? I'm not sure I have. 2. What the heck are Debian developers (packagers, actually), doing removing init scripts? There's an answer to that and it's "it doesn't matter" (I tried to point that out in an earlier reply). On the wheezy system I'm using to write this, 'init scripts' make up 6789 LOC, nobody has the power to make them disintegrate and I'd be very much surprised if there are more than 2000 LOC in there which actually do something useful. Actually, I expect yes. init scripts should be trivial and if they're not, something else is amiss. [...] Right now, init script come from upstream, Debian "developers" (I really can't bring myself to call a packager a developer) test & tweak the upstream scripts to fit the Debian environment. If they stop doing that, someone is going to have to do that for Devuan. Do they actually come 'from upstream'? Absolutely. At least for most server code, tar xvf foo; ./configure; make install leaves you with running server code, with default configuration (as tailored by configure), and init scripts Packagers typically modify those scripts. Also, to re-iterate this: What an init script needs to do is really only 'start a process'/ 'stop a process'. Most of the other code which crept in there during the last 15 - 20 years will fall into one of two categories 1) Never did anything useful 2) Should never have been implemented in this way. It can be a bit more than that, for example, the sympa mailing list package consists of multiple programs that are started in order, and includes - start (all 4) - stop (all 4) - restart (stop, in order; start in order) - status Most server scripts do some setup and cleanup. There's also typically a reload config files option. This is a non-tempest in a teapot nobody ever really saw. Worse, if "refuse to support multiple init systems" means that the Debian packagers start stripping out the init scripts from Debian packages, those, those packages become useless in Devuan. Last time I looked, the point of Apache was "it's a web server" and not "it comes with an init script" so this seems to have been blown somewhat out of proportion. Even if 'Debian developers' should stop shipping 'init scripts' as part of their packages at some point in time in the future, this won't cause them to disappear from packages people already installed. And even in the extremely unlikely case to $evil_debian_developper invades your computer in the middle of the night and steals $mission_critical_init_script (this happening simultaneously on all computers in the world), they'll be trivial to replace. Trivial as in, somebody has to do it. The whole point of packaging is to automate a lot of the routine things involved in installation. And, because Debian (and presumeably Devuan) don't put stuff in default locations, packaging involves changing the default locations of things. Where this leads is that down the road, we either need a full set of Devuan-specific package maintainers, or everybody is back to compiling and installing from upstream source. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init scripts in packages
On 08/07/2015 09:31 PM, Miles Fidelman wrote: Trivial as in, somebody has to do it. The whole point of packaging is to automate a lot of the routine things involved in installation. And, because Debian (and presumeably Devuan) don't put stuff in default locations, packaging involves changing the default locations of things. Where this leads is that down the road, we either need a full set of Devuan-specific package maintainers, or everybody is back to compiling and installing from upstream source. Miles Fidelman Good evening, Miles! =) If I might offer an opinion, I do not think that the situation is quite that dire. The packages that require init scripts are a tiny fraction of the entire repository. For the moment, the scripts Devuan needs are still in the Debian archives as Jesse has System 5 support. Devuan can just replicate them and support them moving forward. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
