| === JanC_ is now known as JanC | ||
| 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:23 |
| Keybuk | it does | 13:42 |
| djszapi | w00t ? | 13:43 |
| 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:44 |
| Keybuk | process 599 is the script itself | 13:45 |
| Keybuk | and the shared process group of all of those tens of commands | 13:45 |
| djszapi | so it does not print then. | 13:46 |
| djszapi | well, what is the solution way if I need that sort of information, Keybuk ? | 13:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| djszapi | nope | 13:56 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| djszapi | because I still cannot ? | 14:04 |
| Keybuk | why? you can answer questions? | 14:04 |
| djszapi | http://pastebin.com/GjeJiy7n | 14:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| Keybuk | (feel free to relink /bin/sh -> /bin/busybox and run that script, if you need physical proof) | 14:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 | |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| djszapi | so the jobs, daemons capabilities are separated. | 14:37 |
| djszapi | because they are different debian packages. | 14:37 |
| djszapi | or rpm, whateva' | 14:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:44 |
| 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:47 |
| Keybuk | as for the things like hwclock and soforth run by the scripts, audit is *probably* the right place | 14:48 |
| 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:49 |
| 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:50 |
| 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 ^ | 14:51 |
| djszapi | <blah>:<pid>,sh:xxx,init:1 | 14:51 |
| 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:52 |
| 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 | 14:53 |
| Keybuk | <blah>:<pid>,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) | 14:53 |
| Keybuk | <blah>:<pid>,sh:8557,init:1 | 14:53 |
| Keybuk | see how the 8557 lines up there | 14:53 |
| djszapi | so ? | 14:53 |
| Keybuk | every <blah> run by that script will still end ",sh:8557,init:1" | 14:54 |
| Keybuk | <blah>:<pid>,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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 14:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| Keybuk | ? | 15:07 |
| djszapi | highly doubt | 15:07 |
| Keybuk | is it a background process? | 15:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| djszapi | well I do not see any shell script in the output. | 15:14 |
| 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:15 |
| Keybuk | cool | 15:16 |
| Keybuk | you're using dash then? ;-) | 15:16 |
| djszapi | your mean ? | 15:16 |
| Keybuk | readlink /bin/sh | 15:16 |
| 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:17 |
| 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:18 |
| Keybuk | doesn't matter | 15:19 |
| Keybuk | since it obviously does the right thing for you | 15:19 |
| djszapi | y | 15:21 |
| 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:23 |
| djszapi | After this command: 'initctl log-priority warn' -> it works perfectly after every reboot that way until I set it back, right ? | 15:29 |
| Keybuk | right | 15:31 |
| djszapi | right what ? | 15:32 |
| Keybuk | right :) | 15:33 |
| djszapi | well, I said/asked two things, both ? | 15:34 |
| Keybuk | both | 15:35 |
| djszapi | k, ty. | 15:35 |
| djszapi | btw, are you an upstart developer ? | 15:38 |
| Keybuk | I wrote Upstart | 15:38 |
| djszapi | alone ? | 15:38 |
| Keybuk | pretty much | 15:39 |
| djszapi | lol | 15:39 |
| djszapi | you are crazy :D | 15:39 |
| Keybuk | yes | 15:39 |
| 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:40 |
| djszapi | weirdy | 15:41 |
| djszapi | well, it does not print anything in fact, I have just tried it out. | 15:42 |
| 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:43 |
| djszapi | there is no syslog here. | 15:44 |
| djszapi | mmh.... | 15:45 |
| djszapi | no idea I guess. | 15:46 |
| 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:47 |
| djszapi | by default: /var/log/syslog ? | 15:48 |
| 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:49 |
| 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:50 |
| djszapi | anyways...no idea where the log should be then | 15:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| djszapi | some sysfs or procfs heuristics ? | 15:56 |
| 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:57 |
| 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 ? | 15:58 |
| 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:04 |
| djszapi | how can that be Keybuk, I do not get any upstart messages, nor the debug statements about the stopped, started processes ? | 16:14 |
| 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:45 |
| 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:46 |
| sam-_- | Stevee, ah ok. thx | 16:47 |
| 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:48 |
| JanC | for now at least | 16:49 |
| sam-_- | y. no problem. | 16:49 |
| JanC | even natty still has 0.6.6 it seems | 16:50 |
| JanC | (but I guess that will change?) | 16:50 |
| 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:51 |
| JanC | initctl --version | 16:52 |
| JanC | so probably it's 0.6.7 but doesn't know that itself ;) | 16:53 |
| Keybuk | huh | 16:54 |
| SpamapS | Has there very been a discussion of an 'expect listen' ? | 16:57 |
| Keybuk | yes | 16:57 |
| 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. | 16:59 |
| 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:00 |
| 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:01 |
| djszapi | Keybuk: gotta go, ty for your help today :) | 17:02 |
| djszapi | my virtual beer is yours, heh | 17:03 |
| 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:30 |
| Keybuk | wonder why | 17:33 |
| SpamapS | t | 20:47 |
| SpamapS | 1 | 20:48 |
| SpamapS | oops wrong window | 20:49 |
| bencc | can you give an example of ubuntu package that uses upstart? | 22:44 |
| bencc | I'm trying to package a server and want to see how to include the upstart script | 22:45 |
| JanC | bencc: you mean a server package? | 22:48 |
| 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:49 |
| 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:50 |
| bencc | thanks, checking | 22:51 |
| bencc | JanC: dh-make produces example files like init.d.ex | 22:54 |
| bencc | I don't see an example for upstart | 22:54 |
| 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:56 |
| 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 | 22:57 |
| 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 | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!