lkml.org 
[lkml]   [2007]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/4] coredump: core dump masking support v3
    Kawai, Hidehiro wrote:
    > Requirements are:
    > (1) a user can change the core dump settings _anytime_
    > - sometimes want to dump anonymous shared memory segments and
    > sometimes don't want to dump them

    I might not have been sufficiently clear about this in my previous
    e-mail. Currently, the Google coredumper does not have the feature that
    you asked about, but adding it would be trivial -- it just hadn't been
    needed, yet, as on-the-fly compression was good enough for most users.

    Answering your question, I don't see any reason why the new API would
    not be able to make changes at any time.

    > (2) a user can change the core dump settings of _any processes_
    > (although permission checks are performed)
    > - in a huge application which forks many processes, a user
    > hopes that some processes dump anonymous shared memory
    > segments and some processes don't dump them

    The Google coredumper is a library that needs to be linked into the
    application and needs to be called from appropriate signal handlers. As
    such, it is the application's responsibility what management API it
    wants to expose externally, and what tools it wants to provide for
    managing a group of processes.

    > And reliability of the core dump feature is also important.

    We have generally had very good reliability with the Google coredumper.
    In some cases, it even works a little more reliably than the default
    in-kernel dumper (e.g. because we can control where to write the file,
    and whether it should be compressed on-the-fly; or because we can get
    multi-threaded coredumps even in situations where the particular
    combination of libc and kernel doesn't support this), and in other cases
    the in-kernel dumper works a little better (e.g. if an application got
    too corrupted to even run any signal handlers).

    Realistically, it just works. But we did have to make sure that we set
    up alternate stacks for signal processing, and that we made sure that
    these stacks have been dirtied in order to avoid problems with memory
    overcomitting.

    > And all the software vendors don't necessarily apply
    > google-coredumper. If the vendor doesn't apply it, the user will
    > be bothered by huge core dumps or the buggy application which
    > remains unfixed. So I believe that in kernel solution is still
    > needed.

    I agree that the Google coredumper is only one possible solution to your
    problem. Depending on how your production environment looks like, it
    might help a lot, or it might be completely useless.

    If it is cheap for you to modify your applications, but expensive to
    upgrade your kernels, the Google coredumper is the way to go. Also, if
    you need the extra features, such as the ability to compress core files
    on-the-fly, or the ability to send corefiles to somewhere other than an
    on-disk file, you definitely should look at a user-space solution. On
    the other hand, if you can easily upgrade all your kernels, but you
    don't even have access to the source of your applications, then an
    in-kernel solution is much better.


    Markus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-01 19:21    [W:0.435 / U:0.012 seconds]
    ©2003-2014 Jasper Spaans. Advertise on this site