[lkml]   [2008]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectcore_pattern pipe documentation

    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).



    Andi Kleen wrote:
    > Michael Kerrisk wrote:
    >> On Tue, Apr 15, 2008 at 11:09 PM, Michael Kerrisk
    >> <> wrote:
    >>> Hi Andi,
    >>> In 2.6.19 you added the pipiing syntax
    >>> ( 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;
    Want to report a man-pages bug? Look here:

     \ /
      Last update: 2008-04-18 17:43    [W:0.061 / U:61.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site