FYI in order to get 2.1.1p2 to work on my HP-UX 11.0 systems I had to patch
atomicio.c for EWOULDBLOCK (HP read() does not give the POSIX return code).
The new atomicio() is a clean fix for this timing problem; all it needs now
is this one little tweak.
Also had the "General Commercial Security" error (PAM_TERM_ERROR from
pam_acct_mgmt()) which I have very crudely addressed for now by hacking out
that check entirely.
*** atomicio.c Thu Jun 22 07:32:31 2000
--- /tmp/atomicio.c Thu Jul 6 09:03:30 2000
***************
*** 46,52 ****
res = (f) (fd, s + pos, n - pos);
switch (res) {
case -1:
! if (errno == EINTR || errno == EAGAIN)
continue;
case 0:
return (res);
--- 46,56 ----
res = (f) (fd, s + pos, n - pos);
switch (res) {
case -1:
! if (errno == EINTR || errno == EAGAIN
! #ifdef _HPUX_SOURCE
! || (errno == EWOULDBLOCK)
! #endif
! )
continue;
case 0:
return (res);
Steve Marquess 301-663-1770 x238 / 301-619-3933 voice
DMLSS Technical Manager DSN 343-3933
JMLFDC 301-663-6788 / 301-619-7831 fax
623 Porter Street steve.marquess at amedd.army.mil
Ft. Detrick, MD 21702-5018
Hi,
On Thu, 6 Jul 2000, Marquess, Steve Mr JMLFDC wrote:
: FYI in order to get 2.1.1p2 to work on my HP-UX 11.0 systems I had to patch
: atomicio.c for EWOULDBLOCK (HP read() does not give the POSIX return code).
: The new atomicio() is a clean fix for this timing problem; all it needs now
: is this one little tweak.
:
: *** atomicio.c Thu Jun 22 07:32:31 2000
: --- /tmp/atomicio.c Thu Jul 6 09:03:30 2000
: ***************
: *** 46,52 ****
: res = (f) (fd, s + pos, n - pos);
: switch (res) {
: case -1:
: ! if (errno == EINTR || errno == EAGAIN)
: continue;
: case 0:
: return (res);
: --- 46,56 ----
: res = (f) (fd, s + pos, n - pos);
: switch (res) {
: case -1:
: ! if (errno == EINTR || errno == EAGAIN
: ! #ifdef _HPUX_SOURCE
: ! || (errno == EWOULDBLOCK)
: ! #endif
: ! )
: continue;
: case 0:
: return (res);
Which problem(s) does this fix? If read() is really returning
EWOULDBLOCK instead of EAGAIN for POSIX non-blocking IO we should file a
defect and get it fixed. There was an old problem with send() returning
EWOULDBLOCK that was fixed over a year ago. Which ARPA transport patch
do you have installed? This was the defect information in the patch
README:
( SR number: [5003446658/STARS-ACTIVE/English] ; Defect:
JAGaa45906 )
send() when called non-blocking returns EWOULDBLOCK
rather than EAGAIN.
I have a test program and I don't see EWOULDBLOCK for sockets.
Kevin:
You are right about the patch, read() is indeed returning EWOULDBLOCK but HP
has a June 14, 2000 cumulative patch (s700_800 11.00 cumulative ARPA
Transport patch) that supposedly fixes the EWOULDBLOCK-instead-of-EAGAIN
problem (PHNE_21767, either obsoleting two earlier patches or "Not yet HP
recommended" depending on how you query). I'll try it out on an
in-house
system. Unfortunately it will take us quite awhile to run this substantial
looking patch through our QA process and push it to our deployed systems
worldwide (auto-reboot in particular is a problem), so in the meantime I'll
still need to hack atomicio.c locally. Good tip, though, thanks.
BTW I'm seeing the same General Commercial Security error you've
reported
(HP-UX B.11.0, same pam.conf).
-Steve M.
-----Original Message-----
From: Kevin Steves [mailto:stevesk at sweden.hp.com]
Sent: Saturday, July 08, 2000 11:38 AM
To: Marquess, Steve Mr JMLFDC
Cc: openssh-unix-dev at mindrot.org
Subject: Re: 2.1.1p2 HP-UX 11 timing error
Hi,
On Thu, 6 Jul 2000, Marquess, Steve Mr JMLFDC wrote:
: FYI in order to get 2.1.1p2 to work on my HP-UX 11.0 systems I had to
patch
: atomicio.c for EWOULDBLOCK (HP read() does not give the POSIX return
code).
: The new atomicio() is a clean fix for this timing problem; all it needs
now
: is this one little tweak.
:
.
.
<<snip>>
.
.
Which problem(s) does this fix? If read() is really returning
EWOULDBLOCK instead of EAGAIN for POSIX non-blocking IO we should file a
defect and get it fixed. There was an old problem with send() returning
EWOULDBLOCK that was fixed over a year ago. Which ARPA transport patch
do you have installed? This was the defect information in the patch
README:
( SR number: [5003446658/STARS-ACTIVE/English] ; Defect:
JAGaa45906 )
send() when called non-blocking returns EWOULDBLOCK
rather than EAGAIN.
I have a test program and I don't see EWOULDBLOCK for sockets.