This is still not a very good way to control the names.
What I have is a cluster of nearly 100 machines - all but one of them have
no disk. When something goes down on one of the machines, I would like to
know (a) what it was that went down and (b) which machine it was on.
I would also like to have the core files someplace that is writable (all
but the /coredumps directory is read-only - oh, and the local tmpfs mounts
for /var and /etc)
> >And having process names is nicer than having PIDs - I don't mind if my core
> >files are over-written on subsequent runs, actually it's nice (keeps the disks
> >from filling up).
>
> They can get long and annoying... They are not suitable for short name
> filesystems... They provide a good
> hint for deliberate overwrites.... and so on. Basically I think this
> would be too much of the good.
I was very carefull to keep that behavior consistant with 2.4.17. That
is, if you do nothing different with the kernel.core_name_format then it
will work just as before. And only root can change that sysctl.
As to "overwrites" and the like, I have much less overwrites with most
any pattern form than with just plain "core" And I can support features
that many people have wanted (%N.core being a very popular construct).
-- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. - 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/