[13:23] <djszapi> Why does upstart not print the Process ID of an application launched from a script section ?
[13:23] <djszapi> What is the advantage of this way ?
[13:42] <Keybuk> it does
[13:43] <djszapi> w00t ?
[13:44] <djszapi> Script part can have tens of commands and those are not printed. Only if there is problems like this one /proc/self/fd/6: /etc/pulse/pulseaudio_pre-start.sh: line 53: amixer: not found pulseaudio start/running, process 599. /proc/self/fd is where it runs script part of the .conf files
[13:45] <Keybuk> process 599 is the script itself
[13:45] <Keybuk> and the shared process group of all of those tens of commands
[13:46] <djszapi> so it does not print then.
[13:51] <djszapi> well, what is the solution way if I need that sort of information, Keybuk ?
[13:52] <djszapi> I have just read your mail and I am still not sure the next version (that I do not know when will be released) is useful for my purpose.
[13:52] <djszapi> and for sure I do not have time to wait for that.
[13:53] <djszapi> audit kernel stuff I thought can be a hackaround for now, but let me know, I am newbie in this area.
[13:53] <Keybuk> I don't know what your purposes are
[13:53] <djszapi> well
[13:54] <Keybuk> (so it's hard to me to answer questions where you state "for my purpose")
[13:54] <djszapi> I need the configuration file name and pid of the application that was run by upstart.
[13:54] <djszapi> as it happens quite perfectly with 'exec' entries in the /etc/init/*.conf files.
[13:55] <Keybuk> but it does give you that, it gives you the pid of the script
[13:55] <Keybuk> which is all that was run by Upstart ;-)
[13:56] <djszapi> nope
[13:57] <Keybuk> what do you mean "nope"
[13:57] <Keybuk> I'm pretty sure only one of the two of us *wrote* Upstart, so knows what he's talking about :p
[13:57] <djszapi> hwclock:329,sh:328,init:1
[13:57] <djszapi> for example this is the procedure, init -> sh (upstart) -> hwclock
[13:58] <Keybuk> right, Upstart ran "sh"
[13:58] <djszapi> I need the pid of the hwclock and the configuration file name which started it.
[13:58] <Keybuk> so status in that example will give you the pid of sh
[13:58] <Keybuk> not of hwclock
[13:58] <Keybuk> ok, that's *NOT* what you said above
[13:58] <Keybuk> you said "id of the application that was run by upstart"
[13:58] <Keybuk> upstart ran sh
[13:58] <djszapi> no
[13:58] <Keybuk> what sh did is entirely up to sh
[13:58] <Keybuk> are you disputing what you typed?
[13:58] <Keybuk> because I just copy & pasted it
[13:59] <djszapi> okay, you do not still understand it :)
[13:59] <djszapi> let me give you an example:
[13:59] <Keybuk> no, I understand far more than you
[13:59] <Keybuk> you're just not explaining yourself
[13:59] <Keybuk> and probably you don't actually know what you want
[13:59] <Keybuk> and don't understand how processes work on UNIX
[14:00] <djszapi> do not insult me, please.
[14:00] <Keybuk> I believe what you want is:
[14:00] <Keybuk>   script
[14:00] <Keybuk>     foo &
[14:00] <Keybuk>     bar &
[14:00] <Keybuk>     baz &
[14:00] <Keybuk>   end script
[14:00] <djszapi> as said, WAIT
[14:00] <Keybuk> to give you the pids of foo, bar and baz ?
[14:00] <djszapi> I am gonna give you an example, patient pls...
[14:01] <djszapi> I need to boot the device up.
[14:01] <Keybuk> is that not what you want?
[14:01] <djszapi> seems you cannot be patient :)
[14:01] <Keybuk> no
[14:01] <Keybuk> I'm busy
[14:02] <Keybuk> I'm answering you rather than working
[14:02] <Keybuk> because I'm nice ;-)
[14:02] <Keybuk> but I don't have much time
[14:02] <djszapi> work now and ask when I provide info ?
[14:02] <djszapi> and to avoid the guesswork and wasted time till that ?
[14:02] <Keybuk> sure, will you hang around here for, say, 6 hours?
[14:03] <djszapi> please do not be arrogant for hours, if I may ask...
[14:03] <Keybuk> I'm not being arrogant, I am, right now, using my lunch hour to try and help you
[14:03] <Keybuk> and you're not answering my question
[14:04] <djszapi> because I still cannot ?
[14:04] <Keybuk> why?  you can answer questions?
[14:04] <djszapi> http://pastebin.com/GjeJiy7n
[14:05] <djszapi> 14th line for instance.
[14:05] <Keybuk> that's a shell script
[14:05] <djszapi> I would like to get this configuration file back and hwclock pid 
[14:05] <Keybuk> hwclock has no pid at the point that script has finished
[14:05] <Keybuk> because the shell runs hwclock, waits for it to finish, and reaps it
[14:05] <djszapi> weird it has.
[14:05] <djszapi> every process has pid
[14:05] <Keybuk> tell you what
[14:05] <Keybuk> why not read what I typed?
[14:06] <Keybuk> AT THE POINT THAT SCRIPT HAS FINISHED
[14:06] <djszapi> even tho. the same sometimes than the parent process (setuid e.g.)
[14:06] <Keybuk> the shell does something like:
[14:06] <Keybuk>   fork()
[14:06] <Keybuk>     (child:
[14:06] <Keybuk>       exec hwclock)
[14:06] <Keybuk>     (parent:
[14:06] <Keybuk>       wait)
[14:06] <Keybuk>   // now at the next line of shell
[14:07] <Keybuk> so there's no backgrounding going on here
[14:07] <djszapi> k, so I cannot get this information by upstart....
[14:07] <Keybuk> the fact that hwclock has a separate pid is basically an implementation detail
[14:07] <djszapi> how can I get then ?
[14:07] <Keybuk> for example, a particularly over-the-top shell could have hwclock as a built-in
[14:07] <Keybuk> which means it would have no pid
[14:07] <Keybuk> get it when?
[14:08] <djszapi> nope
[14:08] <Keybuk> the pid (if there even is one) will appear and vanish pretty quickly
[14:08] <Keybuk> stop saying "nope" to me
[14:08] <Keybuk> I know what I'm talking about
[14:09] <djszapi> let me wait for someone else to help then...
[14:09] <Keybuk> they'll either tell you the same thing 
[14:09] <Keybuk> or they'll give you incorrect information
[14:09] <djszapi> seems you are in god-mode.
[14:10] <Keybuk> no, I'm trying to help you
[14:10] <Keybuk> but you're not actually listening to anything I say
[14:10] <Keybuk> which is exasperating
[14:10] <djszapi> by screaming at me ?
[14:10] <Keybuk> I'm not screaming at you
[14:10] <Keybuk> I'm telling you how things work
[14:10] <djszapi> and screaming if I am saying sth ?
[14:10] <Keybuk> and you're refusing to believe me
[14:10] <djszapi> interesting help, never tried
[14:10] <Keybuk> which is insulting
[14:10] <Keybuk> you're wrong
[14:10] <Keybuk> do you accept that there is no need for hwclock to have a separate pid at that point?
[14:11] <Keybuk> (feel free to relink /bin/sh -> /bin/busybox and run that script, if you need physical proof)
[14:12] <djszapi> no idea whether it has got pid that point, but I need the 1) conf file name 2) PID when it ran.
[14:12] <Keybuk> you could add strace -f to the shell invocation
[14:13] <djszapi> exactly as it happens in case the exec line in the configuration files.
[14:13] <Keybuk> that way you'd trace all the system calls, and follow forks, so you'd get the pids that way
[14:13] <Keybuk> you could use the proc connector kernel interface to follow the forks/execs of the shell and again get the pids
[14:14] <Keybuk> proc connector is racey though, because the pid may vanish before you have an opportunity to read /proc/PID/cmdline and actually figure out what it is
[14:14] <Keybuk> (strace at least blocks)
[14:14] <djszapi> pid is not enough, as said also the config file where it was run frm.
[14:14] <Keybuk> audit, ftrace, etc. any of those kernel tracing hooks
[14:14] <djszapi> * from
[14:15] <djszapi> well, my original idea was the audit stuff.
[14:15] <Keybuk> you could mount a subsystem-less cgroup hierarchy and place that script into a new cgroup within it
[14:15] <Keybuk> that would collect the pids run in the tasks file
[14:15] <Keybuk> but again, that only really tells you background processes
[14:15] <Keybuk> hwclock would come and go, so unless you polled the tasks file *really hard* you may not even see the pid
[14:16] <Keybuk> (and even then, /proc/PID/cmdline would probably be gone by the time you found the pid)
[14:16] <djszapi> yeah, but audit should not be racey.
[14:16] <Keybuk> audit is racey
[14:16] <djszapi> or "slow".
[14:16] <Keybuk> and slow
[14:16] <djszapi> lol
[14:16] <Keybuk> sadly
[14:16] <Keybuk> audit doesn't block the shell from doing its work
[14:17] <djszapi> which is nifty.
[14:17] <Keybuk> so when the shell forks off hwclock, it doesn't actually stop anything
[14:17] <Keybuk> so by the time that the audit system is told about the new pid, it could have already finished running
[14:17] <djszapi> hard to imagine.
[14:17] <Keybuk> which means there won't be any information about it - not even the fact it was hwclock at all
[14:17] <Keybuk> happens all the time
[14:17] <djszapi> as long as the audit follows the syscalls.
[14:17] <Keybuk> you'd have to follow the fork and the exec calls
[14:17] <Keybuk> and extract the strings from the exec call (which is actually an array of strings)
[14:18] <Keybuk> that's what then makes it slow
[14:18] <djszapi> well, not really.
[14:18] <djszapi> it depends on the kernel configuration.
[14:18] <Keybuk> no, really ;(
[14:18] <djszapi> you are not obligate to enable the syscall tracing capability.
[14:19] <Keybuk> no, I mean it's just slow when enabled
[14:19] <Keybuk> it can be nearly free when turned off
[14:19] <Keybuk> your best bet, really, is to get the shell to tell you the pids ;)
[14:19] <Keybuk> for example, you could write that script as
[14:19] <Keybuk>   hwclock -s -u &
[14:19] <djszapi> yeah, but that option is just one of the available audit options, you can still use audit with no syscall trace.
[14:19] <Keybuk>   # you now have the PID in $!
[14:19] <Keybuk>   wait $!
[14:19] <Keybuk> sure, but audit with no syscall trace means you won't get the pids ;)
[14:20] <djszapi> mmh
[14:20] <djszapi> so the easiest way is to modify ALL the configuration files existing.
[14:20] <Keybuk> well, it depends yeah
[14:21] <Keybuk> a better question is why do you need to know the PID of that hwclock invocation?
[14:21] <djszapi> I cannot talk about that, sorry. Company project and NDA.
[14:21] <Keybuk> do you need to know the pid of the date and test invocations?
[14:21] <djszapi> if it was run directly by upstart shell then yeah.
[14:22] <Keybuk> there's no such thing as "upstart shell"
[14:22] <Keybuk> that's what I was referring to earlier
[14:22] <djszapi> wtf ? :D
[14:22] <Keybuk> everything in that script block - upstart thinks is a big string
[14:22] <Keybuk> you can put whatever you want in there
[14:22] <Keybuk> all upstart does is exec /bin/sh and pipe that string to it
[14:22] <djszapi> I mean in the process queue, there is a shell process after the init process and I meant that shell as an upstart shell.
[14:22] <Keybuk> which is what I mean about "the application that Upstart runs" *is* /bin/sh
[14:23] <Keybuk> interesting example:
[14:23] <Keybuk>   script
[14:23] <Keybuk>     exec hwclock -s -u
[14:23] <Keybuk>   end script
[14:23] <Keybuk> what will Upstart say the pid of that is? :-)
[14:23] <Keybuk> (hwclock)
[14:23] <djszapi> no idea
[14:23] <Keybuk> without knowing your project
[14:24] <Keybuk> one option would be for you to patch /bin/sh itself
[14:24] <djszapi> lol
[14:24] <Keybuk> why lol ?
[14:24] <djszapi> funny
[14:24] <Keybuk> let's say you have this upstart job
[14:24] <Keybuk>   exec /lib/foo/some-binary
[14:25] <Keybuk> if that some-binary is that shell script you paste-binned
[14:25] <Keybuk> do you *still* need the pids from it?
[14:25] <djszapi> no
[14:25] <Keybuk> interesting, why the distinction?
[14:25] <djszapi> :)
[14:25] <Keybuk> *shrug*
[14:26] <Keybuk> seems pretty arbitrary to me
[14:26] <Keybuk> btw, that script is *completely* bat shit insane
[14:26] <Keybuk> you don't need to run hwclock like that
[14:26] <djszapi> no we need.
[14:26] <djszapi> and it was just an example if you do not like, the point is you got the idea.
[14:26] <Keybuk> but I don't get the idea
[14:27] <djszapi> do not make it with me, pleae :)
[14:27] <djszapi> * please
[14:27] <Keybuk> I don't get why you're treating scripts pasted into an upstart conf file differently to those elsewhere
[14:27] <djszapi> do not do it to me :)
[14:27] <Keybuk> let's give a hypothetical example:
[14:27] <djszapi> you do not need to understand that bit.
[14:27] <Keybuk> let's say you have a system which is entirely an upstart-native boot
[14:27] <Keybuk> no, I *do* to help you
[14:27] <djszapi> our system is that.
[14:27] <Keybuk> ok
[14:28] <Keybuk> so have upstart as the last thing run a shell
[14:28] <djszapi> well, I can tell you why tbh.
[14:28] <Keybuk> the PIDs run by Upstart are "1 thru the PID of that shell:"
[14:28] <Keybuk> no?
[14:28] <djszapi> but it requires a more in-depth understanding.
[14:28] <djszapi> and not 1 min
[14:28] <djszapi> that is why I would like to avoid it for now.
[14:28] <djszapi> I would not like to bother you.
[14:28] <Keybuk> if, after booting, the shell's pid is 1456 then Upstart has resulted in 1,456 processes being run
[14:29] <djszapi> yeah, a sheel after the jobs, daemons.
[14:29] <djszapi> * shell
[14:29] <djszapi> yeah, it is trivial
[14:29] <djszapi> but what is your gist ?
[14:29] <Keybuk> no gist, I'm trying to understand what you're trying to do
[14:30] <djszapi> well
[14:30] <Keybuk> for example, if you were trying to measure the overhead of using shell scripts for things rather than writing them in C
[14:30] <djszapi> there are more shell scripts in fact, not just one.
[14:30] <djszapi> depends on the amount of configuration file stuff
[14:30] <djszapi> well, put it that way.
[14:30] <djszapi> do you know Maemo, MeeGo ?
[14:30] <Keybuk> of course
[14:30] <djszapi> define "of course".
[14:30] <Keybuk> it's hard to work out, because - for example - what if hwclock forked off an extra child?
[14:31] <Keybuk> do you want to know two pids or one?
[14:31] <djszapi> are you a nokian ?
[14:31] <Keybuk> of course I know of Maemo/MeeGo
[14:31] <Keybuk> no, but I know lots of people who are
[14:31] <djszapi> excellent
[14:31] <djszapi> so we use upstart in this project.
[14:31] <djszapi> right ?
[14:31] <Keybuk> indeed
[14:31] <djszapi> well
[14:31] <Keybuk> well, on/off
[14:31]  * Keybuk checks whether there's a "u" in the day
[14:32] <djszapi> ?
[14:32] <Keybuk> sorry, possibly an English expression
[14:32] <djszapi> nvm...
[14:32] <Keybuk> Maemo/MeeGo uses Upstart on Sunday, Tuesday, Thursday and Saturday
[14:32] <Keybuk> but something else on Monday, Wednesday, Friday
[14:32] <djszapi> so you know maemo, meego security framework
[14:32] <Keybuk> a joke about the fact that they change their mind every minute
[14:32] <Keybuk> no, I don't know about that I'm afraid
[14:32] <djszapi> it is a bit different compared to the traditional posix capability stuff.
[14:32] <djszapi> it is more fine tuned stuff, like selinux, smack
[14:32] <djszapi> and the like
[14:33] <Keybuk> ok
[14:33] <djszapi> btw, do not starve because of me :)
[14:33] <Keybuk> I've eaten :)
[14:33] <djszapi> *Nifty, googles*
[14:33] <djszapi> *giggles*
[14:33] <djszapi> typo king, so
[14:34] <djszapi> we use manifest files for fine-tune capability management
[14:34] <djszapi> and upstart and daemon maintainer did something wrong :)
[14:34] <djszapi> no manifest stuff, and all the run jobs, daemon, upstart have all the capabilities.
[14:34] <djszapi> We wrote a debugger kernel module which gives a line like that:
[14:35] <djszapi> [    9.701293] captrace:allow=25|hwclock:329,sh:328,init:1
[14:35] <djszapi> 25 obv. comes from /usr/include/linux/capabili.*
[14:35] <djszapi> it is a capability
[14:35] <djszapi> that is the output during the boot-up
[14:36] <djszapi> and I do some kind of reverse engineering with the perl script
[14:36] <djszapi> to generate the manifest files for upstart and jobs, daemons maintainers.
[14:36] <djszapi> can you follow ?
[14:36] <Keybuk> yup
[14:36] <djszapi> okay, great I need the conf path to put into the manifest file.
[14:36] <djszapi> and just the daemon binary path in case daemons
[14:36] <djszapi> that is why it does not matter in that case.
[14:37] <djszapi> so the jobs, daemons capabilities are separated.
[14:37] <djszapi> because they are different debian packages.
[14:37] <djszapi> or rpm, whateva'
[14:38] <djszapi> e.g. /usr/bin/pulseaudio
[14:38] <djszapi> but the stuff run by upstart.
[14:38] <djszapi> will be dropped by the upstart package.
[14:38] <djszapi> and we are still speaking about credentials.
[14:38] <djszapi> is it clear ?
[14:39] <djszapi> so [    9.701293] captrace:allow=25|hwclock:329,sh:328,init:1 is a good line, but I need to pass it with a configuration file
[14:39] <djszapi> from which hwclock was run actually.
[14:40] <djszapi> hwclock pid is there, 329
[14:40] <djszapi> and that is what I should match with upstart debug output, if any
[14:40] <djszapi> and get the related configuration file name
[14:40] <djszapi> that is all about, feel free to ask if something is vague.
[14:44] <Keybuk> ah, I usee
[14:44] <Keybuk> so if you had a line saying date:330,sh:328,init:1
[14:44] <Keybuk> you'd just ignore it?
[14:47] <Keybuk> so there's an easy way to map <blah>:<pid>,init:1 to an Upstart conf name
[14:47] <Keybuk> boot with --verbose, in the system logs upstart will list all the pids along with the job
[14:47] <Keybuk> so you could compare the syslog to that log, and extract :PID,init:1 and map all instances of those to a .conf
[14:48] <Keybuk> as for the things like hwclock and soforth run by the scripts, audit is *probably* the right place
[14:49] <Keybuk> since in those cases, hwclock's ppid remains 328, init never finds out about it - the only time init really cares about a pid is when the ppid dies and it gets reparented to init, you see
[14:49] <djszapi> usee ?
[14:50] <Keybuk> "see" sorry
[14:50] <djszapi> I would not ignore a line, why do you think that ?
[14:50] <Keybuk> well, date doesn't need any extra capabilities? :-)
[14:50] <Keybuk> or maybe it does
[14:50] <djszapi> gotcha
[14:50] <djszapi> you are right
[14:50] <djszapi> the common linux commands do not.
[14:51] <djszapi> but it is just a whitelisty parsy thingy.
[14:51] <djszapi> this is not the main question here for now.
[14:51] <djszapi> so there's an easy way to map <blah>:<pid>,init:1 to an Upstart conf name
[14:51] <djszapi> nope ^
,sh:xxx,init:1
[14:52] <Keybuk> --verbose will give you the log messages to do that
[14:52] <djszapi> the blah process can most likely be "advanced" cmd.
[14:52] <djszapi> advanced = extra credentials for now
[14:52] <djszapi> most likely the one left to that in the line is gonna be a common tool as you have just mentioned.
[14:52] <djszapi> it is a kinda process tree tho.
[14:52] <Keybuk> --verbose will give you:
[14:53] <Keybuk> Jan 14 14:52:49 deathspank init: tty6 main process (8557)
[14:53] <Keybuk> log messages
[14:53] <Keybuk> that means you know that all
[14:53] <djszapi> boot with --verbose, in the system logs upstart will list all the pids along with the job -> nope
,sh:8557,init:1
[14:53] <djszapi> as said, we do not need jobs
[14:53] <djszapi> just commands from the scripts
[14:53] <Keybuk> no, not ALL
[14:53] <djszapi> jobs means by me the daemons.
[14:53] <Keybuk> but you don't need all
[14:53] <Keybuk> Jan 14 14:52:49 deathspank init: tty6 main process (8557)
,sh:8557,init:1
[14:53] <Keybuk> see how the 8557 lines up there
[14:53] <djszapi> so ?
[14:54] <Keybuk> every <blah> run by that script will still end ",sh:8557,init:1"
,sh:8557,init:1
[14:54] <Keybuk> hwclock:8558,sh:8557,init:1
[14:54] <Keybuk> date:8559,sh:8557,init:1
[14:54] <djszapi> give me 2-3 mins to read your posts again.
[14:54] <Keybuk> mkdir:8560,sh:8557,init:1
[14:54] <Keybuk> hwclock:8563,sh:8557,init:1
[14:54] <Keybuk> for example
[14:54] <Keybuk> if that script ran at least those four commands, that's what you'd see, no?
[14:54] <Keybuk> (the ppid of each of those remains 8557)
[14:55] <Keybuk> and, in fact, the pgid and sid of even hwclock is 8557
[14:55] <Keybuk> so that tells you that the shell script run by upstart for the "tty6.conf" ran those four commands
[14:55] <djszapi> since in those cases, hwclock's ppid remains 328, init never finds out about it - the only time init really cares about a pid is when the ppid dies and it gets reparented to init, you see
[14:55] <Keybuk> right
[14:56] <djszapi> -> yes, I mentioned an example in the beginning for that.
[14:56] <Keybuk> unless a process deliberately attempts to shed its session, the pgid and sid will remain the same as the shell
[14:57] <djszapi> 16:57 < Keybuk> Jan 14 14:52:49 deathspank init: tty6 main process (8557)
[14:57] <djszapi> well it is not enough
[14:57] <Keybuk> why not?
[14:57] <djszapi> it is just about the shell script, not the application run by that.
[14:57] <Keybuk> why is it just about the shell script?
[14:58] <Keybuk> from what you've told me, that'd exactly what you want, isn't it?
[14:58] <djszapi> nope
[14:58] <djszapi> okay, give me a better example and not hwclock
[14:58] <Keybuk> no, what _do_ you want then?
[14:58] <djszapi> * let me give you
[15:01] <djszapi> sorry Keybuk
[15:01] <Keybuk> maybe I should have picked a better test command than "stop gdm" :p
[15:01] <djszapi> :P
[15:01] <djszapi> you were right
[15:01] <Keybuk> http://people.canonical.com/~scott/forkwatch.c.txt
[15:01] <djszapi> I did not understand what I mean
[15:02] <djszapi> * You mean
[15:02] <djszapi> * meant..erm
[15:02] <Keybuk> if you need something that *really* can watch all the forks, that C program should help
[15:02] <djszapi> wait
[15:02] <Keybuk> though you'll see what I mean about the cmdline race there
[15:02] <Keybuk> audit might be better
[15:02] <djszapi> we have just discussed the verbose stuff is ok'ish
[15:02] <Keybuk> the verbose stuff should get you back to an upstart .conf file, yeah
[15:03] <Keybuk> and you can turn it off after boot with "initctl log-priority warn"
[15:03] <djszapi> well, the pid idea was about the identification
[15:03] <djszapi> but I need the config file only at last.
[15:04] <djszapi> http://people.canonical.com/~scott/ -> is it your stuff ?
[15:04] <djszapi> Keybuk: well not an issue
[15:04] <Keybuk> djszapi: yup
[15:04] <Keybuk> my stuff
[15:04] <djszapi> as you got the point this task is because of a wrong maintainer past
[15:04] <djszapi> so hopefully it is not gonna require continous running.
[15:04] <djszapi> during the lifecycle of the device, os.
[15:05] <Keybuk> *nods
[15:05] <Keybuk> you can turn on --verbose btw with "initctl log-priority info"
[15:05] <Keybuk> so you don't even need to reboot to enable it
[15:05] <djszapi> but for confirmation, let me give you a better example than hwclock was.
[15:05] <djszapi> [    8.318542] captrace:allow=6|aegis-loader:191,sh:188,init:1
[15:06] <djszapi> aegis-loader is an internal application
[15:06] <djszapi> run by upstart's script section
[15:06] <djszapi> right ?
[15:06] <Keybuk> right
[15:06] <Keybuk> I assume from that that aegis-loader still has pgid/sid=188
[15:07] <Keybuk> ?
[15:07] <djszapi> highly doubt
[15:07] <Keybuk> is it a background process?
[15:08] <djszapi> RM680-02-2_RD_001:/etc/init# grep -rni aegis-loader .
[15:08] <djszapi> ./aegis.conf:14:    if [ -d /sys/kernel/security/credp -a -x /usr/bin/aegis-loader ]; then
[15:08] <djszapi> ./aegis.conf:15:        /usr/bin/aegis-loader || echo "Failed to load aegis"
[15:08] <Keybuk> right, so doesn't look backgroundy to me
[15:08] <Keybuk> so it should still be easy to match up
[15:08] <djszapi> righty
[15:08] <djszapi> k
[15:09] <djszapi> one thingy I do not understand about your posts.
[15:09] <Keybuk> what's that?
[15:09] <djszapi> 16:52 < Keybuk> as for the things like hwclock and soforth run by the scripts, audit is *probably* the right place
[15:10] <Keybuk> right, to find out the pid of hwclock in the first place, rather than the shell
[15:10] <Keybuk> you know the pid of the shell, upstart knows the pid of the shell, upstart logs it, etc.
[15:10] <Keybuk> but upstart doesn't know (or care) what the shell does
[15:10] <Keybuk> so you need something to get the pid of the things the shell runs
[15:10] <Keybuk> so then you map those things back to the .conf file
[15:10] <Keybuk> basically you'll end up with a process tree
[15:11] <Keybuk> pid 1 forked pid 57 forked pid 134
[15:11] <Keybuk> 134 might be hwclock
[15:11] <Keybuk> so you look up its parent, 57, in the log - and that tells you its wibble.conf
[15:11] <Keybuk> wibble main process (57)
[15:12] <djszapi> well
[15:12] <djszapi> sh:pid,init:1
[15:12] <Keybuk> right
[15:12] <djszapi> shS are the shell scripts coming from upstart (during the boot-up for instance), aren't they ?
[15:12] <Keybuk> not always
[15:12] <Keybuk> that's why I asked about exec /lib/blah/blah style
[15:12] <Keybuk> that can show up as just "sh" too
[15:13] <Keybuk> (if blah is a shell script)
[15:13] <djszapi> because that way I would say we do not need anything else than the process id of the shell if it is quite enough information to figure out the configuration file.
[15:13] <djszapi> let us grep for exec lines, momment
[15:14] <djszapi> well I do not see any shell script in the output.
[15:15] <djszapi> getty, syslogd, sshd, udevd, internal binaries...
[15:15] <djszapi> no shell script.
[15:15] <djszapi> mostly /usr/(s)bin stuf.
[15:15] <djszapi> and /sbin ofc.
[15:16] <Keybuk> cool
[15:16] <Keybuk> you're using dash then? ;-)
[15:16] <djszapi> your mean ?
[15:16] <Keybuk> readlink /bin/sh
[15:17] <Keybuk> probably /bin/dash or /bin/bash
[15:17] <djszapi> busybox
[15:17] <Keybuk> oh right
[15:17] <djszapi> ofc embedded mobile phones
[15:17] <Keybuk> that's usually a bugger for not setting proctitles ;-)
[15:17] <djszapi> and some netbook
[15:17] <djszapi> we are talking about in case Maemo, MeeGo.
[15:17] <djszapi> 'that's usually a bugger for not setting proctitles ;-)' -> can you be a bit more expressive, please ?
[15:18] <Keybuk> oh, I mean that busybox often doesn't bother setting the proctitle
[15:18] <Keybuk> (the thing you see in ps)
[15:18] <Keybuk> so when it gets a shell script, you often just see 'sh' rather than '/bin/foo'
[15:18] <Keybuk> but that, of course, depends on its configuration when built
[15:19] <Keybuk> doesn't matter
[15:19] <Keybuk> since it obviously does the right thing for you
[15:21] <djszapi> y
[15:23] <djszapi> so it seems we do not need audit and kernel hacking then
[15:23] <djszapi> but let me know the truth (aka. fixme).
[15:29] <djszapi> After this command: 'initctl log-priority warn' -> it works perfectly after every reboot that way until I set it back, right ?
[15:31] <Keybuk> right
[15:32] <djszapi> right what ?
[15:33] <Keybuk> right :)
[15:34] <djszapi> well, I said/asked two things, both ?
[15:35] <Keybuk> both
[15:35] <djszapi> k, ty.
[15:38] <djszapi> btw, are you an upstart developer ?
[15:38] <Keybuk> I wrote Upstart
[15:38] <djszapi> alone ?
[15:39] <Keybuk> pretty much
[15:39] <djszapi> lol
[15:39] <djszapi> you are crazy :D
[15:39] <Keybuk> yes
[15:40] <djszapi> CONFIG_CMDLINE="init=/sbin/preinit root=0xB302 rootfstype=ext4 rw console=ttyS0,115200n8 omap3_die_id" -> this is the default, so just -> CONFIG_CMDLINE="init=/sbin/preinit root=0xB302 rootfstype=ext4 rw console=ttyS0,115200n8 omap3_die_id verbose" ?
[15:40] <djszapi> or what is the correct syntax ?
[15:40] <Keybuk> --verbose
[15:41] <djszapi> weirdy
[15:42] <djszapi> well, it does not print anything in fact, I have just tried it out.
[15:43] <Keybuk> no, it logs it so syslog
[15:43] <djszapi> highly doubt
[15:43] <djszapi> we redirect it to console and watch in minicom
[15:44] <djszapi> there is no syslog here.
[15:45] <djszapi> mmh....
[15:46] <djszapi> no idea I guess.
[15:47] <djszapi> ok I gave it up :/
[15:47] <Keybuk> I've no idea what your configuration is wrt syslog
[15:47] <Keybuk> but that's where upstart sends its log messages
[15:48] <djszapi> by default: /var/log/syslog ?
[15:49] <Keybuk> no, syslog
[15:49] <Keybuk> man 3 syslog
[15:49] <djszapi> there is no /var/log/messages*
[15:49] <Keybuk> syslog is a socket interface
[15:49] <Keybuk> where they go after that, depends entirely on your setup
[15:49] <Keybuk> (or even if anything listens)
[15:49] <djszapi> man 3 -> developer man pages.
[15:50] <djszapi> I do not develop with syslog.
[15:50] <Keybuk> I do :)
[15:50] <djszapi> by default: -> there is not "depends entirely on your setup" thingy :)
[15:51] <djszapi> anyways...no idea where the log should be then
[15:53] <Keybuk> you need to speak to the maemo/meego developer who knows where syslog() messages go on meego
[15:53] <djszapi> again: minimum, serial port
[15:54] <djszapi> at least my printk goes there...
[15:54] <djszapi> and printk is supposed to go to the syslog if nothing else h appens.
[15:54] <djszapi> * minimum = minicom
[15:55] <djszapi> seems verbose does not work
[15:55] <djszapi> maybe the command line option struggles.
[15:55] <djszapi> is there any way to check the command line with which the system was booted up ?
[15:56] <djszapi> some sysfs or procfs heuristics ?
[15:57] <djszapi> RM680-01-2:~# initctl log-priority warn
[15:57] <djszapi> RM680-01-2:~# 
[15:57] <djszapi> this does not help either after the rebootl.
[15:57] <djszapi> * reboot
[15:58] <djszapi> the upstart might not work on this boot at all ??
[15:58] <djszapi> I do not see any other upstart related entries either.
[15:58] <djszapi> should they occur at all ?
[16:04] <sam-_-> so i want to disable an upstart job. would i just uncomment the "start on" line? what's the preferred way to do this?
[16:14] <djszapi> how can that be Keybuk, I do not get any upstart messages, nor the debug statements about the stopped, started processes ?
[16:45] <JanC> sam-_-: I think you mean *comment* the "start on" line?  (and yes, that should prevent it from getting started automatically)
[16:45] <sam-_-> JanC, is the preferred way?
[16:46] <sam-_-> JanC, y. that's what i meant. 
[16:46]  * sam-_- hits himself in the head
[16:46] <JanC> ☺
[16:46] <Stevee> if you are using upstart 0.6.7, there is a stanza called "manual" add this entry to any jobfile to prevent upstart to start it by any event
[16:47] <sam-_-> Stevee, ah ok. thx
[16:48] <JanC> in case you are using Ubuntu, Maverick still has 0.6.6
[16:48] <sam-_-> i'm on 0.6.6 though :-(
[16:48] <JanC> so 0.6.7 is very new
[16:48] <sam-_-> yes
[16:48] <sam-_-> so the comment will have to do it :-)
[16:48] <sam-_-> so the commenting will have to do it :-)
[16:49] <JanC> for now at least
[16:49] <sam-_-> y. no problem.
[16:50] <JanC> even natty still has 0.6.6 it seems
[16:50] <JanC> (but I guess that will change?)
[16:51] <Keybuk> natty has 0.6.7
[16:51] <JanC> hm, no
[16:51] <JanC> package says 0.6.7, --version says 0.6.6
[16:52] <JanC> initctl --version
[16:53] <JanC> so probably it's 0.6.7 but doesn't know that itself  ;)
[16:54] <Keybuk> huh
[16:57] <SpamapS> Has there very been a discussion of an 'expect listen' ?
[16:57] <Keybuk> yes
[16:59] <Keybuk> though it goes something more like "why not use 'start on socket'" :p
[16:59] <SpamapS> Yeah thats where I get to as well.. the example I'd give is mysql .. which may take 20 minutes to start if it has to recover large innodb transaction logs.
[17:00] <Keybuk> yeah, and on a server you might want mysql always running
[17:00] <Keybuk> not just started on first activation
[17:00] <Keybuk> though even then, it would have the listening socket passed to it
[17:01] <Keybuk> so it's a bit of a tricky one
[17:01] <Keybuk> the other side of the question is - does the kernel even notify userspace of new sockets?
[17:01] <Keybuk> I had a vague idea there might be something netlink-y but I've not looked
[17:02] <djszapi> Keybuk: gotta go, ty for your help today :)
[17:03] <djszapi> my virtual beer is yours, heh
[17:30] <JanC> Keybuk: the source package for upstart 0.6.7 in natty says 0.6.6 in configure.ac & configure, but that seems to be correct/fixed in upstream 0.6.7
[17:30] <Keybuk> weird
[17:33] <Keybuk> wonder why 
[20:47] <SpamapS> t 
[20:48] <SpamapS> 1
[20:49] <SpamapS> oops wrong window
[22:44] <bencc> can you give an example of ubuntu package that uses upstart?
[22:45] <bencc> I'm trying to package a server and want to see how to include the upstart script
[22:48] <JanC> bencc: you mean a server package?
[22:49] <bencc> JanC: a web server
[22:49] <bencc> what do you mean by a server package?
[22:49] <JanC> well, there are many packages that use upstart jobs, but starting a server isn't the same as starting a TTY of course  ;)
[22:50] <bencc> ok
[22:50] <bencc> I have a basic upstart job that start the server
[22:50] <bencc> I want to see how to include it in a .deb package
[22:50] <JanC> I see mysql & squid have upstart jobs
[22:51] <bencc> thanks, checking
[22:54] <bencc> JanC: dh-make produces example files like init.d.ex
[22:54] <bencc> I don't see an example for upstart
[22:56] <JanC> bencc: maybe file a (wishlist) bug about that then?
[22:56] <bencc> JanC: ok but I don't know how to use it
[22:57] <bencc> JanC: if there is init.d.ex the packaging tool probably handle it in a special way
[22:57] <bencc> so I'm not sure if I need to put the upstart on the root or maybe treat it as a normal file
[23:51] <tgm4883> When looking at upstart services, what is the meaning of +, -, and ?. for example   [ ? ]  acpi-support
[23:51] <tgm4883> I've been querying the info, but + and ? tend to be the same