 |
|
|
|
Next: Kgdb patch for redhat 9.0 kernel 2.4.20-8
|
| Author |
Message |
External
Since: Sep 03, 2003
Posts: 64
|
(Msg. 1) Posted: Tue Apr 13, 2004 11:44 am
Post subject: Signal information in /proc//status?
Archived from groups: comp>os>linux>development>system (more info?)
|
|
|
Hi,
what is the meaning of SigPnd, SigBlk and the other fields in
/proc/<pid>/status on Linux 2.4.x?
For example,
# cat /proc/6063/status
[snipped]
SigPnd: 0000000000000000
SigBlk: 0000000080001000
SigIgn: 8000000000000000
SigCgt: 0000000380010e48
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
So, what is the meaning of SigPnd, SigBlk, SigIgn, SigCgt, CapInh, CapPrm
and CapEff and how do I interpret these bitmasks? The first few fields
(VmSize etc.) are described in the documentation coming with the kernel
source, but it does not mention the ones I am interested in.
Thanks in advance, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!! |
|
| Back to top |
|
 | |
External
Since: Jul 15, 2003
Posts: 2364
|
(Msg. 2) Posted: Tue Apr 13, 2004 7:17 pm
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Dragan Cvetkovic wrote:
>
> SigPnd: 0000000000000000
> SigBlk: 0000000080001000
> SigIgn: 8000000000000000
> SigCgt: 0000000380010e48
Must be pending, blocked, ignored, and caught signals.
The blocked signals are those the process is not
currently ready to receive. If any of those arrives
it will be pending until it is unblocked at which
point the handler can be called.
A signal being ignored just means that it isn't going
to kill the process like it would otherwise have done.
Finally there are the caught signals, which means the
process have installed a handler for those.
> CapInh: 0000000000000000
> CapPrm: 00000000fffffeff
> CapEff: 00000000fffffeff
Those are inheritable, permitted, and effective
capabilities. I don't know exactly how to use those
bitmasks. But the idea is, that root permissions isn't
actually all or nothing. It is split into a number of
different capabilities that can in principle be given
individually.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */ |
|
| Back to top |
|
| |
External
Since: Sep 03, 2003
Posts: 64
|
(Msg. 3) Posted: Tue Apr 13, 2004 7:18 pm
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Kasper Dupont writes:
> Dragan Cvetkovic wrote:
>>
>> SigPnd: 0000000000000000
>> SigBlk: 0000000080001000
>> SigIgn: 8000000000000000
>> SigCgt: 0000000380010e48
>
> Must be pending, blocked, ignored, and caught signals.
> The blocked signals are those the process is not
> currently ready to receive. If any of those arrives
> it will be pending until it is unblocked at which
> point the handler can be called.
Thanks Kasper, I know what pending, blocked, ignored, and caught signals
conceptually are, I just need the way to know what e.g. signals are blocked
here i.e. what does mask 0000000380010e48 mean. Do I use sigismember(3)
type of functions or is there some other way?
Thanks and bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!! |
|
| Back to top |
|
| |
External
Since: Sep 03, 2003
Posts: 64
|
(Msg. 4) Posted: Tue Apr 13, 2004 7:18 pm
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Kasper Dupont writes:
> Dragan Cvetkovic wrote:
>>
>> Thanks Kasper, I know what pending, blocked, ignored, and caught signals
>> conceptually are, I just need the way to know what e.g. signals are blocked
>> here i.e. what does mask 0000000380010e48 mean. Do I use sigismember(3)
>> type of functions or is there some other way?
>
> The strings are generated by render_sigset_t() in
> kernel/sched.c, which looks like this:
>
> char * render_sigset_t(sigset_t *set, char *buffer)
[snip]
> So, no you don't need to use sigismember as that
> have already been done for you. What you need to
> do is just compute the corespondance between
> signal numbers and bit positions like the above
> function does.
Great, thanks Kasper.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!! |
|
| Back to top |
|
| |
External
Since: Jul 15, 2003
Posts: 2364
|
(Msg. 5) Posted: Tue Apr 13, 2004 9:20 pm
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Dragan Cvetkovic wrote:
>
> Thanks Kasper, I know what pending, blocked, ignored, and caught signals
> conceptually are, I just need the way to know what e.g. signals are blocked
> here i.e. what does mask 0000000380010e48 mean. Do I use sigismember(3)
> type of functions or is there some other way?
The strings are generated by render_sigset_t() in
kernel/sched.c, which looks like this:
char * render_sigset_t(sigset_t *set, char *buffer)
{
int i = _NSIG, x;
do {
i -= 4, x = 0;
if (sigismember(set, i+1)) x |= 1;
if (sigismember(set, i+2)) x |= 2;
if (sigismember(set, i+3)) x |= 4;
if (sigismember(set, i+4)) x |= 8;
*buffer++ = (x < 10 ? '0' : 'a' - 10) + x;
} while (i >= 4);
*buffer = 0;
return buffer;
}
So, no you don't need to use sigismember as that
have already been done for you. What you need to
do is just compute the corespondance between
signal numbers and bit positions like the above
function does.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */ |
|
| Back to top |
|
| |
External
Since: Feb 11, 2004
Posts: 69
|
(Msg. 6) Posted: Wed Apr 14, 2004 5:42 am
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Tue, 13 Apr 2004 19:17:59 +0200, Kasper Dupont
wrote:
>Dragan Cvetkovic wrote:
>>
>> SigPnd: 0000000000000000
>> SigBlk: 0000000080001000
>> SigIgn: 8000000000000000
>> SigCgt: 0000000380010e48
>
>Must be pending, blocked, ignored, and caught signals.
>The blocked signals are those the process is not
>currently ready to receive. If any of those arrives
>it will be pending until it is unblocked at which
>point the handler can be called.
>
>A signal being ignored just means that it isn't going
>to kill the process like it would otherwise have done.
>Finally there are the caught signals, which means the
>process have installed a handler for those.
>
>> CapInh: 0000000000000000
>> CapPrm: 00000000fffffeff
>> CapEff: 00000000fffffeff
>
>Those are inheritable, permitted, and effective
>capabilities. I don't know exactly how to use those
>bitmasks. But the idea is, that root permissions isn't
>actually all or nothing. It is split into a number of
>different capabilities that can in principle be given
>individually.
Kasper seems to have covered the signal masks pretty well. As far as
the capability sets are concerned, the bit mask definitions are
defined in include/linux/capability.h, and it's just a matter of doing
suitable bit-mask arithmetic -- or were you in serarch of other
information about these fields?
Cheers,
Michael |
|
| Back to top |
|
| |
External
Since: Sep 03, 2003
Posts: 64
|
(Msg. 7) Posted: Wed Apr 14, 2004 9:59 am
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Michael Kerrisk writes:
> On Tue, 13 Apr 2004 19:17:59 +0200, Kasper Dupont
> wrote:
>
>>Dragan Cvetkovic wrote:
>>
>>> CapInh: 0000000000000000
>>> CapPrm: 00000000fffffeff
>>> CapEff: 00000000fffffeff
>>
>>Those are inheritable, permitted, and effective
>>capabilities. I don't know exactly how to use those
>>bitmasks. But the idea is, that root permissions isn't
>>actually all or nothing. It is split into a number of
>>different capabilities that can in principle be given
>>individually.
>
> Kasper seems to have covered the signal masks pretty well. As far as
> the capability sets are concerned, the bit mask definitions are
> defined in include/linux/capability.h, and it's just a matter of doing
> suitable bit-mask arithmetic -- or were you in serarch of other
> information about these fields?
Thanks Michael. I was more in search about signal informations, but knowing
that the last 3 fields are capability related is a nice bonus 
Thanks for the include/linux/capability.h tip, very useful
information. When were capabilities introduced into Linux?
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!! |
|
| Back to top |
|
| |
External
Since: Feb 11, 2004
Posts: 69
|
(Msg. 8) Posted: Fri Apr 16, 2004 7:07 am
Post subject: Re: Signal information in /proc//status? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Wed, 14 Apr 2004 09:59:31 -0400, Dragan Cvetkovic
wrote:
>Michael Kerrisk writes:
>
>> On Tue, 13 Apr 2004 19:17:59 +0200, Kasper Dupont
>> wrote:
>>
>>>Dragan Cvetkovic wrote:
>>>
>>>> CapInh: 0000000000000000
>>>> CapPrm: 00000000fffffeff
>>>> CapEff: 00000000fffffeff
>>>
>>>Those are inheritable, permitted, and effective
>>>capabilities. I don't know exactly how to use those
>>>bitmasks. But the idea is, that root permissions isn't
>>>actually all or nothing. It is split into a number of
>>>different capabilities that can in principle be given
>>>individually.
>>
>> Kasper seems to have covered the signal masks pretty well. As far as
>> the capability sets are concerned, the bit mask definitions are
>> defined in include/linux/capability.h, and it's just a matter of doing
>> suitable bit-mask arithmetic -- or were you in serarch of other
>> information about these fields?
>
>Thanks Michael. I was more in search about signal informations, but knowing
>that the last 3 fields are capability related is a nice bonus
>
>Thanks for the include/linux/capability.h tip, very useful
>information. When were capabilities introduced into Linux?
Hi Dragan,
With Linux 2.2.
Cheers,
Michael |
|
| Back to top |
|
| |
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
|
|
|
FAQ
Search
Profile
Private Messages
Log in
