2 Mar
2012
2 Mar
'12
4:12 a.m.
This message is from tdelibs/kinit/kinit.cpp. They appear in the xession log.
I don't mind the messages and I can see from the source code they are intended to be
debugging aids.
But they lack information. How do I add the process name to the message?
Like this:
PID 10804 (process name) terminated.
With that information the message might remain useful only for debugging, but at least the
message appears more useful and informational to users.
Darrell
2 Mar
2 Mar
2:17 p.m.
New subject: [trinity-devel] fprintf(stderr, "tdeinit: PID %ld terminated.\n", (long) exit_pid);
On Fri, Mar 2, 2012 at 8:12 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
This message is from tdelibs/kinit/kinit.cpp. They
appear in the xession log.
I don't mind the messages and I can see from the source code they are intended to be
debugging aids.
But they lack information. How do I add the process name to the message?
Like this:
PID 10804 (process name) terminated.
With that information the message might remain useful only for debugging, but at least
the message appears more useful and informational to users.
You can consult /proc/<PID>/cmdline contents.
4:39 p.m.
New subject: [trinity-devel] fprintf(stderr, "tdeinit: PID %ld terminated.\n", (long) exit_pid);
On 2 March 2012 09:17, Aleksey Midenkov <midenok(a)gmail.com> wrote:
On Fri, Mar 2, 2012 at 8:12 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Yeah this is the way to do it - but it's not portable is it?
Calvin
This message is from tdelibs/kinit/kinit.cpp.
They appear in the xession log.
I don't mind the messages and I can see from the source code they are intended to be
debugging aids.
But they lack information. How do I add the process name to the message?
Like this:
PID 10804 (process name) terminated.
With that information the message might remain useful only for debugging, but at least
the message appears more useful and informational to users.
You can consult /proc/<PID>/cmdline contents.
6:04 p.m.
New subject: [trinity-devel] fprintf(stderr, "tdeinit: PID %ld terminated.\n", (long) exit_pid);
On 2 March 2012 09:17, Aleksey Midenkov
<midenok(a)gmail.com> wrote:
Use an #ifdef for POSIX systems to enable extra information from
/proc/<PID>, and keep the original code for non-POSIX systems. This type
of code is present in a few places in tdelibs already.
Tim
On Fri, Mar 2, 2012 at 8:12 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Yeah this is the way to do it - but it's not portable is it?
Calvin This message is from tdelibs/kinit/kinit.cpp.
They appear in the
xession log.
I don't mind the messages and I can see from the source code they are
intended to be debugging aids.
But they lack information. How do I add the process name to the
message?
Like this:
PID 10804 (process name) terminated.
With that information the message might remain useful only for
debugging, but at least the message appears more useful and
informational to users.
You can consult /proc/<PID>/cmdline contents.
7:22 p.m.
New subject: [trinity-devel] fprintf(stderr, "tdeinit: PID %ld terminated.\n", (long) exit_pid);
On Fri, Mar 2, 2012 at 10:04 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
To be strict, this is not POSIX standard. Therefore such check does
not guarantee procfs presence. And vice versa: procfs presence does
not require POSIX compliance. So, I'm not sure if such check is
correct. Better look at the sources.
And, AFAIK, POSIX does not cover process table info at all. So, on
Linux this is the only way. IMHO.
On 2 March
2012 09:17, Aleksey Midenkov <midenok(a)gmail.com> wrote:
Use an #ifdef for POSIX systems to enable extra information from
/proc/<PID>, and keep the original code for non-POSIX systems. This type
of code is present in a few places in tdelibs already.
On Fri, Mar 2, 2012 at 8:12 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Yeah this is the way to do it - but it's not portable is it?
Calvin This message is from tdelibs/kinit/kinit.cpp.
They appear in the
xession log.
I don't mind the messages and I can see from the source code they are
intended to be debugging aids.
But they lack information. How do I add the process name to the
message?
Like this:
PID 10804 (process name) terminated.
With that information the message might remain useful only for
debugging, but at least the message appears more useful and
informational to users.
You can consult /proc/<PID>/cmdline contents.
7:28 p.m.
New subject: [trinity-devel] fprintf(stderr, "tdeinit: PID %ld terminated.\n", (long) exit_pid);
On Fri, Mar 2, 2012 at 10:04 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
To be strict, this is not POSIX standard. Therefore such check does
not guarantee procfs presence. And vice versa: procfs presence does
not require POSIX compliance. So, I'm not sure if such check is
correct. Better look at the sources.
And, AFAIK, POSIX does not cover process table info at all. So, on
Linux this is the only way. IMHO.
Correct, I was typing too fast and wrote the wrong thing; my apologies.
As far as I can tell no other mainstream POSIX-compliant system provides
/proc/<PID> (http://en.wikipedia.org/wiki/Procfs) There is some other
unguarded TDE code that will probably fail to function on FreeBSD and
other non-Linux systems; this code should be found (e.g. via grep) and
guarded.
I know a prototype guard check for Linux is present in at least one of the
kioslaves, as I have seen it before...
Tim
On 2
March 2012 09:17, Aleksey Midenkov <midenok(a)gmail.com> wrote:
Use an #ifdef for POSIX systems to enable extra information from
/proc/<PID>, and keep the original code for non-POSIX systems. This
type
of code is present in a few places in tdelibs already.
On Fri, Mar 2, 2012 at 8:12 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
> This message is from tdelibs/kinit/kinit.cpp. They appear in the
> xession log.
>
> I don't mind the messages and I can see from the source code they are
> intended to be debugging aids.
>
> But they lack information. How do I add the process name to the
> message?
>
> Like this:
>
> PID 10804 (process name) terminated.
>
> With that information the message might remain useful only for
> debugging, but at least the message appears more useful and
> informational to users.
>
You can consult /proc/<PID>/cmdline contents.
Yeah this is the way to do it - but it's not portable is it?
Calvin
7:52 p.m.
New subject: [trinity-devel] fprintf(stderr, "tdeinit: PID %ld terminated.\n", (long) exit_pid);
On Fri, Mar 2, 2012 at 11:28 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
And reading from /proc of course should be non-fatal where it is not
critical. I've just checked ps under chroot where proc is not mounted.
It says:
Cannot find /proc/version - is /proc mounted?
This is the way of checking it.
On Fri, Mar 2,
2012 at 10:04 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
To be strict, this is not POSIX standard. Therefore such check does
not guarantee procfs presence. And vice versa: procfs presence does
not require POSIX compliance. So, I'm not sure if such check is
correct. Better look at the sources.
And, AFAIK, POSIX does not cover process table info at all. So, on
Linux this is the only way. IMHO.
Correct, I was typing too fast and wrote the wrong thing; my apologies.
As far as I can tell no other mainstream POSIX-compliant system provides
/proc/<PID> (http://en.wikipedia.org/wiki/Procfs) There is some other
unguarded TDE code that will probably fail to function on FreeBSD and
other non-Linux systems; this code should be found (e.g. via grep) and
guarded.
I know a prototype guard check for Linux is present in at least one of the
kioslaves, as I have seen it before... On 2
March 2012 09:17, Aleksey Midenkov <midenok(a)gmail.com> wrote:
> On Fri, Mar 2, 2012 at 8:12 AM, Darrell Anderson
> <humanreadable(a)yahoo.com> wrote:
>> This message is from tdelibs/kinit/kinit.cpp. They appear in the
>> xession log.
>>
>> I don't mind the messages and I can see from the source code they are
>> intended to be debugging aids.
>>
>> But they lack information. How do I add the process name to the
>> message?
>>
>> Like this:
>>
>> PID 10804 (process name) terminated.
>>
>> With that information the message might remain useful only for
>> debugging, but at least the message appears more useful and
>> informational to users.
>>
>
> You can consult /proc/<PID>/cmdline contents.
>
Yeah this is the way to do it - but it's not portable is it?
Calvin
Use an #ifdef for POSIX systems to enable extra information from
/proc/<PID>, and keep the original code for non-POSIX systems. This
type
of code is present in a few places in tdelibs already.
4448
days inactive
4448
days old
6 comments
4 participants
participants (4)
-
Aleksey Midenkov -
Calvin Morrison -
Darrell Anderson -
Timothy Pearson