Robert Watson wrote:
> The main missing feature right now, from my perspective, is signal
> information, but are there other pieces of detailed process information we
> could usefully be displaying? I'm not sure I want to get into teaching
> procinfo about generating stack traces, which is some
On Sun, 18 Nov 2007, Skip Ford wrote:
1) procstat_args() doesn't use a local variable and the buffer doesn't
get cleared between calls:
$ procstat -a 797
PID ARGS
797 audacious
$ procstat -a 795 797
PID ARGS
795 xterm -xtsessionID 11c0a801030001185368263000768
797 audacious essionID 11
Robert Watson wrote:
> On Sun, 18 Nov 2007, Skip Ford wrote:
>>
>>As for the procstat(1) code itself, I've found one bug and have two
>>sugestions:
>>
>>1) procstat_args() doesn't use a local variable and the buffer doesn't
>>get cleared between calls:
>>
>>$ procstat -a 797
>> PID ARGS
>> 797 au
On Sun, 18 Nov 2007, Skip Ford wrote:
Thomas Hurst wrote:
* Skip Ford ([EMAIL PROTECTED]) wrote:
It would be interesting to know for sure, though, if Solaris uses
hardlinks and, if so, what their utility is called.
Nope. They *do* use hardlinks in that they have 32bit wrappers in /usr/bin
Thomas Hurst wrote:
> * Skip Ford ([EMAIL PROTECTED]) wrote:
>
> > It would be interesting to know for sure, though, if Solaris uses
> > hardlinks and, if so, what their utility is called.
>
> Nope. They *do* use hardlinks in that they have 32bit wrappers in
> /usr/bin etc which dispatch to the
* Skip Ford ([EMAIL PROTECTED]) wrote:
> It would be interesting to know for sure, though, if Solaris uses
> hardlinks and, if so, what their utility is called.
Nope. They *do* use hardlinks in that they have 32bit wrappers in
/usr/bin etc which dispatch to the relevent architecture, but the
com
Bjoern A. Zeeb wrote:
> On Fri, 16 Nov 2007, Skip Ford wrote:
>
> >How about renaming procstat(1) to proc(1), rolling up all of
>
> calling it proc(1), I think, is actually not a good idea either. That
> is way more confusing for people who still think about /proc and do
> not know the difference
On Fri, 16 Nov 2007, Skip Ford wrote:
Hi,
How about renaming procstat(1) to proc(1), rolling up all of
calling it proc(1), I think, is actually not a good idea either. That
is way more confusing for people who still think about /proc and do
not know the difference between (1) or (4).
I like
Robert Watson wrote:
> On Wed, 14 Nov 2007, Skip Ford wrote:
>
>>>I agree regarding the duplication with ps(1) -- however, I'm generally of
>>>the opinion that ps(1) is overburdened as tools go, and that the goals
>>>are actually somehwat different--procstat(1) intentionally doesn't have
>>>the
Robert Watson wrote:
> On Wed, 14 Nov 2007, Skip Ford wrote:
>
>>>I agree regarding the duplication with ps(1) -- however, I'm generally of
>>>the opinion that ps(1) is overburdened as tools go, and that the goals
>>>are actually somehwat different--procstat(1) intentionally doesn't have
>>>the
On Wed, 14 Nov 2007, Skip Ford wrote:
I agree regarding the duplication with ps(1) -- however, I'm generally of
the opinion that ps(1) is overburdened as tools go, and that the goals are
actually somehwat different--procstat(1) intentionally doesn't have the
ability to generate a list of proc
Robert Watson wrote:
> On Wed, 14 Nov 2007, Skip Ford wrote:
> >Robert Watson wrote:
> >>On Tue, 13 Nov 2007, Yuri wrote:
> >>
> >>>Thank you for letting me know about this new feature procstat.
> >>>
> >>>But is there any workaround in 6.3? I need to port one package that
> >>>needs to lookup fil
On Wed, 14 Nov 2007, Skip Ford wrote:
Robert Watson wrote:
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs
to lookup file names by FDs to the current FreeBSD and need s
On Wednesday 14 November 2007, Robert Watson wrote:
> On Tue, 13 Nov 2007, Yuri wrote:
> > Thank you for letting me know about this new feature procstat.
> >
> > But is there any workaround in 6.3? I need to port one package that
> > needs to lookup file names by FDs to the current FreeBSD and need
Robert Watson wrote:
> On Tue, 13 Nov 2007, Yuri wrote:
>
> >Thank you for letting me know about this new feature procstat.
> >
> >But is there any workaround in 6.3? I need to port one package that needs
> >to lookup file names by FDs to the current FreeBSD and need some solution
> >now.
>
> I
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs to
lookup file names by FDs to the current FreeBSD and need some solution now.
If the port uses a script to extract the da
Yuri <[EMAIL PROTECTED]> writes:
> But is there any workaround in 6.3? I need to port one package that
> needs to lookup file names by FDs to the current FreeBSD and need some
> solution now.
You can not reliably obtain a file name from a file descriptor. The
best you can hope for is to find a fi
Robert,
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs to
lookup file names by FDs to the current FreeBSD and need some solution now.
Yuri
Quoting Robert Watson <[EMAIL PROTECTED]>:
>
> On Mon, 12 Nov 2
On Mon, Nov 12, 2007 at 11:33:38AM -0800, Yuri wrote:
>I am looking for functionality similar to Linux's /proc//fd/.
>I need to know what is the file name of an open file descriptor.
Note that there is not necessarily a unique (or any) filename
associated with a file descriptor. This is an inhere
On Mon, 12 Nov 2007, Yuri wrote:
Y> I looked at the patch. It retrieves file description information through
Y> 'sysctl' calls with proprietary keys.
Y>
Y> Isn't it better architecturally to expose the same information through procfs
Y> interface? At least from the filesystem level and up standar
On Mon, 12 Nov 2007, Yuri wrote:
I looked at the patch. It retrieves file description information through
'sysctl' calls with proprietary keys.
Isn't it better architecturally to expose the same information through
procfs interface? At least from the filesystem level and up standard tools
l
On Mon, 12 Nov 2007, Yuri wrote:
Thank you for your response.
I attempted to compile procstat but procstat.h seems to be missing in tgz.
Yuri,
Indeed -- looks like I forgot to p4 add on my development box. I've updated
the tarball to now include procstat.h. If there are any other problem
I looked at the patch. It retrieves file description information through
'sysctl' calls with proprietary keys.
Isn't it better architecturally to expose the same information through procfs
interface? At least from the filesystem level and up standard tools like ls/cat
will be able to show the the
On Mon, 12 Nov 2007, Yuri wrote:
I am looking for functionality similar to Linux's /proc//fd/. I
need to know what is the file name of an open file descriptor.
/proc//fd is missing on FreeBSD.
There's something called 'fdescfs'. In /dev/fd/ it shows the list of file
descriptors. But they don
Robert,
Thank you for your response.
I attempted to compile procstat but procstat.h seems to be missing in tgz.
Yuri
Quoting Robert Watson <[EMAIL PROTECTED]>:
> On Mon, 12 Nov 2007, Yuri wrote:
>
> > I am looking for functionality similar to Linux's /proc//fd/. I
> > need to know what is th
I am looking for functionality similar to Linux's /proc//fd/.
I need to know what is the file name of an open file descriptor.
/proc//fd is missing on FreeBSD.
There's something called 'fdescfs'. In /dev/fd/ it shows the list of file
descriptors. But they don't seem to be symbolic links to open f
26 matches
Mail list logo
