Re: Would discussion of improving sysv-init be on topic?
* On 2014 15 Oct 19:39 -0500, Joel Rees wrote: systemd's problems would best be discussed at the systemd project. (Modulo the willingness of the devs over there to discuss them.) What I'm thinking is to talk about specific features to enable the sort of managing services that systemd seems to be aimed at, and how to implement them, where existing alternatives exist and how well they work, With enough discussion, we might be able to get enough mass to get a project started and get it (mostly) off-list. Perhaps you are not aware of the development project for sysvinit that already exists: http://savannah.nongnu.org/projects/sysvinit That would be a far better place to get involved. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016123311.ge3...@n0nb.us
Re: Would discussion of improving sysv-init be on topic?
On Thu, Oct 16, 2014 at 9:33 PM, Nate Bargmann n...@n0nb.us wrote: * On 2014 15 Oct 19:39 -0500, Joel Rees wrote: systemd's problems would best be discussed at the systemd project. (Modulo the willingness of the devs over there to discuss them.) What I'm thinking is to talk about specific features to enable the sort of managing services that systemd seems to be aimed at, and how to implement them, where existing alternatives exist and how well they work, With enough discussion, we might be able to get enough mass to get a project started and get it (mostly) off-list. Perhaps you are not aware of the development project for sysvinit that already exists: http://savannah.nongnu.org/projects/sysvinit That would be a far better place to get involved. Would that be debian's sysv-init? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOPHp9172PXkvJENUqr=lph7+15wgmelz3cdosp-fh...@mail.gmail.com
Re: Would discussion of improving sysv-init be on topic?
* On 2014 16 Oct 07:54 -0500, Joel Rees wrote: Would that be debian's sysv-init? That link is from the sysvinit-core package's description in Sid's Aptitude. Presumably it is the upstream project. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016125746.gf3...@n0nb.us
Re: Would discussion of improving sysv-init be on topic?
On Thu, Oct 16, 2014 at 9:57 PM, Nate Bargmann n...@n0nb.us wrote: * On 2014 16 Oct 07:54 -0500, Joel Rees wrote: Would that be debian's sysv-init? That link is from the sysvinit-core package's description in Sid's Aptitude. Presumably it is the upstream project. Thank you. I was under the impression that there wasn't really an upstream for sysvinit. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iM84z+iV9+hx1xVvkyQaGzMbsXTyidefYM=xyd_+6q...@mail.gmail.com
Re: Would discussion of improving sysv-init be on topic?
On Thu, 16 Oct 2014 21:52:58 +0900 Joel Rees joel.r...@gmail.com wrote: On Thu, Oct 16, 2014 at 9:33 PM, Nate Bargmann n...@n0nb.us wrote: * On 2014 15 Oct 19:39 -0500, Joel Rees wrote: systemd's problems would best be discussed at the systemd project. (Modulo the willingness of the devs over there to discuss them.) What I'm thinking is to talk about specific features to enable the sort of managing services that systemd seems to be aimed at, and how to implement them, where existing alternatives exist and how well they work, With enough discussion, we might be able to get enough mass to get a project started and get it (mostly) off-list. Perhaps you are not aware of the development project for sysvinit that already exists: http://savannah.nongnu.org/projects/sysvinit That would be a far better place to get involved. Would that be debian's sysv-init? With everything I've learned during the systemd fiasco, if I were to choose Debian's sysv-init, it would be nosh or something very much like it. And, as far as I know, it's ready to go, and our only involvement would be building replacements for formerly available software that was replaced by systemd-welded substitutes. After Jonathan de Boyne Pollard revealing post from yesterday (Wednesday, 10/15/2014), we could write some stupid-simple utilities to individually do all the stuff that logind does, probably using sudoers. Which means a big part of the task would be documentation, and I can do that. Of course, we'd need to write substitutes for the other 3 major welded and subsumed daemons, and some other stuff, but from what Jonathan said, logind is the challenging one. IMHO we should spend absolutely no time or energy making this stuff pretty, or even GUI if it presents challenges. If I'm guessing right about the situation, people who want pretty wouldn't have a problem with monolithic entanglement and vendor lock-in, just as long as they didn't have to pay money for their OS. As a matter of fact, regardless of what the DDs do, it just might be true that making either a systemd-free or systemd-neutered Debian might be mainly a documentation problem, and I'm pretty good at documentation. Who wants to join me? It's your chance to make Red-Hat *really* hate you. And make a lot of Debian users and other Linux people love you. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016112850.36018...@mydesq2.domain.cxm
Re: Would discussion of improving sysv-init be on topic?
On Thu, 16 Oct 2014 11:28:50 -0400 Steve Litt sl...@troubleshooters.com wrote: POINT OF CLARIFICATION: Nothing written below is nosh specific. It could be used with nosh, or upstart, or sysvinit, or any other PID1 that's *only* a PID1. So how about it, who wants to join me in neutering systemd on Debian and probably every other distro? With everything I've learned during the systemd fiasco, if I were to choose Debian's sysv-init, it would be nosh or something very much like it. And, as far as I know, it's ready to go, and our only involvement would be building replacements for formerly available software that was replaced by systemd-welded substitutes. After Jonathan de Boyne Pollard revealing post from yesterday (Wednesday, 10/15/2014), we could write some stupid-simple utilities to individually do all the stuff that logind does, probably using sudoers. Which means a big part of the task would be documentation, and I can do that. Of course, we'd need to write substitutes for the other 3 major welded and subsumed daemons, and some other stuff, but from what Jonathan said, logind is the challenging one. IMHO we should spend absolutely no time or energy making this stuff pretty, or even GUI if it presents challenges. If I'm guessing right about the situation, people who want pretty wouldn't have a problem with monolithic entanglement and vendor lock-in, just as long as they didn't have to pay money for their OS. As a matter of fact, regardless of what the DDs do, it just might be true that making either a systemd-free or systemd-neutered Debian might be mainly a documentation problem, and I'm pretty good at documentation. Who wants to join me? It's your chance to make Red-Hat *really* hate you. And make a lot of Debian users and other Linux people love you. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016113419.37ea8...@mydesq2.domain.cxm
Re: Would discussion of improving sysv-init be on topic?
Steve Litt wrote: On Thu, 16 Oct 2014 11:28:50 -0400 Steve Litt sl...@troubleshooters.com wrote: POINT OF CLARIFICATION: Nothing written below is nosh specific. It could be used with nosh, or upstart, or sysvinit, or any other PID1 that's *only* a PID1. So how about it, who wants to join me in neutering systemd on Debian and probably every other distro? It strikes me that there's actually very little that needs to be done. In the short term, the world, including Debian, will continue to support sysvinit scripts - if only because the BSDs aren't going anywhere, I expect autotools will continue to build things with init scripts, logging to syslog, etc. As far as I can tell, the major place that some work may be needed is in the Debian Installer - to make it easier to install a sysvinit based system. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fe964.4050...@meetinghouse.net
Re: Would discussion of improving sysv-init be on topic?
On 14Oct16:1151-0400, Miles Fidelman wrote: It strikes me that there's actually very little that needs to be done. In the short term, the world, including Debian, will continue to support sysvinit scripts - if only because the BSDs aren't going anywhere, I expect autotools will continue to build things with init scripts, logging to syslog, etc. As far as I can tell, the major place that some work may be needed is in the Debian Installer - to make it easier to install a sysvinit based system. I'd recommend someone take a close look at the assimilated packages, especially udev, before this seat-of-the-pants feasiblity study is deemed useful. -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe. __--from_Nightfall_by_Asimov/Silverberg_ signature.asc Description: Digital signature
Would discussion of improving sysv-init be on topic?
systemd's problems would best be discussed at the systemd project. (Modulo the willingness of the devs over there to discuss them.) What I'm thinking is to talk about specific features to enable the sort of managing services that systemd seems to be aimed at, and how to implement them, where existing alternatives exist and how well they work, With enough discussion, we might be able to get enough mass to get a project started and get it (mostly) off-list. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: SysV Init
In your /etc directory there are a number of directorys called rcN.d where 'N' is a number indicating the runlevel. In each of those directorys there are a number of symbolic links which point to scripts (usually in /etc/init.d/ - at least that's where i keep them) which start with either 'S' or 'K' which indicate whether it will be started or killed and a number which indicates which order it is run in. Also, I believe there is a common way to write the scripts which allow you to pass either start,stop,restart (or maybe some others) which will allow the symbolic links to operate properly (for being started and stopped anyway). I'm not positive about that though. Does someone wanna elaborate on this Leonard Leblanc - Original Message - From: Stephen Robertson [EMAIL PROTECTED] To: debian-user@lists.debian.org Sent: Friday, February 02, 2001 4:13 PM Subject: SysV Init I'm fairly new to Debian and still learning the system. What is the accepted method of configuring which services are stopped and started in each run level, and how can I add my own commands to the Init scripts. RedHat provided a file called rc.local for adding user commands. Is there a similar method in Debian? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SysV Init
Hi, The scripts are stored in /etc/init.d Each runlevel has its own directory e.g. /etc/rc0.d, /etc/rc1.d etc. In the runlevel dirs there are a load of symlinks to the scripts in /etc/init.d. The format of the filename is: Sxxscriptname to run a script with the start argument when entering the level Kxxscriptnameto run a script with the stop argument when entering leaving the level xx is a number which tells init which order to run the links, lowest first, scriptname is the name of the script in /etc/init.d, I don't believe that matching the name is a requirement as I think that init only cares about the first three chars, just common sense for administration. Jim p.s. Please cc me in on a reply as well as the list Stephen Robertson wrote: I'm fairly new to Debian and still learning the system. What is the accepted method of configuring which services are stopped and started in each run level, and how can I add my own commands to the Init scripts. RedHat provided a file called rc.local for adding user commands. Is there a similar method in Debian?
SysV Init
I'm fairly new to Debian and still learning the system. What is the accepted method of configuring which services are stopped and started in each run level, and how can I add my own commands to the Init scripts. RedHat provided a file called rc.local for adding user commands. Is there a similar method in Debian?
RE: SysV Init
On 03-Feb-2001 Stephen Robertson wrote: I'm fairly new to Debian and still learning the system. What is the accepted method of configuring which services are stopped and started in each run level, and how can I add my own commands to the Init scripts. RedHat provided a file called rc.local for adding user commands. Is there a similar method in Debian? man update-rc.d You need to add a /etc/init.d/local script. Debian does not ship one. As for what starts and stops, debian basically assumes you live in run level 3. If you install a package, it gets run at boot. uninstall things you do not want. Another choice is to added configuration to /etc/defaults/foo and make /etc/init.d/foo read that file. update-rc.d can reassign boot priorities and what runlevels what gets run at.
Re: file-rc vs. sysV init (was: enabling bootpc at startup)
Quoting the lone gunman ([EMAIL PROTECTED]): Why is file-rc not the default, just out of curiosity. I found it much more intuitive, and a bit easier and faster to maintain. The default sysV init scripts took me a bit longer to figure out. First, the sysV mechanism is more common (e.g., redhat) so people familiar with other platforms will look for it. Also, the single file is a little more dangerous in my mind: if it gets corrupted (maybe someone misstypes, or two people try writing at the same time) you'll have a hard time getting booted properly. Mike Stone
Re: file-rc vs. sysV init (was: enabling bootpc at startup)
On Wed, Aug 26, 1998 at 02:20:28PM -0500, the lone gunman wrote: On Wed, Aug 26, 1998 at 08:19:34AM +0200, Torsten Hilbrich wrote: On: Mon, 24 Aug 1998 14:11:30 -0500 the lone gunman writes: On my Debian 1.3 system, I installed the package which removes the sysV style init scripts and installs the /etc/runlevel.conf system. I did not see this package in my hamm install. Did I overlook it? Yes, it's called file-rc and to be found in stable/main/admin. BTW: Search the package file for runlevel.conf and you will find it. Why is file-rc not the default, just out of curiosity. I found it much more intuitive, and a bit easier and faster to maintain. The default sysV init scripts took me a bit longer to figure out. Well...it is not the traditional way of configuring runlevels. besides...I LIKE the sysvinit way of doing it with SymLinks Also...when I installed file-rc (accidently) a while back...it completle fucked my system. It wasn't properly unmounting filesystems on reboot. When I found it was doing this I set out to find out why (not even knowing that file-rc was installed)...lost the whole filesystem. Maybe this has been fixed? I would install file-rc agian, but I have a worry. I noticed when updating/installing new packages with file-rc installed, I get a *LOT* of errors that are something like: update-rc.d: integer expected or something leading me to believe that dpkg still tries to run the update-rc.d script used in a sysV init system, while update-rc.d is obsolete if file-rc is used. Any comments on this? Is this perhaps fixed in Hamm? I dunnoI would NOT want to see this become the default... I think it is allot less flexible than sysvinit. if you like it...go on ahead...whatever floats your boat -Steve -- /* -- Stephen Carpenter [EMAIL PROTECTED] --- [EMAIL PROTECTED] */ E-mail Bumper Stickers: A FREE America or a Drug-Free America: You can't have both! honk if you Love Linux
file-rc vs. sysV init (was: enabling bootpc at startup)
On Wed, Aug 26, 1998 at 08:19:34AM +0200, Torsten Hilbrich wrote: On: Mon, 24 Aug 1998 14:11:30 -0500 the lone gunman writes: On my Debian 1.3 system, I installed the package which removes the sysV style init scripts and installs the /etc/runlevel.conf system. I did not see this package in my hamm install. Did I overlook it? Yes, it's called file-rc and to be found in stable/main/admin. BTW: Search the package file for runlevel.conf and you will find it. Why is file-rc not the default, just out of curiosity. I found it much more intuitive, and a bit easier and faster to maintain. The default sysV init scripts took me a bit longer to figure out. I would install file-rc agian, but I have a worry. I noticed when updating/installing new packages with file-rc installed, I get a *LOT* of errors that are something like: update-rc.d: integer expected or something leading me to believe that dpkg still tries to run the update-rc.d script used in a sysV init system, while update-rc.d is obsolete if file-rc is used. Any comments on this? Is this perhaps fixed in Hamm? Thanks
