| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === khermans__ [i=administ@nat/cisco/x-ff87b469336f7e6a] has joined #upstart | ||
| === mbiebl [n=michael@e180088015.adsl.alicedsl.de] has joined #upstart | ||
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| === khermans__ [i=administ@nat/cisco/x-879df417dccb614d] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === int0x0c [n=ben@161.253.46.197] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === cwillu [n=cwillu@S01060011d8399444.ss.shawcable.net] has joined #upstart | ||
| cwillu | how can I get a program in an event to start on a particular tty? | 09:29 |
|---|---|---|
| === mdales [n=michael@dsl-217-155-205-58.zen.co.uk] has joined #upstart | ||
| cwillu | nvm, guess it was a getty question | 09:34 |
| === Amaranth_ [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Md_ [i=md@freenode/staff/md] has joined #upstart | ||
| === Md_ is now known as Md | ||
| === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart | ||
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === cwillu [n=cwillu@S01060011d8399444.ss.shawcable.net] has left #upstart [] | ||
| === mdales [n=mdales@cpc3-cmbg6-0-0-cust25.cmbg.cable.ntl.com] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === reppel_ [n=reppel@213-140-11-128.fastres.net] has joined #upstart | ||
| reppel_ | is it possible to pass a env variable from the pre-start stanza to the exec stanza? | 11:36 |
| reppel_ | sorry | 11:36 |
| reppel_ | the respawn stanza | 11:36 |
| Keybuk | I'm not sure I understand? | 11:37 |
| reppel_ | well | 11:39 |
| reppel_ | i need to respawn a daemon | 11:40 |
| reppel_ | this daemon takes an optional argument | 11:40 |
| reppel_ | -D | 11:40 |
| reppel_ | and i know if i have to call it with the option reading a file on the filesystem | 11:40 |
| reppel_ | so i thinked about reading this file in the pre-start stanza | 11:40 |
| reppel_ | but it seems i can't pass env variables from pre-start to respawn | 11:41 |
| Keybuk | right | 11:41 |
| Keybuk | you can set the same variable for both though | 11:41 |
| reppel_ | Keybuk: how? | 11:43 |
| reppel_ | lag lag | 11:43 |
| Keybuk | env FOO=BAR | 11:44 |
| Keybuk | in the job | 11:44 |
| reppel_ | Keybuk: yep but the problem is that i need to set FOO to BAR if /etc/sysconfig/video exists (or veryfing a generic condition), otherwise i need to set FOO to another value | 11:51 |
| reppel_ | you can map this problem to /etc/default/ files | 11:51 |
| reppel_ | if you source for example /etc/default/daemon and you found interfaces="eth0,eth1" | 11:52 |
| reppel_ | you need to pass these options to the daemon | 11:52 |
| Keybuk | I understand the problem, there isn't a solution to it yet | 11:54 |
| reppel_ | ok thanks | 11:57 |
| reppel_ | is it planned for the future? | 11:57 |
| Keybuk | dunno | 11:58 |
| Keybuk | I've never seen the point of /etc/default files | 11:58 |
| reppel_ | neither I | 11:58 |
| reppel_ | just wanted to help you understand :) | 11:58 |
| Keybuk | if I were to worry about those, I'd just implement an env FILENAME option or something | 12:01 |
| reppel_ | Keybuk: what do you suggest in my case? | 12:02 |
| reppel_ | respawning a script? | 12:03 |
| Keybuk | sure | 12:03 |
| Keybuk | script ... | 12:03 |
| Keybuk | end script | 12:03 |
| Keybuk | respawn | 12:03 |
| reppel_ | you can respawn a script/end script stanza? | 12:04 |
| Keybuk | yes | 12:06 |
| reppel_ | nice :) | 12:06 |
| reppel_ | much cleaner | 12:06 |
| reppel_ | thanks Keybuk | 12:06 |
| reppel_ | oh, just another question | 12:10 |
| reppel_ | i have a job used as state | 12:10 |
| reppel_ | its definition is the following: | 12:10 |
| reppel_ | on stopped some_event | 12:10 |
| reppel_ | if i try to stop it i get from initctl the following message: | 12:11 |
| reppel_ | # initctl stop system-up | 12:11 |
| reppel_ | system-up (stop) running | 12:11 |
| Keybuk | which upstart version? | 12:12 |
| reppel_ | 0.3.5 | 12:12 |
| Keybuk | yeah, known bug | 12:12 |
| Keybuk | fixed in bzr trunk | 12:12 |
| reppel_ | in the main trunk? | 12:12 |
| Keybuk | yes | 12:12 |
| reppel_ | ok, thanks a lot | 12:12 |
| mdales | initctl emit foo - should that gerenate event foo? | 12:13 |
| === phsdv [n=paul@91.168.175.163] has joined #upstart | ||
| mdales | or did I misunderstand the docs? | 12:13 |
| reppel_ | mdales: yes it does | 12:14 |
| mdales | okay, but not on 0.2.7? | 12:14 |
| Keybuk | initctl trigger on 0.2.7 | 12:14 |
| mdales | (i.e., what's on edgy) | 12:14 |
| mdales | ah | 12:14 |
| mdales | thanks | 12:14 |
| reppel_ | mdales: don't know about 0.2.7, i'm using 0.3.5 | 12:14 |
| Keybuk | (we changed the terminology) | 12:14 |
| mdales | right | 12:14 |
| mdales | many thanks | 12:14 |
| reppel_ | Keybuk: are you still working on specs of complex-event or you have reached a final state? | 12:22 |
| Keybuk | still working on it | 12:23 |
| Keybuk | we're really not happy with it | 12:23 |
| mdales | the respawn scrip thing mentioned above - is the syntax for that just "respawn script ... end script"? | 12:23 |
| mdales | +t | 12:23 |
| Keybuk | no | 12:24 |
| Keybuk | "respawn" appears on a line on its own | 12:24 |
| mdales | okay | 12:24 |
| Keybuk | respawn CMD is just a (removed in bzr trunk) shortcut for "respawn\nexec CMD" | 12:24 |
| mdales | is that the right thing to do for a respawning process that emits an event as it starts - the script will do an initctl trigger and then run the command, and I specify that script as respawn? | 12:25 |
| mdales | okay | 12:25 |
| Keybuk | the only difference would be that instead of running exec() on the command directly, it would exec() a shell and pipe in the script instead | 12:27 |
| mdales | cool | 12:28 |
| mdales | okay, many thanks for that. I now have proper dependancy on scripts | 12:42 |
| mdales | much appreciated | 12:42 |
| === nakee [n=nakee@grok.cs.huji.ac.il] has joined #upstart | ||
| nakee | hey | 12:44 |
| Keybuk | hi | 12:46 |
| _ion | Hi | 12:46 |
| nakee | upstart also replaces cron and so on? | 12:46 |
| _ion | Not yet. | 12:46 |
| nakee | but it suppose to be something like the daemon they have now on macosx? | 12:47 |
| Keybuk | we're heading in that direction, yes | 12:47 |
| Keybuk | but a little earlier in the development cycle than they are | 12:47 |
| Keybuk | (which reminds me, the launchd never did e-mail me) | 12:47 |
| === pschulz01 [n=paul@202.174.42.5] has joined #upstart | ||
| pschulz01 | Hello.. How do I enable a serial console in edgy? | 12:48 |
| pschulz01 | (Fresh install) | 12:48 |
| Keybuk | pschulz01: try #ubuntu | 12:49 |
| pschulz01 | Keybuk: Sorry.. dev forum? | 12:49 |
| Keybuk | Ubuntu users/support channel | 12:50 |
| _ion | pschulz: Look at /etc/event.d/tty1, create /etc/event.d/ttyS0 just like it but modify the parameters on the "respawn" line appropriately. | 12:50 |
| _ion | (I think) | 12:50 |
| pschulz01 | _ion: Ta.. exactly what I was after. | 12:50 |
| pschulz01 | (/etc/inittab was missing :-?) | 12:51 |
| _ion | /etc/event.d is the Upstart equivalent of inittab. | 12:51 |
| pschulz01 | _ion: Restart required? | 12:52 |
| Keybuk | no | 12:52 |
| _ion | sudo initctl start jobname (where jobname is the filename, e.g. ttyS0) | 12:52 |
| === __keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| pschulz01 | _ion: Wahoo!!! ta. one wyse terminal connected and talking :-) | 12:54 |
| === _ion wonders whether any hardware terminal supports UTF-8 | ||
| mdales | hmmm. I had a respawned script that did "initctrl trigger myserverstart \ /usr/bin/myserver" and all was well | 01:01 |
| Keybuk | you'd get "started myserver" anyway | 01:02 |
| mdales | when I added a initctrl trigger myserverstop after the myserver line the script no longer seems to stop myserver | 01:02 |
| mdales | yes | 01:02 |
| mdales | that was fine | 01:02 |
| Keybuk | right, it would kill the shell script not the daemon running inside it | 01:02 |
| Keybuk | you need to use trap to kill the daemon | 01:02 |
| mdales | but it did that in the first case | 01:02 |
| mdales | both cases are scripts | 01:02 |
| Keybuk | ? | 01:06 |
| Keybuk | can you pastebin the job? | 01:07 |
| mdales | sure | 01:08 |
| mdales | http://pastebin.ca/377040 | 01:10 |
| mdales | if you remove the second call to initctl it works | 01:11 |
| mdales | anoying Xvnc doesn't dump it's pid anywhere | 01:11 |
| Keybuk | what does it do if you remove the second initctl call? | 01:14 |
| Keybuk | and what does it do if you don't/ | 01:14 |
| mdales | when I so a stop Xvnc will terminate | 01:14 |
| mdales | without it it continues to run | 01:14 |
| Keybuk | so without the second initctl line, Xvnc gets killed? | 01:15 |
| pschulz01 | How do I send upstart output to a serial console? | 01:15 |
| Keybuk | with the second initctl line, Xvnc doesn't? | 01:15 |
| mdales | yes | 01:15 |
| Keybuk | pschulz01: console=/dev/ttyS0 on the kernel command-line | 01:15 |
| Keybuk | mdales: shell behaviour, I would guess | 01:15 |
| mdales | fair enough | 01:15 |
| mdales | I'll add a trap handler for TERM | 01:15 |
| mdales | I assume that otherwise that's a good way to stignal the start/stop of a service? | 01:16 |
| mdales | it's mostly so when I do a stop comamnd it stops the thing that was started by vcnserver11 event | 01:16 |
| mdales | +the | 01:16 |
| mdales | I guess I could do that in the stop stanza | 01:17 |
| mdales | anyway, once again, many thanks for your advice | 01:17 |
| pschulz01 | Keybuk: I did that... I'll have a look at it again though.. as I thought that I would be seeing more messages than what I currently am. | 01:18 |
| Keybuk | pschulz01: in normal operation, you won't see any messages | 01:19 |
| pschulz01 | Keybuk: Ta, | 01:20 |
| Keybuk | mdales: I don't see why you need the initctls there, though | 01:20 |
| mdales | in you can't see why I need the events? | 01:21 |
| mdales | of why I've put them there in particular? | 01:21 |
| mdales | s/of/or/ | 01:22 |
| mdales | I have another script that launches another program in response to Xvnc starting/stopping | 01:23 |
| mdales | we have some hardware thin clients that are essentially ethernet attached framebuffers. there's a program called nivo2vnc that I use to connect the Xvnc session to the thinclient | 01:24 |
| Keybuk | mdales: right, but you get events when jobs start and stop for free | 01:24 |
| mdales | ah, okay | 01:24 |
| mdales | I missed that in the docs | 01:24 |
| mdales | I'll go and reread | 01:24 |
| Keybuk | assuming that job file is called vncserver | 01:25 |
| Keybuk | you get a vncserver/started and vncserver/stop event | 01:25 |
| mdales | okay | 01:26 |
| mdales | thanks | 01:26 |
| mdales | I need to go to a meeting now, but I'll try that when I get back | 01:26 |
| === Trevelyan` [n=Jim@unaffiliated/trevelyan] has joined #upstart | ||
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| === Trevelyan [n=Jim@unaffiliated/trevelyan] has joined #upstart | ||
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| reppel_ | Keybuk: "start on started someevent" and "start on someevent/started" have the same meaming? | 02:41 |
| Keybuk | reppel_: no | 02:45 |
| Keybuk | they're different events, from different versions of upstart | 02:45 |
| reppel_ | i'm using 0.3.5 with "start on started event" | 02:45 |
| reppel_ | is it different in trunk or previous versions? | 02:45 |
| Keybuk | you mean "start on started job" | 02:46 |
| reppel_ | sorry | 02:46 |
| reppel_ | yep | 02:46 |
| Keybuk | and that's correct for 0.3.5, started is emitted when the job is running | 02:46 |
| Keybuk | job/started is what 0.2.7 emits, at a similar, but not identical point | 02:46 |
| reppel_ | Keybuk: is it possible to run a daemon under a given uid with upstart? | 02:46 |
| reppel_ | currently i'm using su | 02:47 |
| Keybuk | use su | 02:47 |
| reppel_ | is it a planned feature? | 02:47 |
| Keybuk | we're planning for user jobs | 02:47 |
| Keybuk | where a job can be registered in the name of a user, and only that user (or root) can start/stop it, etc. | 02:47 |
| Keybuk | and the processes associated with that job are run as that user, in a full PAM session | 02:48 |
| reppel_ | ah ok | 02:48 |
| reppel_ | Keybuk: do you think feisty+1 will be purely upstart based? | 02:48 |
| Keybuk | reppel_: I don't know, maybe | 02:48 |
| Keybuk | feisty isn't upstart-based yet | 02:48 |
| Keybuk | getting promoted didn't leave me enough time to do that | 02:49 |
| mdales | are there circumstances under which respawn will stop trying to work? | 03:17 |
| Keybuk | yes | 03:22 |
| Keybuk | if the limit is reached | 03:22 |
| mdales | cool | 03:25 |
| mdales | ta | 03:25 |
| Keybuk | respawn limit TRIES INTERVAL | 03:25 |
| Keybuk | e.g. | 03:25 |
| Keybuk | respawn limit 100 10 | 03:25 |
| Keybuk | may only be restarted 100 times every 10s | 03:25 |
| Keybuk | if it steps over that, it's stopped | 03:25 |
| mdales | okay | 03:25 |
| mdales | hmmm | 03:27 |
| mdales | that's presumably over the lifetime of a system? | 03:27 |
| Keybuk | yes | 03:27 |
| mdales | okay | 03:27 |
| mdales | can I set it to infinite? | 03:27 |
| Keybuk | respawn limit 0 0 | 03:27 |
| mdales | okay | 03:28 |
| mdales | thanks | 03:28 |
| Keybuk | the TRIES counter is reset if INTERVAL is passed | 03:29 |
| Keybuk | so if the 100th respawn happens more than 10s after the first one, it's not counted as a runaway job | 03:29 |
| mdales | ah | 03:29 |
| mdales | okay | 03:29 |
| mdales | that's more what I want I suspect | 03:29 |
| mdales | hmmm. still not working. I need to add some logging to find out why my child scripts aren't being launched at boot | 03:31 |
| Keybuk | boot with --debug | 03:31 |
| mdales | --debug on the kernel option? | 03:32 |
| Keybuk | yeah | 03:32 |
| mdales | will that dump to the screen or to a log file? | 03:32 |
| Keybuk | screen | 03:35 |
| Keybuk | you don't have a writable filesystem ;) | 03:35 |
| mdales | ah | 03:35 |
| mdales | hmm. okay, I suspect one thing I need to do is make my Xvnc script dependant on xfs having been started | 03:49 |
| mdales | Xvnc struggles to start, and I'd wager xfs not being ready would be a good reason for that to happen | 03:49 |
| === j_ack [n=rudi@p508DB9B4.dip0.t-ipconnect.de] has joined #upstart | ||
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| _ion | Sigh, bloody ISP. | 04:06 |
| Keybuk | :) | 04:08 |
| Keybuk | is there any other kind? | 04:09 |
| _ion | :-) | 04:09 |
| mdales | is there an easy way to tie an upstart script to a rc.d event? I've been looking through the code to see if I can spot it but failed thus far to spot anything | 04:09 |
| _ion | At least this one doesn't charge 25 /month for a static IP address and say "you can't have a server" (even though the Finnish law doesn't allow an ISP to say so). | 04:09 |
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| Keybuk | mdales: define "rc.d event" | 04:28 |
| mdales | where do I define that? I've not seen any examples of defines. Basically I want to tie my script to the starting of xfs whcih on edgy is started in rc2.d | 04:35 |
| mdales | apologies if I'm missing some obvious docs on this stuff | 04:35 |
| Keybuk | no, I mean can you define "rc.d event" for me, since I don't understand what you mean | 04:37 |
| Keybuk | the most you could do would be to start your script on rc2.d/stop | 04:38 |
| mdales | okay | 04:38 |
| Keybuk | or modify /etc/init.d/rc to emit upstart events | 04:39 |
| mdales | yeah | 04:39 |
| mdales | I was pondering that option | 04:39 |
| mdales | but I think your idea of having it start on rc2.d/stop would work too | 04:39 |
| mdales | and mean less messing with other scripts | 04:39 |
| === j_ack [n=rudi@p508DB9B4.dip0.t-ipconnect.de] has joined #upstart | ||
| === int0x0c [n=ben@161.253.46.197] has joined #upstart | ||
| === AStorm [n=astralst@puszkin.org] has joined #upstart | ||
| AStorm | Hello guys. | 06:10 |
| AStorm | Any new releases? (need a new one for my liveUSB :> ) | 06:10 |
| Keybuk | what do you need a new one for? :p | 06:11 |
| Keybuk | what's wrong with the old one? | 06:11 |
| AStorm | Complex events? | 06:11 |
| AStorm | Maybe I'll just use the latest bzr. | 06:12 |
| AlexExtreme | complex-event-config is being rather complex to design ;) | 06:12 |
| Keybuk | complex events aren't even in bzr trunk | 06:12 |
| Keybuk | so they wouldn't appear in the next release anyway | 06:12 |
| AStorm | Keybuk: uh... | 06:12 |
| Keybuk | still "drafting"/"experimental" | 06:12 |
| AStorm | Uh... ^2 | 06:12 |
| AStorm | But I can manage with current upstart too. | 06:12 |
| AStorm | But then, any init system would work fine for that. | 06:13 |
| Keybuk | need to finish the design of complex-events before the implementation can be released | 06:14 |
| AStorm | Good. Hate to use unfinished and broken tools. | 06:15 |
| === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart | ||
| === mbiebl [n=michael@e180086079.adsl.alicedsl.de] has joined #upstart | ||
| Keybuk | I hate it when test cases break when I change things | 06:36 |
| mbiebl | Keybuk: with feature freeze nearing for feisty, do you still hold on your ambitious plans of upstartifying the core system services? | 06:37 |
| Keybuk | no | 06:37 |
| Keybuk | they'll be optional packages instead | 06:37 |
| AlexExtreme | IIRC feature freeze already started | 06:37 |
| Keybuk | general advice; if you want time to do things, *don't* say yes to becoming a manager | 06:39 |
| Keybuk | geg | 06:39 |
| Keybuk | he | 06:39 |
| mbiebl | turns out ComplexEventConfig was more complex than anticipated ;-) | 06:39 |
| AlexExtreme | heh | 06:39 |
| Keybuk | mbiebl: nah, I anticipated it would be complex | 06:40 |
| Keybuk | I just want it to be elegant, really | 06:40 |
| mbiebl | Well, I just noticed your hesitations (better think twice than rush it) | 06:41 |
| mbiebl | But getting it right (which includes elegance imo) is surely more important than getting it out quickly | 06:42 |
| Keybuk | exactly | 06:43 |
| mbiebl | Keybuk: the vim syntax highlighting file, I wrote: where is the best place to put that? | 06:45 |
| Keybuk | mail it to the list | 06:46 |
| mbiebl | ok. but what about updates (new keywords etc.) | 06:46 |
| Keybuk | if you mail it to the list, I'll stick it in bzr :) | 06:47 |
| Keybuk | alternatively, make your own bzr branch and add it there, and I can pull | 06:47 |
| Keybuk | contrib/ directory or something would do | 06:48 |
| mbiebl | never worked with bzr, so I'll go with the first option ;-) | 06:48 |
| mbiebl | but maybe a good occasion to learn about bzr... | 06:50 |
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| === khermans__ [i=administ@nat/cisco/x-a0e2e3363eb9cf3c] has joined #upstart | ||
| Keybuk | yay | 07:05 |
| Keybuk | job->pre_start/post_start/etc. are all gone! | 07:05 |
| Keybuk | along with job->pid | 07:06 |
| _ion | \o/ | 07:08 |
| Keybuk | there's now a single job->process array | 07:09 |
| Keybuk | the first five elements of which are builtin to be the default main/pre-start/etc. actions | 07:09 |
| Keybuk | and each member has its own pid | 07:09 |
| _ion | Nice | 07:10 |
| Keybuk | this makes some code more sane, e.g. the child_reaper doesn't guess which process failed by the state anymore | 07:11 |
| Keybuk | it now knows it was the post-start script :) | 07:11 |
| Keybuk | also it makes adding custom actions really easy | 07:11 |
| _ion | If the job has multiple instances, will they be added to the array? | 07:11 |
| Keybuk | instances are still separate entries in the jobs hash table | 07:11 |
| _ion | Ok | 07:11 |
| Keybuk | I haven't disconnected the state from the configured job | 07:12 |
| Keybuk | (yet, maybe) | 07:12 |
| === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart | ||
| === pkt [n=pantelis@athedsl-17765.otenet.gr] has joined #upstart | ||
| === mdales_ [n=mdales@dsl-217-155-205-58.zen.co.uk] has joined #upstart | ||
| === mdales [n=mdales@dsl-217-155-205-58.zen.co.uk] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| wasabi_ | Keybuk: Where'd the term watershed come from? | 08:57 |
| Keybuk | no idea | 09:02 |
| Keybuk | it's a dictionary word | 09:02 |
| === j_ack [n=rudi@p508DB9B4.dip0.t-ipconnect.de] has joined #upstart | ||
| Keybuk | things flow over the top of a watershed | 09:24 |
| wasabi_ | hmm | 09:27 |
| wasabi_ | I can't even find any CS references to it. :0 | 09:27 |
| wasabi_ | Except in evms.rules. =) | 09:27 |
| Keybuk | I doubt there are | 09:28 |
| Keybuk | it's a geography term :p | 09:29 |
| Keybuk | when a river reaches a watershed, the water is collected to be returned at a later time | 09:29 |
| Keybuk | http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott@netsplit.com-20070301180322-inrigno2arsd68dk?start_revid=scott%40netsplit.com-20070301190545-9fdab2fn014jyx9y | 09:34 |
| wasabi_ | udev lesson: What happens when a br0 interface is added. | 09:34 |
| wasabi_ | I see 25-iftab.rules. | 09:34 |
| wasabi_ | Seems like that would invoke it. | 09:34 |
| Md | try it: use udevmonitor and create a new bridge | 09:35 |
| wasabi_ | ooh. neat utility. | 09:35 |
| wasabi_ | Have a friend whose getting weirdness with interfaces being renamed involving bridges. I'm wondering if there's anyplace anywhere that DOESN"T rename br0 to eth* | 09:36 |
| === afancy [n=chatzill@xiliu.sby.abo.fi] has joined #upstart | ||
| afancy | hi | 09:44 |
| afancy | This channel requires that you have registered and identified yourself with the network's nickname registration services (e.g. NickServ). Please see the documentation of this network's nickname registration services that should be found in the MOTD (/motd to display it). | 09:44 |
| afancy | I got the above msg. | 09:44 |
| afancy | how shoud i do | 09:44 |
| wasabi_ | interesting. What makes 25-iftab rules NOT continue processing events for the interface? | 09:48 |
| wasabi_ | The interface it just renamed. | 09:48 |
| wasabi_ | Or, does it, just under the new name? | 09:49 |
| === mdales [n=mdales@dsl-217-155-205-58.zen.co.uk] has joined #upstart | ||
| === afancy [n=chatzill@xiliu.sby.abo.fi] has left #upstart [] | ||
| Keybuk | wasabi: the point is that udev continues processing events under the new name | 10:11 |
| Keybuk | there should be an IRC flag meaning "I need an operators help" | 10:12 |
| Keybuk | and there should be a channel flag that prevents people joining the channel if they have that :p | 10:12 |
| AlexExtreme | :p | 10:12 |
| === Keybuk sets mode #upstart -Md | ||
| Keybuk | :p | 10:13 |
| AlexExtreme | :P | 10:13 |
| AlexExtreme | gotta go, cya | 10:13 |
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| === int0x0c [n=ben@128.164.137.192] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!