newb question: I would like to know how upstart handles boot up - specifically whether it (eventually) just runs rc as before with a runlevel eg 2, so that the links in rc2.d are used as before (and I can just enable/disable them there). A second question is: how can one configure upstart and control what run level it chooses at boot up? The upstart site does not give an explanation as to how upstart is used in Ubuntu 7.10 I don't think.
Having done a bit more searching on upstart: It looks as if upstart uses job scripts in /etc/event.d One of these is rc-default. This script seems to check for inittab and use whatever is in there so I could create an etc/inittab file and just put eg id:3:inittab in it to get default runlevel 3 (and customise this in /etc/rc3.d). I'm not really happy with this as it seems retrogressive - I'd far rather understand upstart properly! Further note: Looking at rc-default: - this checks /proc/cmdline for an S (not sure why) and do telinit S (for what???) - if not, looks for inittab and if it finds eg id:3:inittab in there, uses telinit 3 (there is no inittab in recent versions of Ubuntu, but could make one) - otherwise it uses telinit 2 I think telinit 2 would execute script /etc/event.d/rc2 which executes rc with parameter 2 This then runs all scripts pointed to by links in /etc/rc2.d to start up services. So to change the default runlevel to say 3, rather than create an inittab file, alter the two references to telinit 2 in rc-default to telinit 3 (I have tested this and it works OK), then alter links in /etc/rc3.d as per the README there to control startup of services as desired for runlevel 3. The runlevels are used as follows: 0 halt, 1 single user, 2-5 multi-user, 6 restart. Ubuntu uses 2 by default and initially 2-5 are identical. I hope all this is correct - maybe a more experienced Linux user could check it! Thanks. I wonder if this will keep changing in future versions... particularly will upstart keep running rc-default?
Further to this: I think this is how upstart works at boot up: - it starts up and monitors scripts ('jobs') in /etc/event.d all the time. - any job headed 'start on startup' will be run at boot up time (/etc/event.d/rcS is the only one that has this: at the moment it does backward -compatible calls to the old single-user startups via /etc/init.d/rcS which calls scripts pointed to by links in /etc/rcS.d etc) - another job called rc-default has 'start on stopped rcS' so will be called next when /etc/event.d/rcS stops (at the moment this makes backward-compatible calls to the old scripts as in the above post). I think in future if one knows where the upstart job scripts are (currently /etc/event.d) it is possible to follow the boot sequence by just looking for 'start on startup' in a job and following other starts that may get triggered as a result. I would imagine that the old scripts in /etc/init.d will in future become jobs in /etc/event.d which start in sequence (if needed) or all at once, defined by their 'start on' lines. I would think that to disable a service all that will be required is to modify it's 'start on' line. Of course any jobs waiting to start on this job's termination would not start - but that would be bad design of the jobs if that were the case surely? Not sure how runlevel equivalents would be achieved though - it's really nice to have a 'fileserver', 'webserver' etc runlevel for different occasions. A slight disadvantage is that to modify the boot sequence or disable a service start may need understanding of the scripting language. Modified 'start on's could potentially cause uncontrolled start-stop looping! Let's hope the designers put in lots of comments! I would appreciate comments from an experienced linuxer please... thanks.
