[09:26] <djszapi> hackeron: did you figure it out ?
[09:36] <djszapi> Which job is runfirst by upstart ?
[09:36] <djszapi> * run first, I would like to start an audit daemon asap.
[10:02] <djszapi> so basically the question is like that: "What is the job execution order by upstart ?".
[10:36] <djszapi> JanC ^ any idea ? :o
[10:51] <djszapi> grep -rni "start on startup" .
[10:51] <djszapi> ./sysconfig-early.conf:4:start on startup
[10:51] <djszapi> mmh this process k then ^
[11:07] <djszapi> The primary event emitted by upstart is startup which is when the machine is first started (without writable filesystems or networking) -> But what is the last when poweroff, core_shutdown ?
[15:10] <djszapi> Where can I communicate with an upstart developer ? I did not get any answer on the mailing list for more than 3 days ?
[15:14] <djszapi> JanC: do you have any idea how to implement this PID printing for those missing parts ?
[15:14] <djszapi> I would like to investigate more time in the patch if I can get any starting hint.
[15:21] <JanC> djszapi: Scott is changing between jobs currently, so he might be a bit more busy than usual
[15:21] <JanC> jhunt should also be able to help you with the code
[15:22] <djszapi> jhunt: please do
[15:23] <djszapi> I would like to implement a feature, to print out the shell PID of the pre/post-start/stop commands that were run from those sections.
[15:23] <djszapi> JanC: is upstart fully leisure time project for Scott ?
[15:27] <JanC> I think he could work on it during working hours too, but not all the time as he had other work to do too
[15:28] <djszapi> I meant whether some company pays him for developing upstart.
[15:28] <djszapi> seems a quite essential tool in order to get paid by a company.
[15:28] <JanC> he was paid by Canonical, probably will get paid by Google in the future
[15:28] <JanC> as Google uses upstart in Chrome OS
[15:29] <JanC> and they are his new employer
[15:29] <JanC> http://netsplit.com/2011/01/11/leaving-canonical/ 
[15:31] <jhunt> djszapi: does this relate to your "--verbose" issue?
[15:35] <djszapi> y
[15:37] <djszapi> jhunt: any idea where to start ?
[16:33] <jhunt> djszapi: sorry - meetings :) so from the list mail you are unable to see pids for pre-start scripts for example? I don't fully understand - do you never see pids logged in /var/log/daemon.log?
[16:34] <djszapi> what do you mean jhunt ?
[17:26] <jhunt> keybuk answered your first query. Your second related to "--verbose" where you are not seeing pids being logged for pre-start scripts for example?
[17:27] <jhunt> So, after either specifying "--verbose" or running, "initctl log-priority debug" when you start a job, all script section pids will get logged to (by default) /var/log/daemon.log
[17:27] <jhunt> are you saying you get no output in daemon.log?
[17:58] <djszapi> jhunt ping
[17:58] <jhunt> hello
[17:58] <djszapi> sorry I was travelling.
[17:58] <djszapi> from Nokia to home.
[17:59] <djszapi> 'Your second related to "--verbose" where you are not seeing pids being logged for pre-start scripts for example?' -> Yup.
[17:59] <djszapi> never tried /var/log/daemon.log, keybuk said it should be in syslog, he has never mentioned this daemon.log.
[18:00] <djszapi> and a mount command is not a daemon for instance.
[18:04] <jhunt> well, keybuk is correct in that syslog handles the logging, but on a stock Ubuntu system, it should appear in daemon.log.
[18:04] <djszapi> it is not Ubuntu, but Maemo.
[18:05] <jhunt> you'll have to see how syslog is configured then. a quick grep in the log directory should show you. If that doesn't work, feel free to post further info to the mailing list.
[18:06] <djszapi> did not, posted.
[18:06] <djszapi> nothing related and FYI: same by JanC.
[18:06] <djszapi> but it is a bit suspicious because keybuk has been quite strong minded about its working situation.
[18:07] <djszapi> I could not just speak with him since then.
[18:07] <djszapi> I did not even see him on IRC this week or mailing list.
[18:25] <djszapi> so 1) To make sure it is not implemented 2) If not I can help and I would like.
[18:27] <djszapi> because the situation got worse, auditsyscall kernel option is not supported on ARM :(
[18:28] <djszapi> and not a trivial solution to fix it and if it should anyway be in upstart as a feature it is better to deal with that for me.