| === laszlop [n=laszlo@CPE0015e976f21f-CM0017ee427a40.cpe.net.cable.rogers.com] has joined #upstart | ||
| === laszlop [n=laszlo@CPE0015e976f21f-CM0017ee427a40.cpe.net.cable.rogers.com] has left #upstart ["Konversation] | ||
| === jme [n=jme@c-24-7-89-173.hsd1.ca.comcast.net] has joined #upstart | ||
| [chaoticg33k(n=chaoticg@alphabox.cxw.utoledo.edu)] hello | 12:54 | |
| === mbiebl [n=michael@e180086068.adsl.alicedsl.de] has joined #upstart | ||
| === justin__ [i=justin@59.92.143.121] has joined #upstart | ||
| jme | I suppose this is the wrong place to ask re Usplash configuration | 01:49 |
|---|---|---|
| === jme [n=jme@c-24-7-89-173.hsd1.ca.comcast.net] has left #upstart ["Leaving"] | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === tapas [n=tapas@affenbande.org] has left #upstart [] | ||
| === oneman [n=oneman@ip24-254-239-184.hr.hr.cox.net] has joined #upstart | ||
| oneman | my upstart jobs in edgy are not starting on startup.. | 05:45 |
| oneman | it works with start and stop | 05:45 |
| oneman | i also notice it doesn't work with daemons that fork off and become a session leader.. | 05:46 |
| _ion | Add something like 'start on runlevel-2' | 05:47 |
| _ion | Add 'daemon' for a forking daemon. | 05:47 |
| oneman | ive got start on startup :P | 05:51 |
| oneman | where do i put daemon, just anywhere? | 05:51 |
| _ion | "start on startup" means that it's started before filesystems have been checked, or networking has been started, or syslogd has been started etc. | 05:59 |
| _ion | Yes. | 05:59 |
| _ion | I'd put it just before or after the 'exec foo' or 'respawn foo' line, or just before the 'script' block. | 05:59 |
| oneman | ohh | 06:01 |
| oneman | ok, for lighttpd | 06:02 |
| oneman | daemon worked for starting, but it doesn't kill it on stop | 06:02 |
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === cfedde [i=cfedde@fedde.littleton.co.us] has joined #upstart | ||
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| oneman | upstart is cool | 07:00 |
| oneman | but its apha betaboy stuff | 07:00 |
| oneman | and you have to go talk to the developers themselfs on internet chat to get them to tell you secret undocumented information to really do anything | 07:01 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === H__2 [n=hans@mail.sangine.com] has joined #upstart | ||
| H__2 | anyone awake ? | 10:56 |
| Keybuk | yup | 11:02 |
| Keybuk | what's up? | 11:02 |
| H__2 | i have a question about the new developments : the job-starting and such. Is the following planned : when service A requires service B, and B is restarted, is then A stopped before B stops and A started after B started again ? | 11:04 |
| Keybuk | it depends | 11:05 |
| H__2 | ;-) | 11:06 |
| Keybuk | if A wants to be restarted when B is restarted, it would indicate as such in its job definition | 11:06 |
| Keybuk | e.g. | 11:06 |
| Keybuk | stop on job-stopped B | 11:06 |
| Keybuk | start on job-started B | 11:06 |
| H__2 | ok, does "stop on job-stopped B" mean that A stops after B stopped ? | 11:06 |
| Keybuk | no | 11:07 |
| Keybuk | it means B stops because A is | 11:07 |
| H__2 | Can't follow you there. This is the scenario : A requires B. B is restarted, the question is what happens to A, and in what order | 11:08 |
| Keybuk | B is stopped | 11:08 |
| Keybuk | A is stopped | 11:08 |
| Keybuk | B is started | 11:08 |
| Keybuk | A is started | 11:08 |
| Keybuk | with that example | 11:08 |
| H__2 | exactly, so A stops after B stopped. I think that is wrong. | 11:09 |
| Keybuk | if you needed it in the other order, you'd use "stop on job-pre-stop B" or similar | 11:09 |
| Keybuk | upstart doesn't enforce any of this, it simply issues sufficient events for you to define the behaviour | 11:09 |
| H__2 | ah, perfect :) | 11:09 |
| H__2 | very interesting | 11:10 |
| H__2 | another small question : from the website "being developed for the Ubuntu distribution" does that mean that Ubuntu now actively uses it, or that it is targetted to replacing the system currently present in ubuntu ? | 11:11 |
| thom | H__2: ubuntu now uses it | 11:12 |
| H__2 | nice, thanks. Will look into it. | 11:13 |
| Keybuk | (as of the release of edgy, yesterday) | 11:14 |
| H__2 | is there a way in upstart to draw a dependency graph of a bunch of scripts that subscribed to upstart's events ? | 11:20 |
| Keybuk | there may be eventually, yes | 11:20 |
| Keybuk | I think that such a thing would be useful | 11:20 |
| H__2 | heh :) I've been drawing those by hand and sometimes using graphviz ;-) | 11:21 |
| === Keybuk uses graphviz | ||
| Keybuk | I figured upstart would output dotty | 11:21 |
| H__2 | the example jobs from the homepage (http://upstart.ubuntu.com/download/example-jobs-2.tar.gz) don't have "job-pre-stop"-level rules, is there a second list of examples available for download perhaps ? | 11:29 |
| Keybuk | job-pre-stop rules don't exist yet | 11:31 |
| Keybuk | upstart's still in heavy development | 11:32 |
| Keybuk | they're planned for the 0.3 series | 11:32 |
| H__2 | ow ;-) | 11:32 |
| H__2 | I got the impression from your ' you'd use "stop on job-pre-stop B" ' that it was already available ;-) | 11:33 |
| Keybuk | you'd use "stop on B/stopping" at the moment | 11:33 |
| Keybuk | (and "start on B/starting") | 11:34 |
| Keybuk | they mean about the same thing | 11:34 |
| H__2 | well, it's a race we suffer from at the moment. So we still must use our proprietary solution | 11:34 |
| H__2 | another question : is the event queue re-read and any new (or removed) subscriber results merged with the active queue after any upstart action ? | 11:39 |
| Keybuk | not sure I understand the question>? | 11:39 |
| H__2 | ok, i'll make up an axample : | 11:39 |
| H__2 | let's say that upstart is active and it as to start scripts A, B, C and D (in that order). And it just finished starting B. This script B has enabled another event script called X. The dependency order of X is that it has to start before C. What does upstart do ? | 11:41 |
| Keybuk | upstart doesn't have dependency orders | 11:42 |
| Keybuk | it's not a dependency-based init system | 11:42 |
| Keybuk | it would be better if you phrased your question in terms of a real example | 11:42 |
| H__2 | well, it is actually a real example, but from a proprietary system I wrote | 11:43 |
| Keybuk | ok | 11:43 |
| Keybuk | so you have four jobs, A, B, C and D | 11:43 |
| H__2 | yes | 11:44 |
| Keybuk | B starts on job-started A, C starts on job-started B, D starts on job-started C | 11:44 |
| H__2 | yes | 11:44 |
| Keybuk | what do you mean by "enabled another event script" ? | 11:44 |
| H__2 | Let's say that script B wrote a script X (or copied it into place), and if available then C wants X to have started before C itself starts. | 11:46 |
| Keybuk | so C should be started by the "X started" event | 11:47 |
| Keybuk | not the one for B | 11:47 |
| H__2 | the C - B relationship is not changed, there is a new one inserted halfway | 11:48 |
| H__2 | and indeed, 'C should be started by the "X started" event'. | 11:48 |
| Keybuk | you're confusing relationships and events | 11:50 |
| Keybuk | upstart isn't a dependency-based init system ;) | 11:50 |
| Keybuk | it doesn't have relationships | 11:50 |
| H__2 | possibly, i'm new to upstart terminology | 11:50 |
| Keybuk | it takes a little bit of a backstep to understand how to translate dependency-based information into event-base | 11:51 |
| Keybuk | they're not a 1:1 mapping by any means, and are quite different | 11:51 |
| Keybuk | we're convinced event-based is better | 11:51 |
| Keybuk | but it does mean that if you come from init-ng, gentoo, etc. you can't just run some perl/sed over the init script to get an upstart one -- you have to rethink how the service is started | 11:52 |
| Keybuk | and how multiple jobs interact (rather than depend) | 11:52 |
| H__2 | ok | 11:54 |
| H__2 | (I don't come from init-ng, gentoo, etc, it's my proprietary development. And I'm wondering whether it can be replaced) | 11:55 |
| Keybuk | so the basic theory of upstart is not that services depend or require one another | 11:56 |
| H__2 | so far upstart comes closest :) | 11:56 |
| Keybuk | but that services are started because other things happen | 11:56 |
| Keybuk | this is because in reality most things don't depend on another service, but an abstract concept | 11:56 |
| Keybuk | e.g. "on battery power" | 11:56 |
| H__2 | well | 11:57 |
| H__2 | what we have is fi. a script that creates an tunnel device, to which other services want to bind. I call that a dependency. | 11:57 |
| Keybuk | right | 11:57 |
| Keybuk | so the obvious change there is | 11:58 |
| Keybuk | other services do not depend on a script that creates a tunnel device | 11:58 |
| H__2 | and if this tunnel device disappears, then the others are in trouble, they must be stopped upfront | 11:58 |
| Keybuk | instead, other services need the tunnel device! | 11:58 |
| Keybuk | so in upstart, you'd do "on network-device-added tun0" | 11:58 |
| Keybuk | and make sure udev sent that event to it | 11:58 |
| Keybuk | that way the services come up with the tunnel | 11:58 |
| Keybuk | likewise, you'd stop them because the tunnel device went away | 11:59 |
| Keybuk | which means even if the user ifconfig'd it down, the services would stop | 11:59 |
| H__2 | went away is too late ;-) will go away is what we need | 11:59 |
| Keybuk | there's no way to know it "will go away" | 11:59 |
| Keybuk | ifconfig tun0 down | 11:59 |
| Keybuk | *boom* | 11:59 |
| Keybuk | you can have a "bring tunnel down safely" script | 11:59 |
| Keybuk | that can issue a "going to take tunnel down" event which stops the services | 12:00 |
| Keybuk | but they should also be stopped if the tunnel goes away unexpectedly | 12:00 |
| === hunger [n=tobias@pd95b0676.dip0.t-ipconnect.de] has joined #upstart | ||
| H__2 | yes the 'die unexpectedly' is a different problem | 12:00 |
| Keybuk | we think it's the same one | 12:00 |
| H__2 | interesting :) | 12:01 |
| Keybuk | so how I'd do that would be have | 12:01 |
| Keybuk | /sbin/remove-tunnel which is a script that does | 12:01 |
| Keybuk | initctl emit network-device-going-down tun0 | 12:01 |
| Keybuk | ifconfig tun0 down | 12:01 |
| Keybuk | -- | 12:01 |
| Keybuk | and then have the services include both | 12:01 |
| Keybuk | stop on network-device-going-down tun0 | 12:01 |
| Keybuk | stop on network-device-down tun0 | 12:01 |
| Keybuk | -- | 12:01 |
| Keybuk | that way your services can safely come down if the script is used | 12:02 |
| Keybuk | but also come down if the script isn't used | 12:02 |
| Keybuk | one should try one's best to have the services at least deal with that sanely, where sane can include logging an error in syslog | 12:02 |
| hunger | Keybuk: Did you upstartify ifup/ifdown? | 12:02 |
| Keybuk | hunger: not yet, https://launchpad.net/distros/ubuntu/+spec/replacement-network-events | 12:02 |
| H__2 | the " have the services at least deal with that sanely" is indeed what we want, sadly that piece of software is out of our control :-/ | 12:03 |
| === hunger is looking forward to seeing upstart develop in feisty. | ||
| === badock [n=badock@h235.net48.bmstu.ru] has joined #upstart | ||
| hunger | Is there a timeline for upstart in feisty yet? | 12:06 |
| H__2 | why don't you call the " stop on network-device-going-down tun0" a dependency ? to me that is a fine example of a dependency | 12:06 |
| Keybuk | hunger: what kind of timeline? | 12:06 |
| Keybuk | H__2: because dependency infers in people's mind certain semantics; which don't exist in this case. "network-device-going-down" is an event, it's something that happens | 12:07 |
| hunger | Keybuk: Like what is planned for when. On second thought I guess that will be in the specs once they become available. | 12:07 |
| Keybuk | hunger: the specs are already registered, just not yet written | 12:07 |
| hunger | Keybuk: I noticed:-) | 12:07 |
| hunger | I think I'll need to spend some time hacking my cryptdisk setup into your scripts when those hit the repositories. | 12:08 |
| H__2 | heh :) and if others want to be notified of such events you still don't call that a dependency ? A subscription then perhaps ? | 12:08 |
| Keybuk | H__2: the particular case is "start on foo" | 12:08 |
| Keybuk | if bar depends on foo, people assume that even if bar is created after foo has been started, bar will be started | 12:09 |
| Keybuk | whereas when "foo" is an event, people realise that it's forgotten about once it happens | 12:09 |
| H__2 | I don't get this "if bar depends on foo, people assume that even if bar is created after foo has been started, bar will be started" If bar depends on foo, then bar cannot be started if foo's not there. But if foo is there then bar can start. | 12:11 |
| Keybuk | yes | 12:12 |
| Keybuk | exactly | 12:12 |
| Keybuk | that's what dependency infers | 12:12 |
| Keybuk | which is why we don't use that term for upstart | 12:12 |
| Keybuk | bar can be started manually at any time | 12:12 |
| Keybuk | it's up to bar to decide whether it should fail to start because foo is not running | 12:13 |
| H__2 | in my world it can not | 12:13 |
| H__2 | but I think I see what you mean | 12:13 |
| Keybuk | unfortunately, without you elaborating on what your world is, I can't understand | 12:13 |
| Keybuk | if a service depends on a tunnel device, and that tunnel device is not present when it is started, /it should fail anyway!/ | 12:14 |
| Keybuk | and it should present a useful error message to debug that failure | 12:14 |
| H__2 | it should not even try to start, controlled by the service trying to start it | 12:14 |
| Keybuk | why not? | 12:14 |
| Keybuk | the sysadmin should always be able to get their hands dirty and try things | 12:15 |
| H__2 | because we know it will fail | 12:15 |
| Keybuk | you don't know it will fail | 12:15 |
| Keybuk | the sysadmin may have created the tunnel by hand | 12:15 |
| H__2 | true, interesting. Let's say "there is no sysadmin". these are embedded systems. | 12:15 |
| Keybuk | then you don't need to worry about this scenario, because it's inherently not possible ;) | 12:16 |
| Keybuk | if you have no tinkering sysadmin, then you can ignore it | 12:16 |
| H__2 | I think you lost the plot :) | 12:16 |
| Keybuk | ? | 12:16 |
| Keybuk | I haven't been told the plot | 12:16 |
| H__2 | I'll try to describe it better | 12:17 |
| H__2 | that turns out to be quite hard. I'm not sure what to add to it what would help us. | 12:23 |
| Keybuk | you're saying that "bar should not be able to start if foo isn't running" | 12:24 |
| Keybuk | but I'm saying that if the only thing that can start bar is the init daemon, then you don't need to worry about that eventuality | 12:24 |
| Keybuk | nothing will try to start bar except the init daemon, as a result of the events that are listed as causing it to start | 12:25 |
| H__2 | maybe this : if A has a "start on" subscription to B, and upstart just tried to start B, but B failed, does upstart then continue starting A ? | 12:25 |
| Keybuk | depends on the event subscribed to | 12:25 |
| Keybuk | if the event is the started one, then no | 12:25 |
| Keybuk | if it's the starting one, then yes | 12:25 |
| H__2 | ok, clear :) | 12:26 |
| Keybuk | sorry that it seems a little confusing, it's much easier to demonstrate with examples | 12:28 |
| H__2 | Can you elaborate a bit more on the "A has a dependency on B" versus "A is subscribed to an event of B" difference you make ? | 12:29 |
| Keybuk | upstart issues events as B changes state | 12:32 |
| Keybuk | e.g. job-starting, job-started, job-failed, job-stopping, job-stopped, etc. | 12:32 |
| Keybuk | if A is subscribed to any of those events, then it will be started or stopped if an event occurs | 12:33 |
| Keybuk | events are one-shot things, they are emitted, get handled by changing the state of any subscribed job, and then get forgotten about | 12:34 |
| Keybuk | they can be emitted by any part of the system | 12:34 |
| Keybuk | as well as job-started, you can also have network-device-added, block-device-added, path-mounted, battery-power, etc. | 12:34 |
| H__2 | Ok, that part is clear. The question is why it is not considered to be a dependency. The end result in bout our systems is the same btw :) | 12:35 |
| H__2 | bout->both | 12:35 |
| Keybuk | the word dependency conjours up certain things in people's minds | 12:35 |
| Keybuk | if I say that "foo depends on bar", then I would assume certain things: | 12:35 |
| Keybuk | - bar is started if I try and start foo | 12:35 |
| Keybuk | - if bar fails to start, foo does not start | 12:36 |
| Keybuk | - if bar is already running when I try and start foo, then foo is started | 12:36 |
| Keybuk | - if foo stops, and nothing else depends on bar, bar is stopped | 12:36 |
| Keybuk | - bar cannot be started if foo doesn't exist (or is disabled) | 12:36 |
| H__2 | don't agree with " - if foo stops, and nothing else depends on bar, bar is stopped", and the one after it too, the rest: yes | 12:37 |
| Keybuk | while all of these things can be replicated in upstart with a combination of events, simply adding "start on job-started bar" does *not* | 12:37 |
| Keybuk | H__2: dependency-based init systems do that | 12:37 |
| H__2 | only if they are bi-directional dependencies IMO | 12:38 |
| H__2 | bar doesn't care if there's a foo that wants to use it, so if foo is stopped, bar doesn't care | 12:38 |
| Keybuk | but that's not what a dependency-based init system does | 12:40 |
| Keybuk | so calling events dependencies, in an init system, would confuse people | 12:40 |
| H__2 | ah, that's then where our confusion comes from. It is what a dependency-based init system does in our opinion (see Gentoo for example). | 12:41 |
| H__2 | dependencies have only one direction. | 12:41 |
| H__2 | a system with bi-directional dependencies cannot start :) | 12:41 |
| Keybuk | I'm completely unfamilar with Gentoo's, I'm afraid | 12:42 |
| Keybuk | the way that initNG and SMF work is to start a set of goal services, which cause their dependencies to start, et. al. down the list | 12:42 |
| Keybuk | if you stop a goal service, than any dependencies unused by anything else are also stopped | 12:42 |
| Keybuk | this is consistent with dependencies in the package manager as well | 12:43 |
| H__2 | I'm unfamiliar with initNG and SMF :) | 12:43 |
| H__2 | I would say " up the list" instead of " down the list" in 2 lines up | 12:44 |
| Keybuk | also to me, depends infers state tracking | 12:45 |
| Keybuk | "bar depends on network-device tun0" | 12:45 |
| Keybuk | which implies that the state of that network device is tracked | 12:45 |
| Keybuk | upstart relies on something else to track the state, and issue the events when it changes | 12:45 |
| H__2 | ideally yes | 12:45 |
| Keybuk | so instead | 12:45 |
| Keybuk | "start bar on network-device-added tun0" | 12:45 |
| Keybuk | "stop bar on network-device-removed tun0" | 12:45 |
| Keybuk | type thing | 12:45 |
| H__2 | clear | 12:45 |
| H__2 | in our system the tracking is present, but handled outside the 'upstart' alternative. By using blunt checkscripts :) | 12:46 |
| H__2 | can only do polling from scripts there, in most cases. | 12:47 |
| Keybuk | upstart is intended to be useful where you have events from other systems | 12:47 |
| Keybuk | and don't need to poll | 12:47 |
| Keybuk | e.g. udev for hardware | 12:47 |
| H__2 | clear | 12:48 |
| hunger | Keybuk: I like the heartbeat idea that came up on the -devel ML. | 12:48 |
| hunger | Keybuk: That would absolutely rock for the server crowd. | 12:48 |
| === H__2 hides his heartbeat system | ||
| H__2 | ;-) | 12:49 |
| H__2 | just joking, besides they're probably different anyway | 12:49 |
| Keybuk | hunger: without knowing much about heartbeat, I couldn't comment much | 12:49 |
| hunger | Keybuk: heartbeat is pretty simple: basically it is just doing something when the heartbeat is no longer heared. | 12:50 |
| H__2 | from where to where is this heartbeat communicated ? what does it monitor ? | 12:51 |
| hunger | Keybuk: I only ever used something like that on AIX, so I can not comment on how linux works either. | 12:51 |
| hunger | H__2: heartbeat is used for eg. when you want a highly available webserver. You set up two that send each other heartbeat signals. | 12:52 |
| H__2 | ok, so 'total service' is monitored | 12:52 |
| H__2 | then it's the same as what we have | 12:52 |
| hunger | H__2: When the hearbeat of the master is no longer heared by the slave that takes over IPs and stuff and continues. | 12:52 |
| H__2 | clear | 12:52 |
| Keybuk | you could have heartbeat emit a "flatline" event ;) | 12:53 |
| Keybuk | and then write upstart jobs with "on flatline" | 12:53 |
| hunger | Keybuk: Yes, exactly. | 12:53 |
| H__2 | ack | 12:53 |
| Keybuk | it's a definite goal to get rid of everything's *.d script directories | 12:54 |
| H__2 | btw, FreeBSD now has a similar dependency system in their init scripts (as what I talked about earlier) | 12:54 |
| H__2 | with complaints like : % rcorder: requirement `named' in file `/usr/local/etc/rc.d/samba.sh' has no pro | 12:55 |
| H__2 | viders. | 12:55 |
| H__2 | nice to see the world moving in the same direction :) | 12:56 |
| Keybuk | right, but bear in mind that upstart doesn't do that ;P it's not a dependency-based init system | 12:56 |
| Keybuk | in an upstart system, samba instead would be started by an event such as "dns-available" | 12:57 |
| H__2 | and a lot more I hope | 12:57 |
| Keybuk | and that event could be emitted by either the bind9 job, a dhclient job or a network interface job if it detects an available IP in /etc/resolv.conf | 12:57 |
| hunger | Keybuk: That is the one weakness I see in upstart: It will be a PITA to figure out on which events to react, there being so many of them. | 12:58 |
| H__2 | hey, if I understand right the need for 2 providors is also not present in upstart, like samba starts on 'dns-available' but samba also needs 'eth0 available' which may not be there yet, so samba would get started another time lateron when 'eth0' appears, right ? | 12:59 |
| hunger | Keybuk: And that some things will end up depending on more than one event will make things even worse. | 12:59 |
| Keybuk | H__2: not currently, methods of doing that are being discussed and will be in 1.0 | 12:59 |
| H__2 | and will still not be called dependencies, right ? ;-) (sorry , couldn't resist) | 01:00 |
| hunger | H__2: ... and all-exported-filesystems-available is another candidate ... | 01:00 |
| H__2 | I'll get some coffee now | 01:00 |
| Keybuk | it depends on the semantics | 01:02 |
| Keybuk | we've talked about the idea of having jobs "wait" for an event | 01:02 |
| Keybuk | so one might do: | 01:02 |
| Keybuk | start on foo | 01:02 |
| Keybuk | wait for network-device-added eth0 | 01:03 |
| Keybuk | wait for dns-available | 01:03 |
| Keybuk | -- | 01:03 |
| Keybuk | does this mean that dns-available has to occur *after* foo | 01:03 |
| Keybuk | or does this mean that dns-available just has to occur at any point on the system | 01:03 |
| hunger | Keybuk: Will that work if dns-available happens before foo? | 01:03 |
| Keybuk | hunger: exactly | 01:03 |
| hunger | Keybuk: I have thought about how to integrate my cryptsetup script with upstart. | 01:04 |
| Keybuk | and how does that work if the network device comes back down again? | 01:04 |
| hunger | Keybuk: In addition to what the normal one shipped with ubuntu can do mine can mount a FS, read keys from there, mount other FSes and then unmount the key-FS again. | 01:04 |
| Keybuk | the network-device-added event happened, so that "wait" has been fulfilled | 01:04 |
| hunger | So basically I would need to make sure that the key-FS is setup and mounted before any FS it contains a key for and then unmount it again once all of them are up. No idea how I can express that in events. | 01:05 |
| Keybuk | why unmount the key FS? | 01:06 |
| hunger | Keybuk: So that nobody can get the keys once the system is up. | 01:06 |
| Keybuk | they could just mount it? :p | 01:07 |
| hunger | Keybuk: I unmount the FS and destruct its decrypted device. That way only the encrypted device is visible once the other crypted FSes are up. | 01:07 |
| H__2 | I'll ask for open-source clearance once more, i'm very interested in what you have to say about it | 01:07 |
| hunger | all that happens before the network comes up, so I am pretty sure nobody can steal my keys;-) | 01:08 |
| H__2 | only the tempest crew in the other building :-P | 01:11 |
| hunger | H__2: upstart breaks the displaying of the password prompt... that might confuse those guys;-) | 01:11 |
| H__2 | Keybuk : is there an advanced examples tar ball ? | 01:12 |
| H__2 | hunger: heh :o) | 01:12 |
| Keybuk | H__2: no | 01:12 |
| Keybuk | hunger: I don't understand why | 01:13 |
| H__2 | ok, then maybe in Ubuntu 6.10 ? | 01:14 |
| hunger | edgy is screwed up wrt. displaying startup info anyway... running usplash gives the password prompt and displays the password which is even worse IMHO. | 01:14 |
| Keybuk | 6.10 was released yesterday | 01:14 |
| Keybuk | hunger: "screwed up" ? | 01:14 |
| H__2 | i know it was released yesterday, I meant to ask whether it did contain more advanced stuff than the examples tar ball | 01:15 |
| Keybuk | no, the examples tar ball is the copy of the jobs from ubuntu 6.10 | 01:15 |
| H__2 | aah, ok :) | 01:15 |
| hunger | Keybuk: Without usplash: no password prompt, with usplash: password prompt is displayed but password is echoed to the screen. | 01:16 |
| hunger | Both is not really the way I expected it to be;-) | 01:17 |
| H__2 | Thanks for the chat. (I'm off for a lunch-walk now.) | 01:17 |
| === johnnybuoy [n=jano@ob-7515.adsl.datanet.hu] has joined #upstart | ||
| === WorkRoey [n=Roey@h-69-3-4-130.mclnva23.covad.net] has left #upstart ["Leaving"] | ||
| === juergbi [n=juerg@80-219-26-249.dclient.hispeed.ch] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Artanicus [i=kuitunej@lehtori.cc.tut.fi] has joined #upstart | ||
| === phsdv [n=kvirc@83.152.239.70] has joined #upstart | ||
| === shwag [n=shwag@66.101.109.10] has joined #upstart | ||
| === phsdv [n=kvirc@83.152.239.70] has joined #upstart | ||
| phsdv | hi all, I just managed to get my gentoo system booted using upstart. | 10:31 |
| phsdv | but I am getting some errors like: control-alt-delete: init: /dev/initctl: No such file or directory | 10:33 |
| phsdv | does someone know how to fix that? | 10:34 |
| === Akrito [n=alex@24.124.24.34] has joined #upstart | ||
| === phsdv [n=kvirc@83.152.239.70] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!