initialize all signals to SIG_DFL

[William Ahern]

is there a way to initialize all signals to SIG_DFL? the only way i can
think of is to loop thru all possible signals and install the SIG_DFL
handler, but how do i get a list of *all* signals (portably)?

also, for good measure, is there a way to close all file descriptors on
execve() (such as a trick to globally set close-on-exec for all current
descriptors)?

fwiw, i'm creating a popenl() function, like popen() but w/ execl
semantics. and so while i'm at it i'd like to add some useful features.

tia,

Bill

[William Ahern]

Paul Pluzhnikov <ppluzhnikov@earthlink.net> wrote:

> William Ahern <william@wilbur.25thandClement.com> writes:
>

>> but how do i get a list of *all* signals (portably)?

>
> You don't need to. Just do it:
>
> for (i = 1; i < 2048; i++)
> signal(i, SIG_DFL);
>

>> also, for good measure, is there a way to close all file descriptors on
>> execve()

>
> Sure. Same as above ...

well, obviously ;) however, i was hoping that there were some other tricks
of the trade (i read about F_CLOSEM fcntl() flag somewhere). toying around
in Linux i remembered that /dev/fd lists all the open descriptors (including
sockets, i hope). openbsd also has a /dev/fd, altho it lists all integers up
to the max open limit (which puts us back to using getdtablesize() or
getrlimit(), but not any worse). so maybe it's reasonable to assume that if
opendir("/dev/fd") succeeds then its safe to read the descriptors from it,
otherwise fall back to getdtablesize().

- Bill

[Casper H.S. Dik]

William Ahern <william@wilbur.25thandClement.com> writes:

>well, obviously ;) however, i was hoping that there were some other tricks
>of the trade (i read about F_CLOSEM fcntl() flag somewhere). toying around
>in Linux i remembered that /dev/fd lists all the open descriptors (including
>sockets, i hope). openbsd also has a /dev/fd, altho it lists all integers up
>to the max open limit (which puts us back to using getdtablesize() or
>getrlimit(), but not any worse). so maybe it's reasonable to assume that if
>opendir("/dev/fd") succeeds then its safe to read the descriptors from it,
>otherwise fall back to getdtablesize().

Solaris has /dev/fd but it may have too many entries; /proc/self/fd
is actually better (has the exact list of fds in use).

Solaris 9 and later have "closefrom()" which does what you want.

[url]http://docs.sun.com/db/doc/816-0213/6m6ne37rj?q=%22linkers%22&a=view[/url]

--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[Casper H.S. Dik]

Marc Rochkind <rochkind@basepath.com> writes:

>There are only a few (around 28, if memory serves me) portable signals, so
>those are the ones to set. There are more realtime signals, so make sure
>you check the appropriate feature-test macros for them, and set them, too,
>if they're there.

If you can assume that signals are complete, then this might work:

for (sig = sysconf(_SC_SIGRT_MAX); sig > 0; sig--)
signal(sig, SIG_DFL);

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[William Ahern]

Casper H.S. Dik <Casper.Dik@sun.com> wrote:

> Richard Kettlewell <invalid@invalid.invalid> writes:
>

>>The question is how to establish an upper bound on open file
>>descriptors (preferrably a better one than INT_MAX).

>
> If you don't have /dev/fd or /proc/self/fd that's going to be really
> hard.
>
> getrlimit() will tell you what the highest *currently* allowed fd is;
> but open fds might have higher numbers.

Other people have suggested in the past that one could use dup2() to get a
descriptor higher than .rlim_cur or .rlim_max. However, FWIW, on OpenBSD 3.3
and on Linux-2.4.20 (glibc 2.3.1) this doesn't seem to work.

This would fail:

fd = dup2(STDIN_FILENO,getdtablesize());

While this would work:

fd = dup2(STDIN_FILENO,getdtablesize()-1);

Would this behavior be fairly consistent across most implementations?

- Bill

[Casper H.S. Dik]

William Ahern <william@wilbur.25thandClement.com> writes:

>Other people have suggested in the past that one could use dup2() to get a
>descriptor higher than .rlim_cur or .rlim_max. However, FWIW, on OpenBSD 3.3
>and on Linux-2.4.20 (glibc 2.3.1) this doesn't seem to work.

>This would fail:

> fd = dup2(STDIN_FILENO,getdtablesize());

>While this would work:

> fd = dup2(STDIN_FILENO,getdtablesize()-1);

>Would this behavior be fairly consistent across most implementations?

I'd say that an OS in which the first statement doesn't fail
is broken. But you can always lower the limit after the first
one.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[Geoff Clare]

Michael Kerrisk <michael.kerrisk@freenet.de> writes:

> many, though not all implementetations define the
>constant NSIG (not standardised in SUSv3) as the maximum signal
>number.

NSIG is not only "not standardised in SUSv3", it's forbidden by SUSv3,
since it is not in the namespace reserved for the implementation.
(The same applies for SUSv2, SUSv1 and XPG4, but it was allowed by
XPG3 and required by XPG2).

Modern systems that define it only do so for non-standards-compliant
compilation environments.

Also, it is usually the maximum signal number *plus one*.

--
Geoff Clare <nospam@gclare.org.uk>