Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problemette compiling new pcnfsd

0 views
Skip to first unread message

Neil Todd

unread,
Jul 31, 1991, 3:44:02 AM7/31/91
to
Trying to compile the new PC-NFSD on my SVR4 machine, I get the following
error regarding undefined symbols:-

cc -g -DSVR4 -DSHADOW_SUPPORT -c pcnfsd_misc.c
"./common.h", line 142: warning: macro replacement within a string literal
"pcnfsd_misc.c", line 325: undefined symbol: SA_INTERRUPT
*** Error code 1 (bu21)

make: fatal error.

I've looked in my third edition SVID and can find no mention of
SA_INTERRUPT, have I missed something here, or should I complain to my
friendly vendor ?

Neil

--
Neil Todd | ..In general, it is best to assume that the
PSI%234237100122::neil | network is filled with malevolent entities
n...@pio.gid.co.uk | that will send in packets designed to have
GID Ltd | the worst possible effect...

Geoff Arnold @ Sun BOS - R.H. coast near the top

unread,
Jul 31, 1991, 8:15:47 AM7/31/91
to
I've xposted this to comp.unix.programmer.

Quoth ne...@pio.gid.co.uk (Neil Todd) (in <1...@dsbc.icl.co.uk>):
#Trying to compile the new PC-NFSD on my SVR4 machine, I get the following
#error regarding undefined symbols:-
#
# cc -g -DSVR4 -DSHADOW_SUPPORT -c pcnfsd_misc.c
#"./common.h", line 142: warning: macro replacement within a string literal
#"pcnfsd_misc.c", line 325: undefined symbol: SA_INTERRUPT
#*** Error code 1 (bu21)
#
#make: fatal error.
#
#I've looked in my third edition SVID and can find no mention of
#SA_INTERRUPT, have I missed something here, or should I complain to my
#friendly vendor ?

Friendly vendor here... :-) I *DID* warn you in the preamble that
I hadn't had an opportunity to check out that stuff under SVR4. Anyway...

The SA_INTERRUPT code was lifted straight out of the AnswerBook
(DocuBox begone!!). After I saw your posting I grepped around
/usr/include/sys on SunOS for SA_INTERRUPT and found the following:

bodleian:geoff:79 %egrep SA_INTER /usr/include/sys/*.h
/usr/include/sys/signal.h:#define SA_INTERRUPT SV_INTERRUPT

Unfortunately, this doesn't seem to help matters. The SVR4 sys/signal.h
is silent on this, as is the XPG. Can anyone help? How do I achieve
the effect of SA_INTERRUPT under SVR4?

THe scenario is as follows: I'm popen()ing a process to do some
work for me, but I want to ensure that it doesn't run forever.
Therefore in the parent process I want to set a watchdog timer
that will kill the child process after a suitable period and make
sure that the read() on the pipe in the parent process terminates
with EINTR. Fairly straightforward stuff.

The code I'm trying to emulate (which works under SunOS) is:

>>> void start_watchdog(n)
>>> int n;
>>> {
>>> /*
>>> * Setup SIGALRM handler, force interrupt of ongoing syscall
>>> */
>>>
>>> new_action.sa_handler = myhandler;
>>> sigemptyset(&(new_action.sa_mask));
>>> new_action.sa_flags = SA_INTERRUPT;
>>> sigaction(SIGALRM, &new_action, &old_action);
>>>
>>> /*
>>> * Set interval timer for n seconds
>>> */
>>> timer.it_interval.tv_sec = 0;
>>> timer.it_interval.tv_usec = 0;
>>> timer.it_value.tv_sec = n;
>>> timer.it_value.tv_usec = 0;
>>> setitimer(ITIMER_REAL, &timer, NULL);
>>> interrupted = 0;
>>>
>>> }

The SunOS man page for sigaction defines SA_INTERRUPT is follows:

>>> #define SA_INTERRUPT 0x0002 /*
>>> * do not restart
>>> * system on signal
>>> * return
>>> */

This is obviously meant to read "do not restart system CALL on signal
return". The call is question is likely to be a read from the pipe, and
as various docs state I can't be certain that I'll get an EINTR in this
case - certainly not if there's any data in transit in the pipe. I
interpret SA_INTERRUPT to mean "please guarantee that ANY system
call in progress will be interrupted with EINTR when the signal
handler returns." Can I achieve this in SVR4?

Geoff

--Geoff Arnold, PC-NFS architect(ge...@East.Sun.COM or geoff....@Sun.COM)--
------------------------------------------------------------------------------
-- Sun Technology Enterprises : PC Networking group --
-- (a Sun Microsystems Inc. company) --

Rich Stevens

unread,
Jul 31, 1991, 2:53:03 PM7/31/91
to
>#I've looked in my third edition SVID and can find no mention of
>#SA_INTERRUPT, have I missed something here, or should I complain to my
>#friendly vendor ?

>After I saw your posting I grepped around


>/usr/include/sys on SunOS for SA_INTERRUPT and found the following:
>bodleian:geoff:79 %egrep SA_INTER /usr/include/sys/*.h
>/usr/include/sys/signal.h:#define SA_INTERRUPT SV_INTERRUPT
>
>Unfortunately, this doesn't seem to help matters. The SVR4 sys/signal.h
>is silent on this, as is the XPG. Can anyone help? How do I achieve
>the effect of SA_INTERRUPT under SVR4?

First, which version of SunOS were you looking at? I`d assume you
have access to the SVR4 beta version?

I was digging into this "restart-system call" flag a while back also.
From what I've found, SV_INTERRUPT was for sigvec(2) with 4.3BSD and
it said "do not restart". Then SunOS 4.1 (or earlier) came along and
added the #define shown above, I'd guess trying to make it look like
one of the SA_ constants for the POSIX-style sigaction(2). AT&T comes
along and defines the constant SA_RESTART, in both SVID Issue 3 and
the SVR4 man page. But, SA_RESTART says "automatically restart an
interrupted system call", just the *opposite* of SV_INTERRUPT. To
further confuse things, 4.3BSD Reno also defines SA_RESTART but the
comment in <signal.h> incorrectly says "do not restart" when it actually
treats it like SVR4. I certainly hope the SVR4 version of SunOS
provides SA_RESTART, since it's in the SVID. POSIX.1, of course,
punts on this whole issue of restarting system calls.

I can see how this happened, historically, since 4.2BSD did an automatic
restart that some people didn't like, so 4.3 gave you the option not to
restart. In the System V world, however, interrupted system calls were
never restarted automatically, so I guess the SVR4 people figured they'd
give you the choice to restart.

Rich Stevens (rste...@noao.edu)

Neil Todd

unread,
Aug 1, 1991, 3:55:17 AM8/1/91
to
In article <75...@eastapps.East.Sun.COM> ge...@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>I've xposted this to comp.unix.programmer.
>
>Quoth ne...@pio.gid.co.uk (Neil Todd) (in <1...@dsbc.icl.co.uk>):
>#Trying to compile the new PC-NFSD on my SVR4 machine, I get the following
>#error regarding undefined symbols:-
>#
># cc -g -DSVR4 -DSHADOW_SUPPORT -c pcnfsd_misc.c
>#"./common.h", line 142: warning: macro replacement within a string literal
>#"pcnfsd_misc.c", line 325: undefined symbol: SA_INTERRUPT
(stuff deleted)

>
>Unfortunately, this doesn't seem to help matters. The SVR4 sys/signal.h
>is silent on this, as is the XPG. Can anyone help? How do I achieve
>the effect of SA_INTERRUPT under SVR4?
>
(more stuff deleted)

>
>This is obviously meant to read "do not restart system CALL on signal
>return". The call is question is likely to be a read from the pipe, and
>as various docs state I can't be certain that I'll get an EINTR in this
>case - certainly not if there's any data in transit in the pipe. I
>interpret SA_INTERRUPT to mean "please guarantee that ANY system
>call in progress will be interrupted with EINTR when the signal
>handler returns." Can I achieve this in SVR4?
>

Having started this off (well, Geoff did ask for feedback), I think that
what I need is SA_RESTART (from SVID v3 sigaction(BA_OS) "...SA_RESTART
If set, system calls interrupted by this signal will be automatically
restarted by the system. Otherwise system calls interrupted by this signal
will return an EINTR error").

The only reason I raised this publically was I was uncertain of any other
clever stuff that SA_INTERRUPT might be expected to do.

Neil


>
>--Geoff Arnold, PC-NFS architect(ge...@East.Sun.COM or geoff....@Sun.COM)--

Neil Todd | ..In general, it is best to assume that the


PSI%234237100122::neil | network is filled with malevolent entities

ne...@pio.gid.co.uk | that will send in packets designed to have

Geoff Arnold @ Sun BOS - R.H. coast near the top

unread,
Aug 2, 1991, 11:33:16 AM8/2/91
to
Well, after all of the discussion here, the resolution seems
fairly straightforward. SunOS restarts calls by default, so
it's necessary to specify SA_INTERRUPT if you want to
ensure that the call is interrupted. SVR4 doesn't restart
calls, so you don't need to specify anything. Thus I suggest
that you make the following change to pcnfsd_misc.c in the
latest version:

sccs diffs -C pcnfsd_misc.c

------- pcnfsd_misc.c -------
*** /tmp/da10779 Fri Aug 2 11:29:11 1991
--- pcnfsd_misc.c Fri Aug 2 11:28:32 1991
***************
*** 322,328 ****

new_action.sa_handler = myhandler;
sigemptyset(&(new_action.sa_mask));
! new_action.sa_flags = SA_INTERRUPT;
sigaction(SIGALRM, &new_action, &old_action);

/*
--- 322,331 ----

new_action.sa_handler = myhandler;
sigemptyset(&(new_action.sa_mask));
! new_action.sa_flags = 0;
! #ifdef SA_INTERRUPT
! new_action.sa_flags |= SA_INTERRUPT;
! #endif
sigaction(SIGALRM, &new_action, &old_action);

/*


Geoff

--Geoff Arnold, PC-NFS architect(ge...@East.Sun.COM or geoff....@Sun.COM)--

Guy Harris

unread,
Aug 2, 1991, 2:05:53 PM8/2/91
to
>Having started this off (well, Geoff did ask for feedback), I think that
>what I need is SA_RESTART

No, what you need is the *absence* of SA_RESTART. SA_INTERRUPT and
SA_RESTART are inverses of one another (just as CBREAK and ICANON
are...).

Rich Stevens

unread,
Aug 2, 1991, 2:41:15 PM8/2/91
to
> SunOS restarts calls by default, so
> it's necessary to specify SA_INTERRUPT if you want to
> ensure that the call is interrupted. SVR4 doesn't restart
> calls, so you don't need to specify anything.

The unanswered question is what does the SVR4 version of SunOS do ??
Did it inherit the BSD style or the System V style ? My guess is
the latter since the SVID has SA_RESTART in it, and not SA_INTERRUPT.

Rich Stevens (rste...@noao.edu)

0 new messages