Is /proc there (from Perl on BSD)

[Ilya Zakharevich]

How to check that /proc is working on BSD? And check it from Perl?
On Linux and Solaris,

-d "/proc/$$"

is TRUE. Apparently (by indirect guesses from output on CPANtesters),
this does not work on 3 BSD test machines (Open-, Free- and Net-).
Neither does

perl -wle 'open PR, qq(/proc/$$/cmdline) or die $!'

on the only BSD machine I can login into (FreeBSD 7.3).

According to WikiPedia, /proc should be available. According to
FreeBSD manpages, the file /proc/$$/cmdline should be available.

How should I interpret this? Is /proc "very optional", and disabled
by default?

Thanks,
Ilya

P.S. Why do I need to know? Since gdb command set (is documented to)
depends on the fact...

 

[Ilya Zakharevich]

Well, the obvious answer is to check the output of `/sbin/mount` for

procfs on /proc

I'd hate to do it "in real life" due to it being in unknown-in-advance
directory. "In testing", it is not there on FreeBSD machine...

A decent compromise might be to compare st_dev on a stat of "/" and
"/proc".

Are you sure it is going to work when / is unionfs etc?

Here (FreeBSD 8.1) that is *always* true. The directory /proc exists
even if procfs isn't mounted on it. (I'm pretty certain this is true of
at least Linux, as well.) You can, however, check

-d "/proc/$$".

I hope one notices that two discussed tests are identical. ;-)

But anyway, it looks like -d "/proc/$$" works fine on FreeBSD machine
without procfs mounted... (In the sense that it detects availability
of procfs on /proc.) Basically, it means that the current state of

ilyaz.org/software/tmp/auto-debug-module-0.02.zip

is as good as one can expect from 0.02 release... I will make a more
formal announcement ASAP. (Currently tested with
Audio-FindChunks-1.04.tar.gz where I found a bug long ago, but use it
as a testbed for auto-debug-module.)

That's...weird. (Unless that machine doesn't have procfs mounted, of
course.)

It is not mounted indeed.

Yes. It's also vaguely deprecated, though as you say a number of things
still depend on it, so I'm not really sure what that means. AIUI the
supported alternative for new programs is the sysctl interface, but the
whole situation is still rather unsatisfactory.

I tried to find the proof in the pudding:

gdb `which perl`
gdb> b main
gdb> r
gdb> info proc mapping

and it does not work on machine which has procfs disabled. I could
not find pmap either (anyway, I did not manage to find how to access
the PID of the child process from gdb command line, so I would not be
able to call `!pmap $childpid' or somesuch anyway...).

What a mess!

Thanks,
Ilya