Re: Upstart
>> 1. Why does /lib/init/upstart-job direct us to use service rather than >> initctl? > Because /usr/sbin/service can handle the start/stop/restart/status > actions of both traditional System V init scripts in /etc/init.d as > well as Upstart scripts in /etc/init. > It's intended to be one-stop-shopping for managing services in either > /etc/init.d or /etc/init. Many thanks for the explanation. >> 999. Could initctl be made to recognize, for example, both >> avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare >> but it happens - and type "stop av//tab//", I end up with "stop >> avahi-daemon.conf" which, after pressing //enter// results in an >> "unknown job" message.) > As answered above, that's service(8)'s job ;-) Perhaps that it is service's job, but it is also initctl's; and without, bash_completion, neither can distinguish between avahi-daemon and avahi-daemon.conf. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
>>> 999. Could initctl be made to recognize, for example, both
>>> avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare
>>> but it happens - and type "stop av//tab//", I end up with "stop
>>> avahi-daemon.conf" which, after pressing //enter// results in an
>>> "unknown job" message.)
>> That sounds like the lack of a specialised bash-completion function?
> This seems to do the job (except for completions of arguments for --dest):
> --8<---cut here---start->8---
> _stop()
> {
> local cur
>
> COMPREPLY=()
> cur=${COMP_WORDS[COMP_CWORD]}
>
> case "$cur" in
> -*)
> COMPREPLY=( $( compgen -W '-n --no-wait --system --dest -q
> --quiet -v --verbose --help --version' -- $cur ) )
> ;;
> *)
> COMPREPLY=( $(initctl list| awk "/^$cur/ {print \$1}" ) )
> ;;
> esac
>
> return 0
>
> }
> complete -F _stop stop
> --8<---cut here---end--->8---
It works perfectly, thanks. I have never used bash_completion before;
it completes "avahi-daemon" no matter which dir I am in.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
On Sun, Mar 7, 2010 at 2:21 PM, Tom H wrote: > Patrick's two Upstart posts reminded me of 2.5 queries of my own. > > 1. Why does /lib/init/upstart-job direct us to use service rather than > initctl? Because /usr/sbin/service can handle the start/stop/restart/status actions of both traditional System V init scripts in /etc/init.d as well as Upstart scripts in /etc/init. It's intended to be one-stop-shopping for managing services in either /etc/init.d or /etc/init. > 999. Could initctl be made to recognize, for example, both > avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare > but it happens - and type "stop av//tab//", I end up with "stop > avahi-daemon.conf" which, after pressing //enter// results in an > "unknown job" message.) As answered above, that's service(8)'s job ;-) :-Dustin -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
Jan Claeys writes:
> Op zondag 07-03-2010 om 15:21 uur [tijdzone -0500], schreef Tom H:
>> 999. Could initctl be made to recognize, for example, both
>> avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare
>> but it happens - and type "stop av//tab//", I end up with "stop
>> avahi-daemon.conf" which, after pressing //enter// results in an
>> "unknown job" message.)
>
> That sounds like the lack of a specialised bash-completion function?
This seems to do the job (except for completions of arguments for --dest):
--8<---cut here---start->8---
_stop()
{
local cur
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
case "$cur" in
-*)
COMPREPLY=( $( compgen -W '-n --no-wait --system --dest -q
--quiet -v --verbose --help --version' -- $cur ) )
;;
*)
COMPREPLY=( $(initctl list| awk "/^$cur/ {print \$1}" ) )
;;
esac
return 0
}
complete -F _stop stop
--8<---cut here---end--->8---
Florian
--
GUIs programmieren mit Python und Glade:
Re: Upstart
Op zondag 07-03-2010 om 15:21 uur [tijdzone -0500], schreef Tom H: > 999. Could initctl be made to recognize, for example, both > avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare > but it happens - and type "stop av//tab//", I end up with "stop > avahi-daemon.conf" which, after pressing //enter// results in an > "unknown job" message.) That sounds like the lack of a specialised bash-completion function? -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
> So, I'm testing samba on a Lucid alpha 3, and I decide to restart the > smbd daemon: > sudo /etc/init.d/samba restart > sudo: /etc/init.d/samba: command not found > Oops, I guess it's a service now? > sudo service samba restart > samba: unrecognized service > So of course it only took a little digging to discover that smbd and > nmbd are now services started separately, and that (bizarrely) there is > now a winbind daemon which is still started from /etc/init.d, but > nevertheless a bit unnerving. (And why and since when has winbind been a > separate daemon, anyway?! But I digress.) I assume that the samba job has been split into two because there was a problem with nmbd not starting when smbd and nmbd were launched through samba. If you look at the respective conf files, you will see that nmbd requires a nic other than lo to be up before starting. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
On Fri, 2010-03-05 at 14:50 -0600, Patrick Goetz wrote: > > D-Bus is used to communicate with the init daemon, and one of the method > > calls you may make is to emit an event. The event name is simply a > > string, and the arguments an array of strings. There's no need to > > configure Upstart to accept certain events, you just make them up as you > > go along. > > > > Thanks for the detailed response, this is all starting to make sense. > So if service Z can't start until services A,B, and C have already > started the /etc/init/Z.conf file would contain the line: > >start on (A started and B started and C started) > ? > We don't tend to describe it that way. We say that "service Z should be started as a result of services A, B and C having been started". (Because a sysadmin can always come along and run "start Z" by themselves) > And if D alternatively replaces A and C, then this becomes > >start on ((A started and B started and C started) or > (B started and D started)) > ? > Yes. > One last question. I'm curious about the technical details of how this > is implemented; i.e. what blocks Z until A,B, and C have started? Does > upstart or some process simply make a list of /\/etc\/init\/(.+)\.conf/ > and then poll through the list in a loop looking to see if the 'start > on' conditions have already been met => send a startup $1 signal to > init, remove $1 from the list whenever it does? > No, this describes a fairly poorly implemented dependency based init system. Upstart is event based, and is thus the exact opposite. Upstart parses all *.conf files under /etc/init and creates in-memory objects for each of them, which have event matches. Each time an event occurs, Upstart marks any event matches as TRUE for them. If a job's event tree is TRUE, then it gets started. A good way of describing the difference is: a dependency based system (such as you described) thinks "can I start foo yet? no, it needs bah" an event based system (like Upstart) thinks "bah just started, what else can I start now?" Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
Scott James Remnant wrote: > You might have forgotten to plug your USB > mouse in this boot; or maybe your cat has chewed the ethernet cable > overnight and it won't come up, etc. > Actually, it was my gerbil that frequently chewed through the ethernet cable, but then the cat ate the gerbil, so that bug has been resolved, so to speak. > D-Bus is used to communicate with the init daemon, and one of the method > calls you may make is to emit an event. The event name is simply a > string, and the arguments an array of strings. There's no need to > configure Upstart to accept certain events, you just make them up as you > go along. > Thanks for the detailed response, this is all starting to make sense. So if service Z can't start until services A,B, and C have already started the /etc/init/Z.conf file would contain the line: start on (A started and B started and C started) ? And if D alternatively replaces A and C, then this becomes start on ((A started and B started and C started) or (B started and D started)) ? One last question. I'm curious about the technical details of how this is implemented; i.e. what blocks Z until A,B, and C have started? Does upstart or some process simply make a list of /\/etc\/init\/(.+)\.conf/ and then poll through the list in a loop looking to see if the 'start on' conditions have already been met => send a startup $1 signal to init, remove $1 from the list whenever it does? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
On Fri, 2010-03-05 at 12:27 -0600, Patrick Goetz wrote: > So of course it only took a little digging to discover that smbd and > nmbd are now services started separately, and that (bizarrely) there is > now a winbind daemon which is still started from /etc/init.d, but > nevertheless a bit unnerving. (And why and since when has winbind been a > separate daemon, anyway?! But I digress.) > > During the transition from Debianized Sys V Init to Upstart, how > difficult would it be to keep the comfortable old /etc/init.d scripts in > place, but so that these scripts simply tell command line users > something like: > > pgo...@data:~$ sudo /etc/init.d/samba restart > > The samba daemons are now started individually as services: try > service smbd restart > and/or > service nmbd restart > Oh, and note that winbindd is now a separate process -- happy debugging! > > > Again, some people, possibly myself, are old, feeble-minded, and > distracted with lots of problems that go beyond the function of basic > linux server services, hence discomfited when start/stop/restart > commands that have worked for 10 years are suddenly missing with no > explanation of how to proceed in the new world order. > That's exactly what we've done for the most part: quest scott# /etc/init.d/cron restart Rather than invoking init scripts through /etc/init.d, use the service(8) utility, e.g. service cron restart Since the script you are attempting to invoke has been converted to an Upstart job, you may also use the restart(8) utility, e.g. restart cron cron start/running, process 20151 Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
On Fri, 2010-03-05 at 12:09 -0600, Patrick Goetz wrote: > Scott James Remnant wrote: > > Anyone can emit any event. That's probably the bit of Upstart that > > people find the hardest to get to grips with, so there can never be any > > comprehensive list of every event and every argument - because anyone > > can add a new one. > > > From a system administrators' perspective, this sounds like a debugging > nightmare, since anyone not documenting an emitted event as outlined > above leaves you with no idea of what is going on or how things > interact. I think it's extremely important to either have or be able to > produce a text file which definitely indicates the sequence(s) of > [particular] event dependencies. (I.e., I don't want to rely on > someone's remembering to put a comment in a text file, I want to know > what's actually going on for sure.) > An event is simply an abstraction of some kind of change to your computer's state; it might be new hardware being detected, it might be a particular filesystem (or group of filesystems) being mounted. It might even be the user pressing a key combination on the keyboard, or shutting the lid. They don't have "dependencies", nor do they have ordering or sequences. Upstart was designed from the principle that since we can no longer control the order that things happen in, or even whether certain things happen, we should instead design a system that lets you define what a service needs. You can't know what's going on for sure without letting the computer boot and see what happens. You might have forgotten to plug your USB mouse in this boot; or maybe your cat has chewed the ethernet cable overnight and it won't come up, etc. > The events are emitted over D-bus? Unfortunately I don't know much > about d-bus, so pardon my ignorance if this is a dumb question, but is > there some kind of Upstart d-bus configuration file which documents all > the events the upstart daemon is configured to handle? How does Upstart > decide how to sequence services based on the events they emit? > D-Bus is used to communicate with the init daemon, and one of the method calls you may make is to emit an event. The event name is simply a string, and the arguments an array of strings. There's no need to configure Upstart to accept certain events, you just make them up as you go along. Upstart doesn't "sequence services". > Perhaps a specific example would help: > > Let's say, for the sake of argument, that autofs is failing to start > because of some daemon initialization timing problem (I use this example > because this is a problem we've actually had with Ubuntu desktop clients). > > 1. > How would I go about figuring out what the *linear* sequence of events > is related to the autofs service? I.e. I understand that lots of stuff > is going to be started in parallel, but I want to know the startup > dependencies for that particular service. This was very easy to figure > out with System V init on Debian: >ls /etc/rc2.d > followed by a few peeks at files in /etc/init.d. > There is no *linear* sequence of events. Purge that assumption from your mind. In an Upstart system, you look at the "start on" (or "while" in future versions) line in the /etc/init/autofs.conf file. That tells you what condition will cause autofs to be started/running. > 2. > OK, I've rolled out Ubuntu X.Y and discover that a (mission-critical) > service is not starting because of an event sequencing boo-boo, > intermittent timing problem, or what not. In 9.4, for autofs, we solved > this by throwing a few sleep 1's in the /etc/init.d/autofs file > What recourse do I have to fix the problem myself on an Upstart-based > system? Please note that in trenches one encounters fire-breathing > dragon users who aren't satisfied with the response "oh, we logged a bug > on launchpad, so this should be working in a couple of weeks -- we > hope.". System administrators who like to stay employed are most > comfortable with solutions, even if hacks or band-aids, that they can > deploy themselves while waiting for the Olympians to act. <:) > Simple; you'd modify the /etc/init/autofs.conf file and either fix the "start on"/"while" line (which must be wrong if the service is failing to start) - or modify the script/exec lines to correct how autofs is started. > 3. > I have to install a commercially provided service and these bozos > couldn't care less about dpkg, Ubuntu, or anything other than their > lucre (why is lucre always filthy?). The service is probably a license > manager, or something like this. How does this interface with the > Upstart Init system? Just stuff everything into /etc/rc.local and hope > for the best? > If you're providing something commercially, and aren't particularly targeting any distro, you should follow the LSB specifications - which include things like service management. Ubuntu implements these LSB specs. > 4. > Presumably there m
Re: Upstart (now, a very modest suggestion)
On Fri, 05 Mar 2010 13:54:48 -0500 Ben Gamari wrote: > Excerpts from Patrick Goetz's message of Fri Mar 05 13:27:52 -0500 > 2010: > > So of course it only took a little digging to discover that smbd > > and nmbd are now services started separately, and that (bizarrely) > > there is now a winbind daemon which is still started > > from /etc/init.d, but nevertheless a bit unnerving. (And why and > > since when has winbind been a separate daemon, anyway?! But I > > digress.) > > With all due respect, you are using alpha software. Documentation is > generally one of the last things to be completed. I would hope these > init changes will be thoroughly documented before release. Moreover, > it sounds like most of what confused you were changes in Samba's > packaging, not upstart itself. At the same time, it never hurts to be reminded, most of all about missing docs. > > > > Again, some people, possibly myself, are old, feeble-minded, and > > distracted with lots of problems that go beyond the function of > > basic linux server services, hence discomfited when > > start/stop/restart commands that have worked for 10 years are > > suddenly missing with no explanation of how to proceed in the new > > world order. > > > Certainly, but if you are having difficulty with this, you probably > ought to stick with releases. I am sorry, but I do not agree. The difficulty one (be it Patrick, or whoever) is having on a development release will probably be even greater after a release. Even more, we *need* testers, and we *need* to have feedback. Feedback after the release of a version will probably only be acted on for the next release, while feedback during development allows for (possible) action in time for the release. I would rather have a lot of (even misguided) feedback than none at all (and, by the way, I think Patrick is raising some good points). Cheers, ..C.. signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
Excerpts from Patrick Goetz's message of Fri Mar 05 13:27:52 -0500 2010: > So of course it only took a little digging to discover that smbd and > nmbd are now services started separately, and that (bizarrely) there is > now a winbind daemon which is still started from /etc/init.d, but > nevertheless a bit unnerving. (And why and since when has winbind been a > separate daemon, anyway?! But I digress.) With all due respect, you are using alpha software. Documentation is generally one of the last things to be completed. I would hope these init changes will be thoroughly documented before release. Moreover, it sounds like most of what confused you were changes in Samba's packaging, not upstart itself. > > During the transition from Debianized Sys V Init to Upstart, how > difficult would it be to keep the comfortable old /etc/init.d scripts in > place, but so that these scripts simply tell command line users > something like: > Just use the service command. It's the way things are going to work moving forward. It wouldn't be difficult to write wrapper scripts, but we really do need to move beyond SysV. > > Again, some people, possibly myself, are old, feeble-minded, and > distracted with lots of problems that go beyond the function of basic > linux server services, hence discomfited when start/stop/restart > commands that have worked for 10 years are suddenly missing with no > explanation of how to proceed in the new world order. > Certainly, but if you are having difficulty with this, you probably ought to stick with releases. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
So, I'm testing samba on a Lucid alpha 3, and I decide to restart the smbd daemon: sudo /etc/init.d/samba restart sudo: /etc/init.d/samba: command not found Oops, I guess it's a service now? sudo service samba restart samba: unrecognized service So of course it only took a little digging to discover that smbd and nmbd are now services started separately, and that (bizarrely) there is now a winbind daemon which is still started from /etc/init.d, but nevertheless a bit unnerving. (And why and since when has winbind been a separate daemon, anyway?! But I digress.) During the transition from Debianized Sys V Init to Upstart, how difficult would it be to keep the comfortable old /etc/init.d scripts in place, but so that these scripts simply tell command line users something like: pgo...@data:~$ sudo /etc/init.d/samba restart The samba daemons are now started individually as services: try service smbd restart and/or service nmbd restart Oh, and note that winbindd is now a separate process -- happy debugging! Again, some people, possibly myself, are old, feeble-minded, and distracted with lots of problems that go beyond the function of basic linux server services, hence discomfited when start/stop/restart commands that have worked for 10 years are suddenly missing with no explanation of how to proceed in the new world order. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
Scott James Remnant wrote: > Anyone can emit any event. That's probably the bit of Upstart that > people find the hardest to get to grips with, so there can never be any > comprehensive list of every event and every argument - because anyone > can add a new one. > > However there are "recommendations". > > > First is that if the service a job represents emits an event, it uses > the (purely documentation) "emits" stanza in its job file. That way you > can get a rough idea by parsing /etc/init/*.conf > > $ grep "emits local-filesystems" /etc/init/*.conf > /etc/init/mountall.conf:emits local-filesystems > > So local-filesystems comes from the mountall service. > From a system administrators' perspective, this sounds like a debugging nightmare, since anyone not documenting an emitted event as outlined above leaves you with no idea of what is going on or how things interact. I think it's extremely important to either have or be able to produce a text file which definitely indicates the sequence(s) of [particular] event dependencies. (I.e., I don't want to rely on someone's remembering to put a comment in a text file, I want to know what's actually going on for sure.) The events are emitted over D-bus? Unfortunately I don't know much about d-bus, so pardon my ignorance if this is a dumb question, but is there some kind of Upstart d-bus configuration file which documents all the events the upstart daemon is configured to handle? How does Upstart decide how to sequence services based on the events they emit? Perhaps a specific example would help: Let's say, for the sake of argument, that autofs is failing to start because of some daemon initialization timing problem (I use this example because this is a problem we've actually had with Ubuntu desktop clients). 1. How would I go about figuring out what the *linear* sequence of events is related to the autofs service? I.e. I understand that lots of stuff is going to be started in parallel, but I want to know the startup dependencies for that particular service. This was very easy to figure out with System V init on Debian: ls /etc/rc2.d followed by a few peeks at files in /etc/init.d. 2. OK, I've rolled out Ubuntu X.Y and discover that a (mission-critical) service is not starting because of an event sequencing boo-boo, intermittent timing problem, or what not. In 9.4, for autofs, we solved this by throwing a few sleep 1's in the /etc/init.d/autofs file What recourse do I have to fix the problem myself on an Upstart-based system? Please note that in trenches one encounters fire-breathing dragon users who aren't satisfied with the response "oh, we logged a bug on launchpad, so this should be working in a couple of weeks -- we hope.". System administrators who like to stay employed are most comfortable with solutions, even if hacks or band-aids, that they can deploy themselves while waiting for the Olympians to act. <:) 3. I have to install a commercially provided service and these bozos couldn't care less about dpkg, Ubuntu, or anything other than their lucre (why is lucre always filthy?). The service is probably a license manager, or something like this. How does this interface with the Upstart Init system? Just stuff everything into /etc/rc.local and hope for the best? 4. Presumably there must be developers' documentation for Upstart so that services can be coded to emit d-bus events? Where might one find this documentation? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart? Plymouth?
On Wed, 2010-02-24 at 11:50 -0600, Patrick Goetz wrote: > And probably way to busy to work on documentation. At some point it > would be nice to have a better understanding of how upstart works. The > concept of an event driven init replacement isn't completely jelling in > my little peanut brain; even more so as a replacement for cron/anacron. > > For example, in /etc/init/networking.conf one finds > > start on (local-filesystems >and stopped udevtrigger) > > Hookay, but what/where is "local-filesystems"? I can't find a conf file > for this in /etc/init, although there is one for udevtrigger. > Anyone can emit any event. That's probably the bit of Upstart that people find the hardest to get to grips with, so there can never be any comprehensive list of every event and every argument - because anyone can add a new one. However there are "recommendations". First is that if the service a job represents emits an event, it uses the (purely documentation) "emits" stanza in its job file. That way you can get a rough idea by parsing /etc/init/*.conf $ grep "emits local-filesystems" /etc/init/*.conf /etc/init/mountall.conf:emits local-filesystems So local-filesystems comes from the mountall service. Second is that the service actually documents the event in the form of a manpage (this was missing in karmic, but added in lucid). So $ man 7 local-filesystems DESCRIPTION The local-filesystems event is generated by the moun‐ tall(8) daemon after it has mounted all local filesystems listed in fstab(5). mountall(8) emits this event as an informational signal, services and tasks started or stopped by this event will do so in parallel with other activity. This event is typically used by services that must be started in order for remote filesystems, if any, to be activated. Remember that some users may not consider it wrong to place /usr on a remote filesystem. For most normal services the filesystem(7) event is sufficient. This event will never occur before the virtual-filesys‐ tems(7) event. EXAMPLE A service that wishes to be running once local filesys‐ tems are mounted might use: start on local-filesystems > Right now in Lucid things are a bit of a mess, with a bunch of stuff in > /etc/init and a bunch of other very similar stuff in /etc/init.d. Not a > problem of course if everything just works flawlessly right out of the > box so that I don't even have to think about it, but. <:) > That's because all this is still in development. I've asked nicely to spend the next cycle "finishing" Upstart :-) Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart? Plymouth?
Scott James Remnant wrote: > This is a bug that I'm working on. > > The problem is there's no code in Plymouth to put the VT back ;-) > And probably way to busy to work on documentation. At some point it would be nice to have a better understanding of how upstart works. The concept of an event driven init replacement isn't completely jelling in my little peanut brain; even more so as a replacement for cron/anacron. For example, in /etc/init/networking.conf one finds start on (local-filesystems and stopped udevtrigger) Hookay, but what/where is "local-filesystems"? I can't find a conf file for this in /etc/init, although there is one for udevtrigger. Right now in Lucid things are a bit of a mess, with a bunch of stuff in /etc/init and a bunch of other very similar stuff in /etc/init.d. Not a problem of course if everything just works flawlessly right out of the box so that I don't even have to think about it, but. <:) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart? Plymouth?
On Mon, 2010-02-22 at 17:17 -0600, Patrick Goetz wrote: > I'm trying to track down a Lucid AMD64 Server bug to either Upstart or > plymouth, and realized I have no idea how the system decides what vt > console gets focus after boot when no xserver is installed. Can anyone > direct me to some relevant Upstart documentation? > This is a bug that I'm working on. The problem is there's no code in Plymouth to put the VT back ;-) Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
