Hi! I a need to setup a weird configuration of syslog-ng and I don't know how to do it. Please help me!!! So, here is my problem. I have 2 programs, say A and B. I have metalog configure so that program A write logs a file called log_A, and program B write logs to log_B. This is the easy part. Now the real problem. I have a kernel module K that is used by both programs that also write some logs. I want that the logs written by kernel module K when used by program A go to log_A file. The same with program B, logs should go log_B. How can I do this? TIA. Regards, Julio -- ------------------------ Julio Kriger mailto:julio@cwazy.co.uk
On Tue, 03 May 2005 16:36:16 -0300, Julio Kriger said:
I want that the logs written by kernel module K when used by program A go to log_A file. The same with program B, logs should go log_B.
Does the kernel module indicate in any way which program it was? In other words, given the output from K *by itself*, is there a way to tell if A or B was using it? If so, you should be able to use 'match' to sort things out...
No, there are no ways that the kernel module (it's sctp) know from with program is was called. Not that I know :) On Tue, May 3, 2005 5:05 pm, Valdis.Kletnieks@vt.edu said:
On Tue, 03 May 2005 16:36:16 -0300, Julio Kriger said:
I want that the logs written by kernel module K when used by program A go to log_A file. The same with program B, logs should go log_B.
Does the kernel module indicate in any way which program it was? In other words, given the output from K *by itself*, is there a way to tell if A or B was using it? If so, you should be able to use 'match' to sort things out...
-- ------------------------ Julio Kriger mailto:julio@cwazy.co.uk
On Wed, 04 May 2005 11:11:10 -0300, Julio Kriger said:
No, there are no ways that the kernel module (it's sctp) know from with program is was called. Not that I know :)
Checking the Linux 2.6.12-rc2-mm3 net/sctp source, none of the printk() calls from the module even *care* what program they were called from, and in some cases it's bottom-half code running on somebody else's context (on its own task queue or similar) so there's no actual way to associate the activity with a given program. In fact, most of the printk() calls are some variant on "This is bogus and we can't tell who it belongs to". Can you explain (a) what kernel/system you're using and (b) what sctp messages you're trying to classify, and (c) what you're trying to accomplish by doing it? (I'm suspecting the answer will be "If the sctp kernel module doesn't know, how is syslog-ng supposed to tell? But there's another approach to get the info you wanted. All you do is.....")
Yes, exactly. a) I'm using Linux Gentoo 2.6.11-rc6 (gentoo-sources if you know about gentoo) b) Any debug message, I've done some modifications and I'm testing them, I've added my own messages c) It will help understand why this modifcation I made don't work :) TIA Regards, Julio On Wed, May 4, 2005 1:50 pm, Valdis.Kletnieks@vt.edu said:
On Wed, 04 May 2005 11:11:10 -0300, Julio Kriger said:
No, there are no ways that the kernel module (it's sctp) know from with program is was called. Not that I know :)
Checking the Linux 2.6.12-rc2-mm3 net/sctp source, none of the printk() calls from the module even *care* what program they were called from, and in some cases it's bottom-half code running on somebody else's context (on its own task queue or similar) so there's no actual way to associate the activity with a given program. In fact, most of the printk() calls are some variant on "This is bogus and we can't tell who it belongs to".
Can you explain (a) what kernel/system you're using and (b) what sctp messages you're trying to classify, and (c) what you're trying to accomplish by doing it?
(I'm suspecting the answer will be "If the sctp kernel module doesn't know, how is syslog-ng supposed to tell? But there's another approach to get the info you wanted. All you do is.....")
-- ------------------------ Julio Kriger mailto:julio@cwazy.co.uk
On Wed, 04 May 2005 14:34:01 -0300, Julio Kriger said:
Yes, exactly.
a) I'm using Linux Gentoo 2.6.11-rc6 (gentoo-sources if you know about gentoo) b) Any debug message, I've done some modifications and I'm testing them, I've added my own messages c) It will help understand why this modifcation I made don't work :)
OK.. then it's actually pretty easy, sort of, for a partial solution. ;) Basically, at any given printk(), you're either running on the current-> that got you there or you're not (and if you don't know, and can't figure out how to tell, you shouldn't be playing in that code. :) So if you're in code where current-> make sense(*), just do something like: printk(KERN_DEBUG "sctp: cur=%d(%s) this=%d that=%x\n", current->pid, current->exe, thing1, thing2); and then filter in syslog-ng on the program name the %s outputs... (*) There's places where current-> is defined, just not the process you thought it was, at those places you can safely dereference current-> if you're willing to put up with odd output values. net/sctp/* shouldn't hit any cases where current-> is totally bogus - most of that code is in drivers/ and deals with the interrupt and IRQ level code).
Hi, I will try it. It sounds good!!! Thank you very much for you help. Regards, Julio On Wed, May 4, 2005 2:47 pm, Valdis.Kletnieks@vt.edu said:
On Wed, 04 May 2005 14:34:01 -0300, Julio Kriger said:
Yes, exactly.
a) I'm using Linux Gentoo 2.6.11-rc6 (gentoo-sources if you know about gentoo) b) Any debug message, I've done some modifications and I'm testing them, I've added my own messages c) It will help understand why this modifcation I made don't work :)
OK.. then it's actually pretty easy, sort of, for a partial solution. ;)
Basically, at any given printk(), you're either running on the current-> that got you there or you're not (and if you don't know, and can't figure out how to tell, you shouldn't be playing in that code. :) So if you're in code where current-> make sense(*), just do something like:
printk(KERN_DEBUG "sctp: cur=%d(%s) this=%d that=%x\n", current->pid, current->exe, thing1, thing2);
and then filter in syslog-ng on the program name the %s outputs...
(*) There's places where current-> is defined, just not the process you thought it was, at those places you can safely dereference current-> if you're willing to put up with odd output values. net/sctp/* shouldn't hit any cases where current-> is totally bogus - most of that code is in drivers/ and deals with the interrupt and IRQ level code).
-- ------------------------ Julio Kriger mailto:julio@cwazy.co.uk
On Wed, 04 May 2005 15:14:13 -0300, Julio Kriger said:
Hi, I will try it. It sounds good!!! Thank you very much for you help.
Oh, if your kernel OOPS'es on the printk(), it probably means you managed to find code where current-> doesn't point at a valid 'struct task_struct'. ;)
participants (2)
-
Julio Kriger
-
Valdis.Kletnieks＠vt.edu