OSNews was the first news magazine to break the story on Gnome’s Seth Nickell effort to replace the Init system. Soon, it became confusing to many readers as to if Seth is planning to completely replace the Init system or simply “bridge” it. We had a chat with Seth and discussed about his plans on the project (which is a personal project so far) and for Storage, an exciting project which aims to replace the traditional filesystem with a new database-based document store.We asked Seth if he thinks that in the event these projects take off will be Linux-only and if they actively supported by Gnome libs might result in Gnome being OS-specific and ultimately drive the project into forks. Seth does not believe so that this will be the case, as companies where their business depend on Gnome (e.g. Sun Solaris, Ximian) will be able to adapt and port necessary technologies.
Regarding Storage, Seth told us that the natural language parser needs more work but the project is progressing. We also asked Seth his opinion regarding an ideal packaging management for Linux, and he told us that what Red Hat is doing currently with the “Red Hat Network” is a nice idea, however it still needs some refinement.
Here is Seth’s response on System Services and the replacement of Init:
Seth Nickell: I’m planning to fully replace the init system, not just bridge to it. I *am* providing full backward compatibility with initscripts (SystemServices can use them), but of course they will only offer as many features as initscripts already have written into them (not much :-).
SystemServices has four major goals:
1) Provide a full services framework (including handling “boot up”)
2) Integrate well with a desktop interface
3) Start X, and then allow login ASAP
4) Allow daemon binaries to directly contribute services rather than requiring each distro/vendor to write shell script wrappers
1) The init system has small concessions to being a services framework rather than just a “boot-up-tool”, but it really only provides the ability to start/stop/restart services. We need a system that is both more featureful and and more robust, esp. for desktop integration, but its nice all around. For an example of robustness, if a service can’t start (or if it crashes at some point!)… the interface needs to get an “exception” with an error code and a message. For an example of a feature: we need integration with xinetd so you can flip a checkbox to switch a service between “run on demand” (xinetd) or “run always” (daemon).
2) The way init works doesn’t fit really well into a desktop interface. A lot of these issues are covered by (1). The whole runlevels concept is confusing and cumbersome, even for most (not all, but most) sysadmins. There are a very small percentage of people who need runlevels, but for most people they make the conceptual model for services 100x more complex with -zero- gain. They also make interfaces a lot more clunky. Of course, being a part of Unix tradition, I expect a million people who have never really benefited from them to scream at me anyway *wink*. I *might* provide the idea of named “service profiles”. I *will* provide a way to boot into a “stripped down console mode” aka “single” for system recovery and backup, and a regular non-graphical boot for servers.
3) Most services are not required for running KDE/GNOME/whatever. These can be deferred until after KDE and GNOME have been started (or happen in parallel). Also, SystemServices brings up boot progress information in X almost immediately. Even after you’ve logged in, we provide a little progress window on the side of the screen that provides feedback on the startup of non-desktop-required System Services (Apache, ftp, etc). The window goes away as soon as the system is fully started.
4) This one is part halting constant re-invention of the wheel, part personal agenda, and part clean architecture. Its silly that custom init scripts is one of the areas where distros work separately, what a waste of time they could be spending on much better integration work. My personal agenda is to encourage daemons to depend on DBus in the future, which will make them more likely to *use* DBus for providing a client interface. I fear that even after DBus exists and when it makes sense to, e.g. have an org.apache. WebServer DBus service it will get shot down because nobody wants to add the (compile time optional) dependency to get a few “small” features (small to daemon/kernel/network hackers, big to the desktop!). But the really big thing to me is clean architecture. When daemons contribute services directly we have a framework for them to contribute more than just the basic Service interface. There’s already a concept that a service can contribute more than just “start/stop”… the Apache service can contribute API that allows desktop apps to query status, etc.
3) Most services are not required for running KDE/GNOME/whatever. These can be deferred until after KDE and GNOME have been started (or happen in parallel).
it seems that he is taking the same approach Microsoft uses.
http://www.banned-width.com/shel/works/unempl.html
The Linux init system is crap for a modern desktop OS. This is one area Linux should diverge from Linux for servers ASAP.
I want to see BeOS-like boot up times (into a GUI). I think it’s possible with today’s hardware + Linux and a new init process.
I like number 3.
Because I do not know what services are needed. You get Redhat or Mandrake or Suse, and it seems as if all services are running.
I wonder what Lycoris or Lindows does here, do they run only the needed services?
I dont like how this really encourages(requires?) running XFree86 at startup.
I dont. I usually startx within a minute or two, but I like the ability not to have to boot into XFree86 at startup.
That, and why would I want the extra memory usage just for a pretty login screen? I understand this is nice for Windows users, but it shouldnt be required.
Then don’t use it.
To be more constructive, Why don’t you boot into XFree86 at startup? Maybe there are other alternative init designs that will give you the same benefits as booting to the console.
I dont boot into XFree86 at startup because of two main reasons:
1. I dont like having to use a display manager, it seems like wasted memory to me. Plus, that looping thing is really annoying (I know you can turn it off, but ive had issues with that).
2. Ive been updating kernels alot (2.6), so I have to redo the nvidia module, and when I boot, I dont want XFree86 to startup,and then not find the module,and then go into one of those annoying loops.
The point is that you should have a choice. Especially servers that dont even have GUIs.
Other than that, this sounds like a nice system.
And dont speak for the developer. He wants this to replace the init system,meaning EVERYONE (eventually) will use it. So no, its not just a matter of ‘dont use it’. Im not using it now of course though.
That’s the keyword for me. At the moment, say your network is disconnected, it halts the whole boot process for however many seconds, when useful work could be done. I’m glad to see that people are working on starting services simultaneously. This is a step in the right direction.
Some level of runlevels or profiles support is absolutely required. A lot of computers are multi-role machines. My laptop, for example, runs ssh/nfs/etc services when I’m tethered to my desk, but I don’t want to bother with those when I’m on the go. Also, I have two network interfaces, a wired and a wireless one. When I’m running around, I don’t want my bootscript to try to start the wired network, because I’ll just get a 30-second delay whiles it flails about trying to connect to a DHCP server. Similarly, when I’m out of range of a wireless hub, I don’t want my machine to start up the wireless interface, spending inordinate amounts of time scanning for a wlan.
A couple of comments overall:
1) Using C for this is a bad idea. RedHat has the right idea with using something like Python for non-performance critical services. There are no computational bottlenecks in the init system — its entirely a matter for spending 0.001 seconds to start some C program, and then waiting a second while it does its initialization.
2) I’m really sick of people equating age with low-quality. The existing init system was fine for what it did. Now, the requirements placed on UNIX have changed, to a set of requirements where the current init system is no longer suitable. Replacing it with a new system, more suitable for desktop use, is a fine idea. But code doesn’t rot, and the age of the init mechanism has nothing to do with how it performs.
3) Other than these things, I think this is necessary. Some sort of unified method is required for selecting profiles (for laptop usage and whatnot) and the current init system doesn’t handle this well. Startup speed is also pokey compared to WinXP, so this should be a nice boost.
He says he will probably offer named profiles, and also that there will be a non gui mode.
You could always have a non gui program that monitors dbus and gives you the appropriate information on events etc…
Think about this: 1) You login after 1 second (you really need nothing to be able to login) and while you are browing your home directory everything starts up and prints to tty when major things happen (finished loading everything, apache didnt load, etc…). Or what about having an alt+ctrl+fn that all it does is display detailed information about dbus information, and what happened.
2) You could also have that when you boot up you get a nice little selection screen that lets you select fomr ‘On the road’, ‘In dock station’ ‘On network (so mount network home dir)’ modes.
I am not saying that is what will happen just that this has alot of potential so dont shoot it down!
I was wondering if anybody knows how BluedEyeOS works when it boots up.
I meant BlueEyedOS
I think it’s pointless except for desktop users and even then i’m sure the system isn’t taking the numerous amount of errors that can take place on system initialization into account. How will this be handled? Most likely the same way windows and the like handles it press Shift-Whatever.. It just seems like there is so much room for problematic behavior that doing this is a step in the wrong direction. Let companies like Redhat customize their init scripts based on their distros and provide their own tools to modify.
… Linux becomes just a little more like Windows.
Seriously, what is the obsession with copying Microsoft? So many Linux users profess to hate them, yet spend their time copying aspects of their products….
It really is quite baffling…
Because Windows has some good features.
We copy the good features and not the bad ones. We improve when needed. Thats called innovation.
Like MS never copies anyone?
I don’t even think it is bad concept to re-invent the wheel if the wheel was square to begin with.
But, It was not square and the init system works.
For a Desktop or some Server uses it just works too slowly.
What it does not have a seperate API/Network protocol with fancy whistles and bells?!? It must suck.
I understand the natural superiority of phython since that is the hot new language of the second. Don’t get me started. Every other year there is a new scripting language that everyone just has to learn … blah.. blah.
Still, shell scripts work everywhere.
Does the init system need cleaning up and tightening? Yes.
Do you need to re-invent it poorly through yet another scripting language? No.
By God, the boot process would be five times faster if the following happens:
1. Hardware recognition tools probed quicker
2. Distros would turn off unnecessary services (No, I am not running lvm why does that crap have to start by default on Suse).
3. Network probing and networked services starts were handled in a more intelligent manner. The services ideally would be clustered in one init script and if the network is not there then nothing else net-related would start and the process would just speed right along.
Want more information from an init script on the status?
Add more stuff to the shell script. It is a shell script for goodness sakes. Everyone busts on that fact that it is some high sin. However, you can do some incredible things very simply in a shell script.
I went through this with perl for awhile too. Everyone would say to me “Why are you doing it in a shell script? Write in perl.”
I would say, “Because it is a 12 line shell script and I don’t want to turn it into a 48 line perl script.”
Now it is all about Python. Fine.
The main problem is not init. There are three real problems.
1. How the services are clustered and init does honestly need a re-write to allow clustering daemon initialization by dependent type like I mentioned for network stuff above.
2. Still, even worse is that application writers need to spend a half second thinking about how their program will be initialized and the code around its daemon mode for more flexibility like Seth is talking about.
3. But, finally there are the distros and the packagers. Most init scripts are cookie start|stop|restart things with only a few having a status option. Come on people get into the script and allow for a larger set of initscript options.
I just think Mr. Nickell is taking the hot new language of the moment and creating a hack/crack new level of complexity because init will still exist and then there will be the Dbus stuff and then the default gdm pre-session stuff starts and if you use Gnome there are the session apps and you get the picture.
I think there needs to be a process to for launching process at every step of every process. That is the ticket.
If the author of this “init replacement” is unhappy with his bootup time, perhaps he should analyze where most of that time is spent. On servers it sure isn’t during init.
On the Dell PowerEdge 2650 I’ve been playing with for the last month, 90% of my bootup time (a rough approximation) is spent during POST, and 10% or so doing init. And that’s with starting a plethora of network services which depend on eth0 starting, which is using DHCP for goodness sake. I’ve got a terribly slow configuration and it still starts in sub 30 second times. With a static IP and a more focused server profile that’ll drop to a fraction of the time. When I strip some of the devices out of the kernel that don’t exist, and thus don’t need probing I can shave even more time out of it.
For my desktop I’m in much the same boat. Service dependencies often mean that some serialization is necessary, and on a uniprocessor system trying to context switch between these tasks isn’t likely to buy you much speedup.
Furthermore, the concept of applications being responsible for interfacing with some of service bus is ridiculous. Servers are standalone components of a system, and should be initialized and then left alone. If you want them monitored or restarted or to “throw exceptions” then use something like daemontools. Hell, if you want them restarted put them in the inittab with a respawn option. That’s what its there for.
All in all this looks like somebody has dreamt up some pie in the sky solution for something that nobody really has a problem with, and hasn’t even bothered to analyze what exists today.
seriously.
this is for desktop systems, not for servers.
My thoughts in response to the negative feedback I’m seeing/hearing: so there are advantages and potential disadvantages to the system being proposed. So what? Firstly, it still can and does the standard shell scripts in its initial form as well as Python or whatever script or doc language it can handle. But even beyond this, <em>it’s an experiment</em> simply put. This is what people call a tryout. Don’t just shoot something down without giving it time to see how it goes and doing your research. It seems that he’s addressing the issues being raised and is open to changes; this is, I assume, an open-source project. For all I care, this could turn out to be an amendment to the current init system with additions or improvements, if we give feedback to Seth.
Bottom line, stop being all-out negative, at least be constructive in your arguments, open to options on both ends, and give an experiment a chance. My $0.02…
-Jon MacG.
It is one of the major stumbling blocks to distro packages not working correctly with each other. I work with Linux for a living. A huge part of my job is packaging up programs to replace the older programs in our base SuSE distribution. The biggest pain in the ass is getting the package to compile the with the same layout the init scripts expect. Using the SuSE spec files rarely work because newer versions of the package may compile differently. One instance is upgrading to the latest apache, I have to kill the apache process because the init script can not properly shutdown for some reason. I’m thinking of packing up the DBUS betas because there are a couple of critical services we need to check if they are running and looking at their .pid is no good. The boxes are updated automaticly so having a system services would allow us to realy make sure the services are working and responding and allow us to fix problems before we have to send a tech out in the field. The thing is if we can get rid of init scripts, services can be started, stopped and queried in the same manner across any distribution. No more hacks to see if a process is still running and since most of the code will come from upstream instead of the distros the interfaces will stay cleaner and the behavior similar across the board.
—
J5
http://www-106.ibm.com/developerworks/linux/library/l-boot.html
I submited this link to the new a week ago and no one took any notice. There is a bit of information on how to speed boot time without stripping down functionality.
As far as I can tell, SystemServices is written in C, not Python. I suggested Python because its a nice scripting language that has become rather popular with distro makers (like RedHat and Gentoo) as a glue language. The nice thing about Python is that its scalable — its simple enough for configuration files (scons) and glue code, but scales well to small apps (RedHat config tools) and to large apps (Portage). Shell scripts don’t scale up very well, and C doesn’t scale down very well.
PS> I find the comments about C programs being more aware o their environment troubling. That’s one of the things I hate about the Windows model — applications have too much machinery in them that should be factored out into the system itself. It doesn’t fit the UNIX-y model of apps being simple and straightforward. That model is nice for people editing their init scripts (which almost nobody should be doing, except distro makers) but sucks if the system changes slightly and breaks the applications’ views of how the system is arranged.
1) The init system has small concessions to being a services framework rather than just a “boot-up-tool”, but it really only provides the ability to start/stop/restart services.
True, I think. It’s basic, and sometimes a bit kludgy.
2) The way init works doesn’t fit really well into a desktop interface.
Ofcourse not. Because it’s supposed to do more than just focus on the desktop: it’s supposed to bring the whole system into an operational state, including services that have nothing to do with X, and should be loaded before it, e.g., mta, nfs, etc.
3) Most services are not required for running KDE/GNOME/whatever
But they are required for the system as a whole. I see Gnome as the top of my system, not the base. There is way more running beneath it, and often at least as important.
Besides, if ‘the concept of runlevels is too cumbersome for most admins’, you hired idiots. I mean, if you can’t even grasp what gets started in which order and what will be running at or after the boot process, you should not even be allowed to run a box directly connected to the internet. I mean, you are talking about *admins*, not “dumb” users, after all.
3) Most services are not required for running KDE/GNOME/whatever.
But I need them! Otherwise I wouldn’t start them, would I? Again, my computer is more than just Gnome!
And I do NOT want the GUI started before at least syslog, keyboarddriver, console, nfs, and other daemons/procedures I need initialised *before* my system is up and running. GUI’s are too untrustable to depend on. If X locks up, you’re done. And you would start sshd and other daemons *after* X, Gnome? That’s hundreds of binaries and libs down the chain. If things go wrong, you never get there. And you’re major stuck.
4) This one is part halting constant re-invention of the wheel, part personal agenda, and part clean architecture.
Very personal agenda, methinks. Although you have a point with ‘clean architecture’, I don’t think it’s a good idea to make everything dependent on GUI processes. Lots of things should be done *before* a GUI has the chance of taking over, because those things are:
needed for boot-up (e.g. nfs)
needed for the gui itself and its programs (e.g. mta, syslog)
necessary to ensure backup possibility when the gui comes crashing down or other things go wrong (e.g. console, keyboard, fsck, sshd)
more important than the gui (e.g. mta, dns-cache, imap, apache, whatever)
What you really want, is a init script cleanup and standardisation. And that I can agree with, I don’t particulary like the init structure of most distro’s, and maybe some smaller things would fit better *after* the booting of a GUI. I usually make my own bootscripts (lfs), and it can be done much cleaner than the kludgy must-work-for-everyone and-in-every-possible-configuration methods of most distro’s. Maybe something that combines the late Linux Progress Patch with GDM would be a better idea to experiment with?
But to subject booting, system initialisation and daemon starting to a GUI, is madness, in my eyes. And too deep hooks of GUI into the base of the system sounds like a real horror (performance, security, compatibility, failover-safety, etc).
Don’t make Microsoft’s mistake: although lack of lotsa scrolling text makes it *look* more user friendly, you are deadlocked without info when something goes wrong, whether you are a beginner, advanced user or Billy Leech-you-dry Gates.
There are already bindings for DBUS and a number of languages including python. I should point out that Seth is a python man himself. Excerpts from his blog:
(on starting a service)
Ideally this would mean activating the daemon itself which would use DBus, but it could also mean activating a “python wrapper”
By the way init scripts can still be used but won’t gain the functionality that DBUS and system services give you.
—
J5
What I have done to get the display manager coming up asap and the system be usable, in gentoo is by setting the xdm service to start first. Because gentoo uses a deps system all required services are started for gdm. This makes the booting look quicker and only takes ~ 30 secs from when the kernel boots until the display manager to come up:)
I think interest of GUI login is that startx is already running, so you don’t have to wait for it after login (neither do you need to shut it down between two login). for my self I would also boot with more gnome/kde components in order to have a fast login.
Seth Nickell approach may not be interesting as long as you only thing about linux as a server. But it is important if we want linux to be appreciated as a workstation.
Featuring backward compatibility, Seth Nickell system also feets for a server (better keep the same tools for servers/workstations, maybe with different parameters).
I suggest that you AT LEAST take a look at G. Pape page
http://smarden.org/runit/
It provide replace for even more than linux (BSD and maybe in futur MacOSX).
Before reenventing the wheel, look at existing project and the state of art. Also look at http://cbbrowne.com/info/init.html
Also, it’s very old and was mind as a replacement for Debian init architecture, but I am still using it with sucess and with a little bit of work, you can make every service living in his own directory/username and even use concurrent version of the same service without disturbance:
“runlevel”
Ok, I can even find it anymore on google (it was in 98). But I can give the source code to anybody intersted in. It’s a small C program that patch init to provide single file runlevel, service administration (like in some BSD systems).
I always thought all new ideas should be encouraged in the open source community because only the better ones will survive.
Let this guy do his thing without a word and if his solution really is better people will use it…
The fact that people make new propositions and works on solutions shows in my opinion that there is a problem.
The fact is I tried BeOS twice using a live eval CD that didn’t do much but showed me how fast a Desktop OS should boot. If Linux wants to be a Desktop OS it will need to adapt.
I know I hate Linux when I just need a phone number and my laptop is off… I could careless about all the other services booting up: get my addresse book up and do the rest in the background. (and print out the result on tty1 or whatever…)
For the output he should do like bootsplash: hit esc or f2 and you get text bootup, don’t hit anything and you get graphics. Current systems have way too much memory anyways… use it.
But basicaly:
IF PEOPLE USE SOMETHING, IT HAS TO HAVE SOME GOOD, AND IF PEOPLE SWITCH IT HAS TO BE BETTER…
Reminds me of the project serel, where services are started according to requirements. It’s at http://www.fastboot.org but seems rather dead. As for the people who think admins must know runlevels – yes, currently they must, but why should they if named profiles could replace that concept? Make Linux easier to admin and you’ve just lowered its real cost by a bit.
Is a BSD right? So what kind of system does it use? Is it the init system or something else.
Seth has impressed me again and again with innovative thinking on classic problems faced by Desktop Linux systems – he seems to embrace important developments such as DBus.
Anyways the future of Desktop Linux has gotten a whole lot brighter these past few weeks – HAL 0.1 was announced, Seth announced Storage and SystemServices.
I applaud his efforts – go Seth go !!
Seth shows an obvious lack of awareness of solutions that are already out there. Rather than replacing init with some Python hack (great, yet another half baked interpreter on my system) why not look around at the direction NetBSD has gone. The NetBSD init system is small, clean and like its predecessor only relies on the Bourne shell. FreeBSD is adopting this init system for version 5, and boot up times are significantly faster than with Linux offering similar services on identical hardware.
Chris
People forget that runlevels is a fairly recent import
from Unix SystemV. Originally Unix init did not have them.
There was just the distinction between single-user mode
and multiuser mode (OK, you could call them two runlevels).
Even all Linux distros do not use runlevels. I think
Slackware is the most prominent example.
One major problem with runlevels is that they mean different
things in different systems and a single digit is really
bad as a descriptive name. It also implies a hierarchy
that does not always make any sense. For example, it is
quite reasonable to have a system state where you have
the X11 GUI running but all network services are down.
Should this be above or below the runlevel where the network
starts?!
I like the idea of profiles, if used judiciously and
named well.
Fsck you all, you’re all only complaining about it.
Be happy that this terrible and incompatible way of initscripts is finally going to be deprecated very soon (I hope).
Long live Seth!
(I don’t like the Python way tho
it breaks way too much on my system)
This may work well on a desktop running only client GUI-based services. (Meaning Mozilla, but not Apache, etc.) It may even help Linux/*BSD/etc. leap into the desktop arena.
However, I will not use it on a server if it reuires D-Bus, GTK+, etc. I admin approximately 750 Linux servers. (I use a single distro provider.) None of them have _ANY_ X Windows or desktop related software on them. (All run headless.) They run network services such as Apache, BIND, SSH, and Exim. That is it. I will _not_ install ORBit, GConf, DCOP, GTK+, QT, ATK, Pango, Xlib, Xterm, XDM or any of the related client software. These packages are not necessary nor useful and only waste valuable disk space. I do not want an init system that has a requirement on any of this. I use vi and bash to admin my boxes. I edit runlevels by hand. (They are not hard to figure out if you ask me.) I edit init scripts and config files from the console. I want a small, simple tool to initialize my servers. For me to use this SystemServices software it needs to provide all the functionality of SysV Init, but no more. (Who doesn’t like better packaging?) I need to be able to install it and have it be _completely_ usable WITHOUT D-Bus, GTK+, etc. installed. I don’t want an exception thrown for another piece of software to catch. (Desktop integration is pointless if there is no desktop installed, much less running.) I want a message sent to STDERR on my console. I want to see each service boot so that I know which started and which failed. (The services that I run are complex enough, initializing them should be simple.) These are my requirements, the requirements of your standard, every day, ordinary professional UNIX admin.
Now a few comments on profiles and parallelization. SysV Init already supports these concepts. I can easily make multiple services start at the same time by manipulating a few symlinks. “Profile” is just another term for “runlevel” in my book. SysV Init support 6 runlevels. Most UNIX-like OSes (including Solaris, etc.) only use 3 or 4. The unused ones can be configured to provide alternate profiles for a docked laptop versus an undocked laptop, or a networked configuration versus an non-networked configuration. Just choose your services wisely and use the bootloader efficiently.
I use both windows and Linux for work, on my laptop.
I use windows for the usual reasons, i.e. compatibility with office files of my colleagues, and some programs that have no good enough (at least for me) equivalent under Linux (chemistry stuff) or none at all, while under Linux I use some computational and NMR spectroscopy data processing stuff ported from unix, which has no equivalent (again good enough for me) under windows.
I would really, really welcome anything that could speed up my boot process, so to lose the minimum of switch time.
About the choice of Python as system language, I think that probably it is bigger in disk and memory size than a shell, but about same size of Perl, after removal of unneeded (for system work) libraries. Which is not a problem with 256 Mb RAM and 80 Mb HD, which correspond to a very cheap computer for any western country, I think.
you can use the current init to do everything while retaining the advantages of a simple and plain system.
Gentoo already implements a dependency based init system and is currently using also a parallel startup.
just upgrade to the latest initscirpt package and set USE_PARALLEL_STARTUP=”yes” in the /etc/conf.d/rc file.
esay and quick.
DBUS is a simple Messagebus that has GTK+ and Qt bindings but does not require them. DBUS is lightweight and will eventualy replace specialized deamons like famd. This reduces the amount of deamons running on a system (more secure).
—
J5
The boot process is only one asspect of this project. More important is the use of DBUS for system services. While other projects may have address the system startup time they have not addressed the need to get reliable status information. i.e. are you running? are you also responding? what state are you in? do you have any errors? etc. With deamons and applications alike having a standard DBUS interface standard ways of querying status of these applications will make them easier to administer instead of the init script status hack which is usualy useless as it relies on things like .pid’s to determine if a program is running or not (a program can be running but not responding or could have been killed without cleaning up the .pid). The of the craziest error messages I have ever gotten from an init script is something like, “It looks like the process is already running. If it is not please delete the /var/run/process.pid and try again”. Fine if you are working on a computer by hand, not good if the computer must be automated and self sufficent because it is clear across the country and the client using it have no technical skills whatsoever (or no access to a login – think networked appliance). Wouldn’t it be great to have a cron script that broadcast the dbus every hour for all the services to report in and if one doesn’t report in it restarts it? Why should I have to write a hack for every single service I want to have this functionality in if with DBUS and system services I can just broadcast to the 5 deamons I need to keep an eye on?
—
J5
“1. I dont like having to use a display manager, it seems like wasted memory to me. Plus, that looping thing is really annoying (I know you can turn it off, but ive had issues with that).”
If you’re not using the memory, you’re not wasting it. Memory is a renewable resource. ~,^
“2. Ive been updating kernels alot (2.6), so I have to redo the nvidia module, and when I boot, I dont want XFree86 to startup,and then not find the module,and then go into one of those annoying loops.”
I posted a startup script (guess it needs to be ported to be a SystemService now 😉 to the NVIDIA forums that solves this issue; basically, it takes care of rebuilding the driver if it detects it has become borked, either thru a kernel upgrade or X/Mesa upgrade.
Ok, I saw that but the glue to the thing is Python and putting that extra dependency is troubling. Try adding a new python script like the latest gdesklets and follow the dependencies between python and the different binds back. It is a mess.
Half of the functionality stuff can be resolved between better status utils, more functionality from the services themselves for the daemon services and better written init scripts in plain jane shell.
Like I said before I believe init itself needs to “fixed” especially for desktop usage as opposed to some sort of hack work-around aimed at replacing init or even worse adding another seperate SystemServices layer to an already crowded list of utilities and files that control the start of daemon processes. We already have xinetd, the inittab itself and the init scripts.
I am not saying leave well enough alone. The stone wheel (init services) does not need to remade simply upgraded to that steel belted radial we all want and need. Plus, it hides the fact that distros do sloppy, slow jobs in terms of handling their hardware detection and including a laundry list of services by default that neither an end-user or server implementation needs on by default.
It also hides the fact that all init scripts are basically written in the same manner and better gui front ends for adding or turning on options is needed. We are talking basic string replacement or sometimes uncommenting lines for goodness sakes. Is it a lot to keep track of? Yes. Is it worth the time, yes.
I am tired of people trying to re-invent basic parts of the *Nix infrastructure instead of re-writing and re-creating it. It is even more tiring to see people responsible for coding parts of that core refusing to step to the plate and do the re-writes needed sending more people into a it needs to be replaced frenzy like X for example.
BTW, does anyone know how Mac OS X handles this?
It is not written in python, and it can run init scripts. gDesklets is a completely different beast that uses the GNOME platform to achive its goals. System Services should only have a DBUS dependency which itself has not other dependecies besides glibc which every C program depends on.
It also hides the fact that all init scripts are basically written in the same manner
Have you seen the mess of init scripts between different distros? Init scripts are rarely written by the upstream developers and if they are they are usualy refrence implementations.
—
J5
I really don’t have much of an opinion either way about this. Linux does need better boot times, and I really don’t care if it comes bout via this mechanism or a rework of the existing init system.
As for Python — you have to seperate the Python language itself from additional modules. The Python runtime has almost no dependencies. Its no different from bash — its a programming language + interpreter, except that its a much better language. The reason I suggest Python is that its already being used in a lot of other places in most distros, so it might be nice to standardize on one glue language for the most important pieces.
PS> OS X uses a combination of BSD init and their own system called SystemStarter, which is very much like SysV init. Specifically, BSD init brings up the low-level stuff, and SystemStarter brings up networking and the GUI.
All services which can start parallel, should start parallel. Should be nice to adopt ideas from project “serel” ( http://www.fastboot.org/ )
There is certainly room for innovation within the GPL/OSS community I for one will not be using gnome of any distro that limits my ability to control the system I am using. One of the reasons that I believe people have migrated to the linux platform is access to all aspects of the operating system. This would include the init scripts that are easily modified and well understood by anyone with more than a passing interest in the operating enviroment.
The replacement of the init process will only serve to enlarge the base of windows users migrating to the platform and is the sole reason modifications are made by the likes of RH, Lindows, Lycoris…etc… Not neccessarily a bad thing if computing is nothing more than a tool, similar to a calculator or microwave. A consumable albeit a free consumable.
Cheers, Ithaycu
Slackware boots fast. Slack init script is simple and easy to read, edit and adapt. For instance, I noticed that running /sbin/ldconfig was taking too much time; I just added “&” after “/sbin/ldconfig” command line and voilà, it just runs in the background. Actually I did the same with nfs services and guess what? My machine boots in a mere 15 seconds from SCSI BIOS to GDM.
I really don’t understand why whenever a new idea is proposed that in anyway alters the existing Linux architecture, dozens of plush penguin weilding zealots flow into the arena screaming, “Burn her! Burn her!”
If you want to be left alone and live in the 80s, then go ahead and you your damned command line exclusively. Stick with an older version of whatever your favorite distro is. Meanwhile I will happily, quickly, and graphically boot into my Y window system on Gentoo 3.0.
The GUI is here, it’s not leaving. Realizing that and dealing with it will make your life much easier. I swear, if some of the folks around here were in charge of these decisions I would be etching this message into a stone tablet.
If you want a simpler, quicker replacement for SysV init, use the rc.* system used by BSD. Someone mentioned the NetBSD rc.*, that’s even better. As for linux, doesn’t Slackware use rc.*? What’s wrong with that?
On my machine (old dual celery abit), FreeBSD takes perhaps 7 seconds to go from boot to login screen. RHL takes about 20 seconds. I’d bet that Slackware boots closer to FreeBSD’s speed rather than RHL’s… That’s with a lot of services (anaconda, etc) disabled on RHL, btw.
I don’t buy that most unix admins have difficulty understanding how the SysV init system works. I hate it, but I understand how it works just fine. It’s not rocket science, after all.
OS X uses rc.* in single-user mode, and then uses NetInfo to initialize startup services once it’s gone multiuser.
The real core of these kinds of changes seems to be that UNIX, as UNIX, isn’t valid for the desktop. If the people who work on these projects, or use them, don’t like multiuser UNIX as their desktop, why not get rid of it? Make your own setup that boots with network services running, etc., but make it single-user only. No need for a login screen, or any of that other ‘unnecessary’ stuff. I’d think that’d be a more constructive use of skills and time, rather than building a kludgy ‘framework’ to replace simple no-overhead shell scripts designed to provide service startup and shutdown with an integrated framework that can start up and shut down services. Oh yeah, and query their status. I just don’t get it. The work the guy’s done on his natural language parser project is impressive. This is less so.
I like this idea. I was very interested in the init optimisation technique I read about recently (use make to manage dependancies between services, and launch all services whose dependancies have been fulfilled as parallel jobs). However, I still have issues with this:
1) I don’t believe in ‘servers vs. desktops’. My machine is mostly a desktop, but sometimes I use it as a router/mailserver/etc for another machine. It always runs mailservers etc for the local machine. It usually runs a database server (or two), a webserver (for local development), etc, etc.
2) How will this integrate with my distro? I quite like Debian’s service management already. If it has less features, or doesn’t allow stopping and starting immediately upon package installation, removal, or upgrade, then I don’t want it. Also, on Debian, if you upgrade a ‘base’ package (say, a library or something) that a few services depend on, the package manager can detect those services that need to be restarted, and do it automatically. I would miss that feature if it disappeared.
3) What if I want custom configurations that you haven’t planned for? What if I want 5 webservers running — 3 apache servers for different sites or security protocols, and two boa servers for something else. OK, that example is a little contrived, but hopefully you get the idea. Debian doesn’t yet handle this well either, but I’ve been hoping to see it/dreaming of implementing it. A system that didn’t manage this sort of complexity BY DESIGN would seem flawed, to me.
If those points are covered, and it does the other stuff promised in the write-up, then I’m all for it!
I really don’t understand why whenever a new idea is proposed that in anyway alters the existing Linux architecture, dozens of plush penguin weilding zealots flow into the arena screaming, “Burn her! Burn her!”
This is a good question. I don’t really understand it either. I don’t understand getting flamed by someone (including being told that I am living in the ’80s) because I have a different opinion than you. Remember opinions are like assholes, everyone has one and they all stink.
If you want to be left alone and live in the 80s, then go ahead and you your damned command line exclusively. Stick with an older version of whatever your favorite distro is. Meanwhile I will happily, quickly, and graphically boot into my Y window system on Gentoo 3.0.
Great, we are in agreement. I will use what I think is the best tool for the job and allows me to administer my servers in the quickest, most efficient manner. You will use the GUI and be happy as well. Yay!
For me the correct tool for admining my servers is not and never will be a GUI. I can’t afford the extra RAM required to keep a GUI running, especially since I only login to each server occasionally.
The GUI is here, it’s not leaving. Realizing that and dealing with it will make your life much easier. I swear, if some of the folks around here were in charge of these decisions I would be etching this message into a stone tablet.
What a profound statement. I guess I can get rid of the hammer and chisel that I am using to write this message then.
Seriously, for many of us it is not a reactionary, “I hate everything new” mentality. I have needs for my business. I have to make the most of my hardware purchases. This means that on my workstation I use Mozilla, and KMail. This also means that on my servers I use the minimum necessary to keep the server running well.
I use INIT runlevels to experiment with a new boot sequence
while keeping the old sequence working as a standby.
Single-user sucks! Even MacOS and Windows have realized that single-user OSs make no sense in today’s networked world. Talk about going back to the ’80s!
The majority of my machines don’t have/use any graphical interface, nor do they have X even installed on the machine. This sounds like a desktop-only process to me.
Not that the existing distros can’t be improved to get running faster, but the point is that they can if the user wants that.
I would also suspect that when the work in 2.6 on suspecd is mature, and that’s months not years, people who want a fast boot will just suspend to disk and be back up in a few seconds.
All of these make me think that this is a special case solution, not something which will or should be the new standard.
Hello,
are you in any way aware of the init script speedup by using make utils demonstrately lately by IBM DeveloperWorks? This system basically works that way:
Your dependencies end up being a makefile more or less. Some services need others to be run before starting them. Run levels are a target in this makefile.
Now the beauty is: make -j 5 boot_up
this run instead of init will execute 5 processes in paralell. The time spend busy waiting for something to appear makes booting slow. Not shell or something. The init scripts barely need modification. You can even change back to serial execution with: make book_up
So what gives python here? Nothing at all.
The DBus sounds like an interesting thing. I am sure a loadable Apache module could be written and a lean linking library could supply an interface to the desktop for all services.
But did you really think? Do you Gnome people suddenly want people to have options? Does it matter that much if inetd or init starts apache? Even if, my Debian allows for that already in a clean way. They add it to inetd.conf AND make the init script check if it’s commented in or out. All you need is to button to provide the comment. If you need that in your desktop.
The LSB standard is a good one. Enhance it with such good ideas as the Debian ones. Don’t write things anew that can easily be enhanced.
Why not just modify init to spawn a thread for each item with the same priority in the rc?.d directory? Give two thing the same priority, they go off at once.
Alternatively, specify the dependcies between services and simply use make (or a wrapper to it).
It seems to me that the boot time issue can be addressed immediately with little modification to anything…
1.Ask Which Boot profile (or do a step-by-step)
2.Boot services etc. Symoutaniously (i Know i thats not how you spell it)
3.Login
4.Start X
Am I the only person that things there is a problem with having a “Desktop Enviornment” the interfaces for system daemons?
I’m sure he will make it, I’m sure it will do everything include clean my kitchen, I’m sure I won’t use it.
The last thing I need is for the people that designed a desktop env. that requires a cray to start messing with my system.
I don’t understand getting flamed by someone (including being told that I am living in the ’80s) because I have a different opinion than you.
Flamed? Nay. The point I was trying to make is that both worlds can exist. I don’t complain about the existence of old interfaces, like the command line, so why do people instantly bash any new ideas? It’s not as if this has even made it out of the conceptual stage and people are already bashing it.
That does not make any sense to me. Wait and see. Maybe you’ll like it, maybe you won’t. Maybe it will have flaws, maybe they can be fixed. Either way, the old system still exists if you want it. Redhat 7.0, or whatever older OS you use will always be around for those that don’t like the new systems.
Remember opinions are like assholes, everyone has one and they all stink.
If you want to be left alone and live in the 80s, then go ahead and you your damned command line exclusively. Stick with an older version of whatever your favorite distro is. Meanwhile I will happily, quickly, and graphically boot into my Y window system on Gentoo 3.0.
Great, we are in agreement. I will use what I think is the best tool for the job and allows me to administer my servers in the quickest, most efficient manner. You will use the GUI and be happy as well. Yay!
Yes, of course. Please don’t think I am trying to attack those that use older systems. I have a P200 and a Celeron 300, they aren’t going to run the latest version of Gnome or KDE with all the bells and whistles and I’d rather not even try installing a DE for them.
I’m not arguing against folks like you Douglas. You are obviously reasonable about this. I just think that some people attack these newborn ideas with such zealotry that they will never get a chance to see how they could turn out.
I don’t understand getting flamed by someone (including being told that I am living in the ’80s) because I have a different opinion than you.
Flamed? Nay. The point I was trying to make is that both worlds can exist. I don’t complain about the existence of old interfaces, like the command line, so why do people instantly bash any new ideas? It’s not as if this has even made it out of the conceptual stage and people are already bashing it.
That does not make any sense to me. Wait and see. Maybe you’ll like it, maybe you won’t. Maybe it will have flaws, maybe they can be fixed. Either way, the old system still exists if you want it. Redhat 7.0, or whatever older OS you use will always be around for those that don’t like the new systems.
Great, we are in agreement. I will use what I think is the best tool for the job and allows me to administer my servers in the quickest, most efficient manner. You will use the GUI and be happy as well. Yay!
Yes, of course. Please don’t think I am trying to attack those that use older systems. I have a P200 and a Celeron 300, they aren’t going to run the latest version of Gnome or KDE with all the bells and whistles and I’d rather not even try installing a DE for them.
I’m not arguing against folks like you Douglas. You are obviously reasonable about this. I just think that some people attack these newborn ideas with such zealotry that they will never get a chance to see how they could turn out.
I wonder if somehow BSD can benefit from this. At least the idea of it. NetBSD’s init scripts is a step ahead in the booting process, but I also believe that it does need to get better.
The good thing is that BSD doesn’t have run levels. Either you’re in single-user mode, or multi-user mode. I wonder if that would make things easier for this to work on BSD systems.
And if you wanted to boot into GUI, then just enable xdm in your /etc/ttys file and BAM! you boot into a GUI. I’m pretty sure the process is similar for Linux. Well, instead of editing /etc/ttys you just edit whatever file it may be to boot into xdm. I don’t remember what run mode that was since it’s been a long time since I’ve used Linux.
But anyway, yeah service start up on Unix (as a whole) needs to get better and this might be a step in the right direction.
Just in case someone might get the wrong idea that I’m bashing the init (rc.*) system of NetBSD, I’m not. It’s actually quite good and my FreeBSD box boots up very fast. But, I like the idea of catching exceptions if the service doesn’t start and stuff like that. I just think further functionality can be added. That’s all. Other than that, the NetBSD rc.* system is pretty good.
There’s this thing that my company keeps pusing. Some japanese thing called Kaizen. It means constant gradual improvemnt or something like that. Everything can be made better. So I admire those that take the inititive to try to make things better.
There’s nothing preventing a “daemon” from also being an init script – people don’t usually write it that way because doing so would LIMIT an admin’s ability to modify start-up stuff in a familiar language. If you want to release a binary that can be suitably run as an init script, just code it that way.
The only reason all the distro’s still use init scripts slightly differently is because no one has yet published a compelling standard for enhancing their functionality. Publish a document and convince the guys at either Redhat or LSB to add features uniformly to all the init scripts they support and you’ll have a good base that others will probably start to copy.
The only thing you’re really offering to programmers is a standardized implementation of profiles – and you’re really not sure you want to offer that. It’s the only useful suggestion this project includes. Redhat has started to put some concept of profiles into its network startup scripts, but abstracting the concept out far enough that it can apply instead of runlevels would be a useful improvement.
For example, runlevels 3 and 5 are the only ones people typically change – but why can’t I create runlevels, 8, 9, and “home”? If init were cognizant of user defined “profiles”, which is really just another word for “runlevels”, as opposed to just being aware of modifications to predefined runlevels, then distros wouldn’t have to re-invent that implementation in their init scripts.
Sounds like this does almost the same thing:
http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOv…
Lycoris has a desktop that starts up very quickly and does not have anything that a desktop doesn’t need. I mean–not even xinetd (or inetd). Good. But UNIX and GNU/Linux were designed from the ground up to be timesharing systems. At home, I don’t know what you want to do, but in an organization (perhaps even at home) it makes no sense to run a GNU/Linux desktop OS on all your PCs.
It makes far more sense to run it on desktop servers that provide GUI desktops and GUI applications to X terminals. It’s a networked, timesharing system all the way. Trying to change it into something that isn’t, is twisting it in ways fundamentally opposed to its use… You should, in that case, be using Embedix or something.
In the market place, Linux manageability as a terminal server makes vastly more sense. It’s far easier to manage and a fraction of the cost, both upfront and longterm. Windows has absolutely no remote chance of matching the value proposition.
Matthew
Gentoo already have depencity build in …Example :
$ cat /etc/init.d/apache
#!/sbin/runscript
….
# Copyright 1999-2003 Gentoo Technologies, Inc.
…..
depend() {
need net
use mysql dns logger netmount
}
…
I’m glad I’m using *BSD, so I don’t have to worry about this weird idea replacing a system that already worked fine, and overnight for that matter. My linux experience was mainly with Slackware, and I had very quick bootup times. Now that I’m using FreeBSD, even more so. I’ve also heard great things about NetBSD in this respect, probably much faster than this hacky idea.
Anyway, I don’t think using the language of the week is a good idea, even if it is technically faster or prettier. If you ask me, the best solution is to dump sysV init and just go along with BSD init. It was first, anyway. If not that, then just stay with sysV init.
–Tim
My two biggest remaining complaints with Linux are the
audio situation, KDE apps don’t work well with other
apps and vice versa, and boot up and shutdown times.
I say build the new init system and if it is better and
cleaner than the old system then people will use it, me
included. And the DBUS idea sounds great, been needed
for a long time.
This just shows why GUI developers should stick with GUI development, and let others deal with the OS level coding. Notice how there isn’t much desire to create a runlevel concept, and all focus is on the UI. Well, just because a typical end user doesn’t care about managing/maintaining their system in a modular way, doesn’t mean it isn’t the right thing to do. I find it quite useful to be able to go to runlevel 5 to get an X login, and then bail back to runlevel 3 that has the advantage of quicker booting, not hogging all the resources that most of todays WMs do. All he’s really interested is in making Gnome better. Sounds a lot like M$ plugging IE into their OS – STUPID!!! Other posters have said it, and I’ll reiterate, if init needs more capability, add it, don’t reinvent the wheel. It may be old code and an old concept, but what works works. Make fixes, add new features, but don’t throw out a program/concept that has been good enough to last as long as init has. That’s just being short-sighted and M$-ish. Change it for the sake of changing it…. Find something more useful to spend time on, for crying out loud. I personally don’t even find Gnome useful, as compared to other WMs. Go work on it instead.
Mostly Dittos.
If it is broke, then it is OK to fix it. But is the way init works broken?
The different runlevels exist, because linux is not the OS of a single-user, single-tasking, unnetworked platform from where Windows draws its roots. Good system administration sometimes NEEDS no gui, or no network services, or no user other than root logging in.
The fact that linux is being used on the desktop has more to do with the fact that linux is lightweight and can run on the desktop, even though it can also supply the services used by major enterprise servers.
If the problem is really that Red Hat and Suse (and others) use different scripting methods to stop/start/restart services, then maybe the real crusade is to convince the distro builders to agree to something more unified.
I’m worried about this becoming bloaty-ware. My take on it is that services would be required to support some start/stop config GUI interface. This is overhead that a currently tiny daemon would not have to manage? Doesn’t sound better/faster to me.
Once I got my laptop configured I turned off the things that were non-essential and bootup time became dramatically faster — this is the “fix” most desktop users need to do; just know how to turn services off.
Using Mac OS X and Linux daily, I have noticed that the Mac OS X 10.2 SystemStarter is much faster than the Linux init system. SystemStarter builds a dependency tree and then runs everything it can in parallel, starting items dependent on a previous item only if the first item ran correctly. Mac OS X 10.1 ran everything sequentually and at about the speed of the Linux init system.
The Mac OS X SystemStarter is not graphical, it just usally starts graphically if the user wants it, but does not need to do so. No reason this should behave the same way.
To me the big advantage of Linux is that most of its services are NOT integrated with one another.
I have had more experience working with Windows 2000 server than I care to admit. Its centralized around Active Directory (and now even Internet Information Services). When one of those two go down, they take a great deal with them.
Lets avoid that.