| hrw | hi | 10:41 |
|---|---|---|
| Keybuk | hrw: hey, how's it going? | 10:41 |
| hrw | moment, waiting for ogra | 10:41 |
| * ogra_tb waves | 10:41 | |
| hrw | Keybuk: we want to add extra service to upstart | 10:41 |
| hrw | Keybuk: http://marcin.juszkiewicz.com.pl/tmp/ogra/ogra.tar.bz2 | 10:42 |
| ogra_tb | Keybuk, though for upstream inclusion i'm recommending to not use root autologin indeed :) | 10:42 |
| Keybuk | explain? | 10:42 |
| hrw | Keybuk: it allows to start getty on serial console given by kernel cmdline. useful for ARM people mostly but I think that there will be other users too | 10:42 |
| ogra_tb | Keybuk, it [arses console= and if it finds a serial definition it spawns a serial getty | 10:43 |
| ogra_tb | *parses | 10:43 |
| hrw | Keybuk: by default service is disabled and user can define which tool to run (so can be autorootlogin or normal getty/login combo) | 10:43 |
| ogra_tb | so we dont need to manually add a ttyS*.conf file all the time | 10:43 |
| Keybuk | you don't need to parse /proc/cmdline for that | 10:43 |
| Keybuk | I think you can just put in "env console" and read $console | 10:43 |
| ogra_tb | on arm you usually use multiple console args | 10:43 |
| Keybuk | which one wins? | 10:44 |
| ogra_tb | first console is usually serial, second is a tty | 10:44 |
| hrw | "console=tty1 console=ttyS2" like | 10:44 |
| ogra_tb | the second one | 10:44 |
| Keybuk | I think that works with the environment variables too | 10:44 |
| ogra_tb | as soon as the kernel has uncompressed it switches to the second console | 10:44 |
| ogra_tb | so for debugging you usually need serial | 10:45 |
| ogra_tb | for login you then get the second one ... if you also want a login prompt on the first defined console yu need to create an init .conf file | 10:45 |
| ogra_tb | the code above avoids that | 10:45 |
| Keybuk | unsure which one the kernel passes as $console to init | 10:46 |
| ogra_tb | the second one i think | 10:47 |
| hrw | but it also checks is there a service for console and exit if there is | 10:47 |
| ogra_tb | root@touchbook:~# env |grep console | 10:47 |
| ogra_tb | root@touchbook:~# | 10:47 |
| ogra_tb | hmm, where would that variable exist ? | 10:47 |
| Keybuk | in pid 1's environment | 10:48 |
| ogra_tb | ah | 10:48 |
| Keybuk | unless it doesn't, of course | 10:48 |
| ogra_tb | so apart from the parsing of cmdline, would you think such an addition would be possible upstream ? | 10:49 |
| Keybuk | not in its current form, no | 10:49 |
| ogra_tb | (/me disagrees with the way of calling an external binary though, i'd just use an upstart script/end script section here) | 10:49 |
| Keybuk | it should be possible to do it without the script in /bin | 10:49 |
| ogra_tb | heh | 10:50 |
| Keybuk | and definitely without anything in /etc/default - which is a complete violation of Upstart policy ;-) | 10:50 |
| ogra_tb | well, i want the serial detection | 10:50 |
| Keybuk | plus it doesn't take into account when the device is ready | 10:50 |
| ogra_tb | the arm project guys want to additionally have a root autologin for their images | 10:50 |
| ogra_tb | that caused the default file | 10:51 |
| ogra_tb | i think the serial detection is a valid upstream addition while the rootlogin should be a project thing | 10:51 |
| hrw | so I will check value of $console | 10:52 |
| ogra_tb | init will likely only see the second one, but test it | 10:52 |
| ogra_tb | Keybuk, the device has to be ready anyway, the kernel messaages go to the serial consolle | 10:56 |
| ogra_tb | -l | 10:56 |
| hrw | even with one entry I got empty value for "echo $console >>/tmp/test" in /etc/init/auto-serial-console.conf | 10:57 |
| * ogra_tb hates the touchbook kbd with passion | 10:57 | |
| Keybuk | ogra_tb: not necessarily | 10:57 |
| ogra_tb | well, for our kernels at least we can rely on having serial console support built in | 10:57 |
| Keybuk | sure, you can ship that in Ubuntu ;-) | 10:58 |
| hrw | Keybuk: and we can add "[ ! -f /dev/$tty ] && exit" | 10:58 |
| Keybuk | hrw: that would be a race condition | 10:58 |
| hrw | ok | 10:58 |
| ogra_tb | so with devtmpfs we can be sure the device exists from the start | 10:58 |
| Keybuk | no you can't, the console device driver may not have been loaded yet | 10:58 |
| hrw | Keybuk: unless it is in-kernel? | 10:59 |
| ogra_tb | doesnt that get loaded as fisrt thing by the kernel ? | 10:59 |
| Keybuk | hrw: for something upstream, I can't rely on that guarantee | 10:59 |
| Keybuk | the kernel will cause (via kmod) a char-major-x style probe the first console message that needs to be emitted | 11:00 |
| Keybuk | it may be sometime before userspace responds to that | 11:00 |
| ogra_tb | yeah, its far before userspace | 11:00 |
| Keybuk | no it isn't | 11:00 |
| ogra_tb | kernel messages are output right after uncompressing where would there be userspace ? | 11:01 |
| Keybuk | what kernel messages? | 11:01 |
| ogra_tb | all stuff that ends up in the ringbuffer | 11:01 |
| ogra_tb | from line 1 on | 11:01 |
| Keybuk | what stuff? | 11:02 |
| ogra_tb | all kernel output | 11:02 |
| Keybuk | there is no kernel output in Ubuntu by default ;) | 11:02 |
| ogra_tb | /var/log/dmesg if you want it like that :) | 11:02 |
| hrw | Keybuk: by default there are many things in other way | 11:03 |
| ogra_tb | with queit its indeed quietened down, but the device should exist at that point regardless | 11:03 |
| Keybuk | why should it exist? | 11:03 |
| Keybuk | what will make it? :p | 11:03 |
| ogra_tb | because there is output directed to it | 11:03 |
| ogra_tb | the kernel | 11:03 |
| Keybuk | no it won't | 11:03 |
| Keybuk | because the driver won't be available | 11:03 |
| Keybuk | etc. | 11:03 |
| ogra_tb | hmm | 11:04 |
| ogra_tb | so what do you propose | 11:04 |
| ogra_tb | having a package with just one .conf file ? | 11:04 |
| Keybuk | yes | 11:04 |
| ogra_tb | hmm | 11:04 |
| hrw | Keybuk: no chance to integrate it into upstart then? | 11:05 |
| Keybuk | not in its current form, no | 11:05 |
| hrw | so which suggestions for changes? | 11:06 |
| Keybuk | needs to be a single upstart .conf file, with the desired console available to upstart itself so that the "start on" bit can reference it | 11:06 |
| ogra_tb | i doubt you can change it in a way that would please Keybuk | 11:06 |
| ogra_tb | since you cant know if the device exists at the point you need to know it | 11:06 |
| Keybuk | sure you can, there are events for that | 11:07 |
| hrw | Keybuk: single conf file is easy. but on my beagleboard $console var is empty | 11:07 |
| Keybuk | hrw: may require kernel and/or upstart patches to make it work | 11:07 |
| hrw | week ago I used sysvinit | 11:07 |
| hrw | and was happy with it ;D | 11:07 |
| Keybuk | go use that then | 11:08 |
| hrw | Keybuk: then this system will not be *buntu | 11:08 |
| * ogra_tb doesnt want to add sysvinit stuff to ubuntu :) | 11:08 | |
| ogra_tb | andd i really want the automatic detection stuff | 11:08 |
| Keybuk | so stop whining then - if you want to do something properly, do it properly | 11:08 |
| Keybuk | figure out why the kernel doesn't tell userspace which console it's created, etc. | 11:08 |
| Keybuk | and fix that | 11:09 |
| Keybuk | we have a kernel team, they'll help you get the patch upstream too | 11:09 |
| Keybuk | so everyone can benefit | 11:09 |
| ogra_tb | yeah | 11:09 |
| hrw | mkey | 11:09 |
| ogra_tb | just more time consuming | 11:09 |
| Keybuk | yes, it takes time to do things properly | 11:09 |
| Keybuk | that's not an excuse | 11:10 |
| ogra_tb | i didnt mean to use it as one :) | 11:10 |
| hrw | neither did I | 11:10 |
| ogra_tb | though the arm project guys might have some time pressure | 11:10 |
| Keybuk | we're trying to make the best *Operating System* that we can | 11:10 |
| ogra_tb | not sure about their timelines | 11:10 |
| Keybuk | so it's important to think about everything and do it the right way | 11:10 |
| ogra_tb | indeed | 11:11 |
| hrw | btw - /etc/init/tty1.conf autoassumes that /dev/tty1 exists? | 11:13 |
| Keybuk | that job isn't shipped upstream ;) | 11:13 |
| ogra_tb | oh, but its in our upstart package | 11:15 |
| Keybuk | right | 11:15 |
| Keybuk | we have patches to upstart ;) | 11:15 |
| * ogra_tb wasnt aware you add patches :) | 11:15 | |
| Keybuk | but again, I think this is just something you should ship yourselves in your own packages for now | 11:16 |
| ogra_tb | so once we have a reliable way to detect the device you would be willing to ship it too ? | 11:16 |
| Keybuk | yup | 11:16 |
| ogra_tb | ok | 11:16 |
| Keybuk | once the "start on" can reference the detected console device, I'm happy | 11:16 |
| ogra_tb | good | 11:16 |
| ogra_tb | we'll hunt down the kernel team for it then | 11:16 |
| Keybuk | it may be fixed as part of the "pass all options to init" patch | 11:17 |
| ogra_tb | though it will be tricky since we only want certain console devices | 11:17 |
| ogra_tb | that patch reads the cmdline ? | 11:17 |
| ogra_tb | or the kernel events | 11:18 |
| Keybuk | that patch is in the part of the kernel code that generates init's cmdline from its own | 11:18 |
| ogra_tb | ah | 11:18 |
| ogra_tb | yeah, then we should have $console ... the question is just which one we get :) | 11:18 |
| ogra_tb | at the pointinit starts the first console entry will be ignored already | 11:19 |
| ion | keybuk: How’s Upstart 10’s sysvrc loader going to know whether an init script is a task or a service, btw? | 14:26 |
| ion | Just wait until the main process returns with zero and if it has left any children running, it’s a service? | 14:27 |
| ion | I take it respawn won’t be used for that stuff? | 14:28 |
| Keybuk | consider the start and stop bits equivalent to pre-start and post-stop | 14:29 |
| Keybuk | so they always hold up running/stopped | 14:30 |
| ion | So Upstart won’t track any child processes they left behind at all? | 14:30 |
| Keybuk | yeah it will | 14:30 |
| Keybuk | "equivalent to" | 14:31 |
| ion | Ok :-) | 14:31 |
| Keybuk | process tracking is a bit different in 0.10 | 14:31 |
| zer0c00l | How do i use upstart to restart a crashing application? | 17:12 |
| zer0c00l | For example transmission-daemon | 17:12 |
| JanC | respawn | 17:19 |
| zer0c00l | ok | 17:20 |
| zer0c00l | Read the docs | 17:20 |
| zer0c00l | JanC: thanks | 17:20 |
| zer0c00l | JanC: I read http://code.alexreisner.com/articles/upstart.html | 17:20 |
| JanC | in recent versions of upstart you have to put de .conf file in /etc/init/ and not /etc/event.d/ though | 17:22 |
| zer0c00l | JanC: ok :) | 17:24 |
| zer0c00l | JanC: I don't see /etc/init/ in my system | 17:28 |
| zer0c00l | JanC: i am using Fedora 12, /etc/init.d/ is available | 17:28 |
| JanC | zer0c00l: it depends on what version of upstart you use, older versions had /etc/event.d, newer have /etc/init, and I don't know which one Fedora 12 has | 17:30 |
| zer0c00l | JanC: it has 0.3.11 | 17:31 |
| JanC | then it's still event.d | 17:31 |
| zer0c00l | JanC: ok | 17:32 |
| zer0c00l | JanC: I just followed that blog post , I am getting some issues, http://fpaste.org/JFC4/ | 17:34 |
| JanC | it needs a *.conf filename | 17:34 |
| zer0c00l | JanC: works :) | 17:35 |
| zer0c00l | Great Thanks | 17:36 |
| zer0c00l | JanC: One doubt, whether it the process will be monitored an restarted after a reboot? | 17:36 |
| zer0c00l | s/it/ | 17:37 |
| JanC | if you want to be sure, try it ☺ | 17:38 |
| zer0c00l | JanC: Ok ;) | 17:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!