[10:50] hi; im trying to debug upstart inside a docker, and i would like to attach a gdb to it, but as it crashes directly, i cant [10:51] (idea is to launch one docker with the compiled init and attach a gdb from another shell) [10:51] if someone has an idea on how i can debug ... [12:03] Kiorky: I've never used docker. Do you get any crash output? You could boot your docker environment specifying bash as your init, then start upstart in a separate pid namespace running with --no-startup-event, then attach gdb to that pid. [12:04] jodh: well the difficulty is the docker magic between [12:04] jodh: and that upstart wants pid - 1 [12:05] jodh: well, i want to debug the start process, that's the real problem amongst all [12:05] kiorky: in all likelihood, the crash is probably due to some environment issue: try installing procenv into the docker environment (its in the debian and ubuntu archives, or https://launchpad.net/procenv/), and boot the docker container so that procenv runs first, logs the environment output, then execs upstart. I've blogged about how to do this for lxc here: [12:05] http://ifdeflinux.blogspot.co.uk/2013/04/observing-initial-lxc-environment-using.html [12:05] jodh: i dont know why but init dies, without logs, so my idea was to gdb it [12:06] jodh: lookin' thx [12:06] kiorky: yes, you can run upstart in the docker environment as *pid 1* if you put it into a new pid namespace within your docker environment. [12:06] jodh: ha i see! [12:06] kiorky: are you sure there is no stdout/stderr output being logged by docker somewhere? no docker option to record the console? [12:07] jodh: normally, all goes to docker logs, but anything is captured [12:07] jodh: i have some logs, but nothing fatal [12:07] just that the docker boot and after a little while, dies [12:07] without explanation [12:08] but i will look your blog post and go forward into trying to exec init inside a new pid namespace [12:09] kiorky: I've covered the technique in the cookbook too: http://upstart.ubuntu.com/cookbook/#debugging-another-instance-of-upstart-running-as-root-with-pid-1 [12:10] jodh: in your setup, init starts and then you attach with gdb isnt it ? [12:11] jodh: problem there is that init dies before i can even attach to it [12:11] jodh: i mean on the cookbook [12:12] kiorky: Well, in the lxc example yes, but not in the first example using my clone utility. [12:14] kiorky: I still think it might be quicker to use the procenv trick to get a dump of the docker environment, then run procenv in a "normal" environment and diff the files. [12:16] jodh: the clone is same, you one already running, isnt it ? [12:16] :) [13:58] I'm really at my wits-end here -- how can I, in an unprivileged upstart job, emit an event to start another job? [13:59] I have a job to make logs for a service, so I want the service to start this job 'make sure my logs dir is owned by serviceuser' and then run itself unprivileged (using setgid/setuid) [14:00] Really annoying that pre-start runs as the setuid user :/ [14:00] obviusly sudo doesn't work [14:13] modafinil: easy - turn it round: have the job that handles your logs run as root, then make the job that actually runs the service (with setuid/setgid), specify 'start on stopped '. [14:13] jodh: the problem is that i have a bunch of jobs, and i want them all to use this one job (and set the variable of where the logs dir is) [14:13] i think i figured it out though [14:14] i can 'start on starting acmeco-*' to wildcard match in the log creation job [14:16] modafinil: have the root job that starts first 'export logdir' so that "$logdir" is available to all the non-priv jobs. [14:20] jodh: i agree that would work, but its not really workable for this specific situation -- theres hundreds of different services and i don't want to have one thing that needs to know about them all [14:20] this wildcard match definitely works though [14:21] i appreciate your help! thanks! [15:51] jodh: simpler solution; add a sleep(3) and recompile upstart ;) so i have the time to attach gdb with lxc-execute