Messages in this thread | | | From | "michael mortensen" <> | Subject | Sv: /proc/sys/kernel/corename | Date | Wed, 23 Dec 1998 21:02:28 +0100 |
| |
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/
| |