[00:13] <radix> for what it's worth, 'stop cron' does actually kill the cron process (as does 'restart cron', though that one doesn't bring it back up)
[00:13] <radix> so it's communicating enough that it can do its job, but then not cleaning up properly or continuing to further steps, I guess
[00:35] <radix> for what it's worth, --verbose doesn't seem to write anything when running stop / restart at runtime, though I do see all the console output at first run
[00:35] <radix> er, at boot
[18:39] <radix> did anyone get around to looking at those strace outputs I pastebined yesterday?
[18:58] <steffen_b> hi there
[18:58] <steffen_b> searching for some helping hand of shutdown 
[18:59] <steffen_b> with natty 
[18:59] <steffen_b> + debugging 
[19:00] <steffen_b> problem is that a handfull of services is not shutdown 
[19:04] <JanC> define "not shutdown"
[19:06] <steffen_b> its stopped on runlevel 
[19:06] <steffen_b> 016
[19:06] <steffen_b> and i can see until very late in shutdown process normal messages
[19:06] <steffen_b> of the daemon 
[19:07] <steffen_b> it doesnt do any shutdown messages 
[19:07] <steffen_b> stopping plugins
[19:07] <steffen_b> or anything 
[19:07] <steffen_b> and late in the boot 
[19:07] <steffen_b> i get stopped with status 1 
[19:08] <steffen_b> i.e.
[19:08] <steffen_b> openbox main process (1273) terminated with status 1
[19:09] <JanC> I doubt openbox is handled by upstart?
[19:10] <Keybuk> with that message, I'd say it is
[19:10] <steffen_b> in my install it is
[19:10] <steffen_b> i written the job ;) 
[19:11] <JanC> if you are doing such a customized setup, why use runlevels?
[19:11] <steffen_b> nice try ;) 
[19:11] <steffen_b> stop on runlevel [016]
[19:12] <steffen_b> is openbox also others which look the same
[19:12] <steffen_b> the system is ubuntu natty , customized 
[19:12] <JanC> heh
[19:13] <steffen_b> i dont want to customize everything only the part which we care 
[19:13] <steffen_b> thats why we base it on ubuntu 
[19:13] <steffen_b> i put a test job in to see if the runlevel come 
[19:14] <steffen_b> and that one is executed fine
[19:14] <JanC> is X also started by upstart?
[19:14] <steffen_b> the openbox job starts X 
[19:14] <steffen_b> xinit openbox basically
[19:15] <JanC> so it's probably X that exits with status 1 ?
[19:16] <steffen_b> i dont debug that one job 
[19:16] <steffen_b> its maybe 10 
[19:16] <steffen_b> all show the same behaviour 
[19:16] <steffen_b> all working fine on lucid
[19:19] <JanC> did you check the PID is actually correct?
[19:20] <steffen_b> believe me the jobs are working 
[19:20] <steffen_b> May  5 19:12:47 vdr init: plymouth-stop pre-start process (1269) terminated with status 1
[19:20] <steffen_b> May  5 19:12:47 vdr init: plymouth-splash main process (1328) terminated with status 1
[19:20] <steffen_b> May  5 19:39:45 vdr init: vdr-frontend main process (1437) terminated with status 143
[19:20] <steffen_b> May  5 19:39:45 vdr init: udisks-automounter main process (1594) terminated with status 143
[19:20] <steffen_b> May  5 19:39:45 vdr init: plymouth-upstart-bridge main process (2186) terminated with status 1
[19:20] <steffen_b> May  5 19:39:45 vdr init: irexec main process (2245) terminated with status 1
[19:20] <steffen_b> this terminated with status 1 doesnt look normal 
[19:21] <steffen_b> and is also not happening each boot 
[19:21] <steffen_b> so something strange is happening in the shutdown 
[19:22] <JanC> doesn't seem to happen on a "normal" natty system either?
[19:23] <steffen_b> looks like something in the shutdown is killing the jobs while they are active 
[19:23] <steffen_b> May  5 19:39:45 vdr init: irexec main process (2245) terminated with status 1
[19:23] <steffen_b> May  5 19:39:45 vdr init: irexec main process (2246) terminated with status 1
[19:23] <steffen_b> May  5 19:39:45 vdr init: irexec main process (2247) terminated with status 1
[19:23] <steffen_b> if you look at this 
[19:24] <steffen_b> i don't have a "normal" natty 
[19:25] <steffen_b> but i can check that 
[19:25] <steffen_b> i would rather debug whats happening 
[19:25] <steffen_b> then trying empiric if it's my fault or ubuntus ;)
[19:31] <JanC> wait, I'm seeing things like "Apr 28 13:47:16 saeko init: plymouth-stop pre-start process (3747) terminated with status 1" too here
[19:31] <steffen_b> or maybe coming from the other side 
[19:32] <steffen_b> if upstart is using dbus for handling the jobs, how can upstart shutdown dbus ?
[19:32] <JanC> upstart only uses dbus for communication with dbus clients
[19:32] <JanC> and it doesn't need the dbus daemon
[19:33] <JanC> for communication with upstart clients I mean
[19:33] <steffen_b> k , so initctl uses 
[19:33] <JanC> things like initctl
[19:33] <steffen_b> something else
[19:33] <steffen_b> not dbus
[19:34] <JanC> dbus is a wire protocol, you can use dbus without a dbus daemon  ;)
[19:35] <steffen_b> well on lucid i tried to send signals in init.d scripts and they got plain ignored back then 
[19:35] <JanC> using initctl?
[19:35] <steffen_b> now it looks like runlevel [016] gets ignored 
[19:35] <steffen_b> yes
[19:36] <steffen_b> which one gets ignored seems to be random/depending on time 
[19:36] <JanC> that's weird
[19:36] <steffen_b> my requirement is to cleanly shutdown the daemon 
[19:37] <steffen_b> nothing should kill it before it is finished
[19:39] <JanC> you have a pre-stop script for that?
[19:40] <steffen_b> no
[19:40] <steffen_b> only post start 
[19:42] <JanC> default way to stop a job is to send SIGTERM, then after some time-out send SIGKILL, so if shutdown of your service takes longer, you'll need a pre-stop to handle this gracefully I think?
[19:42] <steffen_b> https://bugs.yavdr.com/projects/yavdr/repository/entry/trunk/base/yavdr-base/etc/init/vdr.conf
[19:43] <steffen_b> but pre-stop would wait until this is finished 
[19:43] <steffen_b> before actually stopping it 
[19:45] <steffen_b> pre-stop ->  kill with SIGTERM vdr doesn't sound right to me  
[19:46] <steffen_b> also it wouldnt help if something would kill it 
[19:46] <steffen_b> from init.d
[19:48] <steffen_b> i can not believe that natty shutdown is so fucked up or handcrafted for the 5 known use cases 
[19:52] <steffen_b> sry 
[20:05] <JanC> I don't know what exactly goes wrong with your setup, but when using pre-stop for a job you can tell it to shut down and wait until it's ready, after that upstart will see no SIGTERM/SIGKILL is needed for that job anymore
[20:06] <JanC> but maybe you want to know what goes wrong first...
[20:08] <steffen_b> there are 2 issues 
[20:08] <steffen_b> first is that runlevel is not coming or sendsigs is coming to fast  
[20:09] <steffen_b> second is waiting for the daemon to finish
[20:09] <steffen_b> the pre-stop might be nice workaround 
[20:10] <steffen_b> but worth nothing if rc and those sendsigs is killing the jobs
[20:10] <akio> Hello, I have finally figured out how to handle a broken serial port and got console redirection working but I don't know where to put the fix.
[20:11] <steffen_b> on the other hand that should ignore everything which is handled by upstart
[20:11] <akio> I have a ttyS0.conf in /etc/init that starts it for me, but before it starts it needs to be manually configured with setserial.
[20:11] <akio> I was wondering where to put the setserial command.
[20:11] <steffen_b> create a setserial.conf 
[20:12] <steffen_b> start on starting ttys0 
[20:12] <steffen_b> ttyS0
[20:12] <akio> Oh cool thanks.
[20:13] <steffen_b> https://bugs.yavdr.com/projects/yavdr/repository/entry/trunk/base/yavdr-base/etc/init/setserial-minimal.conf
[20:13] <akio> Man upstart really has made GNU\Linux better in a big way for me.
[20:14] <akio> Too complicated for me to follow.
[20:14] <steffen_b> its cool, but causing me headaches sometimes 
[20:14] <akio> Makes boot super fast.
[20:15] <steffen_b> if its just for you , just but the commands you need in the script section ;) 
[20:15] <steffen_b> start on starting ttyS0 
[20:15] <steffen_b> will make it wait until that is finished
[20:16] <steffen_b> you might need to put task keyword also in 
[20:16] <SpamapS> yes, otherwise it won't block properly
[20:17] <SpamapS> task makes it block until the job has completed the whole lifecycle
[20:20] <akio> where does task go?
[20:21] <SpamapS> on its own line
[20:21] <SpamapS> anywhere tho
[20:22] <akio> http://pastebin.com/AHPTn0GW
[20:23] <steffen_b> yes should work 
[20:23] <akio> rebeaut!
[21:39] <akio> steffen_b: Thank you. That worked like a charm.
[21:39] <akio> Because charms work well.
[21:39] <steffen_b> cool :) 
[21:39] <akio> Had an issue last night and couldn't console because previous admin couldn't figure it out.