lkml.org 
[lkml]   [1998]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectSv: /proc/sys/kernel/corename
Date
dont vrite me anymore pleace
-----Oprindelig meddelelse-----
Fra: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Til: Kenneth Albanowski <kjahds@kjahds.com>
Cc: simius@algonet.se <simius@algonet.se>; linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>
Dato: 23. december 1998 20:06
Emne: Re: /proc/sys/kernel/corename


>Good idea, but which terminal are you going to run the debugger on,
>if the process did not have a ctty in the first place?
>Even if it had one it is better to not touch it as it may be in
>insane (anything other than canonical) state.
>
>Perhaps one could choose a spare vc (like X does when it starts up)
>and start gdb there?
>
>Regards,
>Tigran A. Aivazian, http://www.aivazian.demon.co.uk/
>
>On Tue, 22 Dec 1998, Kenneth Albanowski wrote:
>
>> On Tue, 22 Dec 1998 simius@algonet.se wrote:
>>
>> > I'm working on a "/proc/sys/kernel/corename" used to change
>> > the filename of a coredump. Ie. you echo something to the above
>> > file and thats what the corefile will be called.
>> > This has been discussed in an earlier thread and the idea to
>> > use %<whatever> came up, for example %p would expand to the coredumping
>> > process pid. I am also trying to conform to the codes used by /bin/ps.
>> >
>> > My problem is how to get the values for certain of these codes, if
>> > anyone has any suggestions of an easy way to get the bellow values
>> > while in elf_core_dump() (in linux/fs/binfmt_elf.c).
>> > I have been using the values in "task_struct *current" extensively
>> > so its possible that some (all?) of these values can be found in there.
>> > If so, please point me in the right direction.
>> >
>> > Problem values:
>> >
>> > coredumping processes: args,elapsed time
>> > user owning the coredumping processes: username,groupname,tty
>>
>> I would be astonished if any names (user, group, or tty) were available
>> within the kernel. (Tty names would probably be available in a devfs
>> environment, though.) uids and gids, yes.
>>
>> This core discussion, and your mention of names, leads me to think of a
>> completely different solution: a user-space daemon that can perform "Just
>> in time debugging", as NT refers to it: connecting up to an application
>> that has crashed. The obvious default is a core dump, but it should also
>> be possible to hook a real debugger up. Once user-space code is performing
>> the dump (or at least responsible for triggering the dump), gaining access
>> to usernames and suchlike is trivial.
>>
>> I'm not sure whether it would be feasible to rewrite the core dumping as a
>> user-space operation, or just give the daemon the ability to trigger a
>> dump with a specified name. The debugger connection facility (along with
>> the rest of this, I suppose) probably belongs in the ptrace system.
>>
>> --
>> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.rutgers.edu
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>Please read the FAQ at http://www.tux.org/lkml/
>


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

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.312 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site