Andi -- ping! Adding Neil to CC, since it looks like he also did some work here, and so can perhaps comment. On Fri, Apr 18, 2008 at 6:53 PM, Michael Kerrisk <mtk.manpages@xxxxxxxxxxxxxx> wrote: > Andi, > > I wrote the following description of the core_pattern pipe feature. Does this > seem okay? > > Piping core dumps to a program > Since kernel 2.6.19, Linux supports an alternate syntax > for the /proc/sys/kernel/core_pattern file. If the first > character of this file is a pipe symbol (|), then the > remainder of the line is interpreted as a program to be > executed. Instead of being written to a disk file, the > core dump is given as standard input to the program. > Note the following points: > > * The program must be specified using an absolute path- > name (or a pathname relative to the root directory, > /), and must immediately follow the '|' character. > > * The process created to run the program runs as user > and group root. > > * Arguments can be supplied to the program, delimited by > white space (up to a total line length of 128 bytes). > > Cheers, > > Michael > > > Andi Kleen wrote: > > Michael Kerrisk wrote: > >> On Tue, Apr 15, 2008 at 11:09 PM, Michael Kerrisk > >> <mtk.manpages@xxxxxxxxxxxxxx> wrote: > >>> Hi Andi, > >>> > >>> In 2.6.19 you added the pipiing syntax > >>> (http://lwn.net/Articles/195310/) to core_pattern. Petr pointed out > >>> that this is not yet documented in core(5), so I set to testing it. > >>> > >>> The change log has the text: > >>> > >>> The core dump proces will run with the privileges and in the name space > >>> of the process that caused the core dump. > > > > My memory is fuzzy but something might have changed this afterwards > > (there were some semantics changes afterwards by other people) I think > > my original version ran as non root. > > > > Anyways the reference as usual is the code, not the change log. > > > >>> This appears not to be true (as tested on 2.6.25-rc8). Instead the > >>> pipe program is run as root. I'm not sure what "in the name space of > >>> the process that caused the core dump" means > > > > namespace is a concept from plan9. It basically means the tree > > of mounts the current process has access to. On 99+% of the systems > > that is only a single global tree, but there is support for processes > > creating their own name space using clone CLONE_NEWNS and then > > mount/umount/mount --bind etc. Linux VFS had this support for > > some time. > > > > The whole thing is very obscure but perhaps some more > > coverage in the man pages would be not bad. It seems to move > > slowly out of obscurity now with all the new container work. > > > > There is some scattered information in Documentation/*. You'll need > > someone else to explain you all the finer details though. > > > > Also there are lots of different mounts now since a few 2.6 kernels -- > > to be honest I don't understand what they are all good for. > > > > > > -- I wondered if it might > >>> mean that the current working directory of the program would be the > >>> same as that of the process that caused the core dump. However that > >>> is not so: the current directory for the pipe program is the root > >>> directory. > > > > Basically with a different namespace the paths can change completely, > > which can in theory have some unpleasant effects on the core dumper > > script. I skimped this by just always using the same as the process. > > > > -Andi > > > > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Want to report a man-pages bug? Look here: > http://www.kernel.org/doc/man-pages/reporting_bugs.html > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
