From: kmcvay@oneb.almanac.bc.ca (Ken Mcvay)
Subject: [REPOST] LISTSERV: Shell failure (WEIRD,XENIX) HAAAAAAALLLLLLLP!
Organization: The Old Frog's Almanac, Vancouver Island, CANADA
Date: Sun, 11 Oct 1992 21:05:48 GMT
Followup-To: comp.unix.xenix.sco
Summary: When did we leave kansas, toto?
Keywords: listserv

[ Reposted for a friend ]

In article <1992Oct07.002849.26390@oneb.almanac.bc.ca> I wrote:

[lots of blather about what a bitch it was to install listserv...]

The same problem exists on two systems now - mine, where it was installed
bit by bit, and another where it was done 'by the book.' I have scrapped
installation as a potential source for the problem...

>Mail addressed to the test list ends up in the appropriate list mail file.
>Mail addressed to the server, however, runs into wierdness <gnashing of
>teeth, etc.> before barfing and bringing the server down. Plunk.
>
>Here's what ps-ef looks like (server only) at the Point of Barf:
>
>    UID   PID  PPID  C    STIME   TIME COMMAND
> server 23153 21799  2 15:44:56   0:00 sh
> server 23154 23153  9 15:44:56   0:00 ps -ef
> server 23116 23111  0 15:44:29   0:00 sh -c /usr/server/listserv -1   -e -r s
> server 23117 23116  0 15:44:29   0:00 /usr/server/listserv -1 -e -r statistic
> server 21799 10253  0 15:14:36   0:02 sh
> server 23111     1  0 15:44:28   0:00 /usr/server/serverd -l 3 -e
> server 23118 23117  0 15:44:29   0:00 sh -c cp /usr/server/requests /usr/serv
> server 23119 23118  0 15:44:29   0:00 cp /usr/server/requests /usr/server/.me
>
>Note the attempt to cp the requests file - that produces:
>
>WARNING:
>System call exit status 130:
>cp /usr/server/requests /usr/server/.messages
>Time/Date: 15:52:57, 10/06/92

This error, identical on both machines, hasn't been identified yet... I'm
hoping some kind soul who has access to that info will enlighten me...the
shell process simply sits there, doing nothing, until you hit BREAK from the
terminal you started it on. The sequence is:

1. serverd spawns off to listserv
2. listserve goes back to the shell, which
3. runs the cp command
4. zero-byte .messages created by server and owned by group
5. the /usr/server/request file shows up on running 'l req*'
6. the (server) system hangs, waiting on the shell
7. I send BREAK (or.. long period goes by, then crashes)
8. shell crashes, still at the cp command

The file created, .messages, is the correct one, and the directory is owned
by userid server groupid group, permissions 777. The owner of the directory
cannot cp a file it owns... imagine.

Nor can the requests file itself be read, edited, or moved while the shell
is brain-challenged and twiddles its thumbs.

>I don't know what status 130 refers to, but I suspect it means that the file
>~/requests cannot be read by server, listserv, or cp. <Gentlemen, we have
>an, er, permissions problem> This is because I also can't cat requests, or
>read it in any way, once it arrives in the server directory....

I have since tried running list and listserv SUID, which made no difference
whatsoever.

>The requests file is correctly permissioned according to setup at 640, owned
>by server, group group.

We've also tried using 666 perms, but it didn't make any difference.

>I've been chatting with the author, who probably thinks I'm nuts. He may be

Now it gets more interesting... I'm used to having things screw up during
installation... after all, this _is_ a XENIX system :-)

After a long series of exchanges between Tasos, the author, I was amazed
when he asked me for the system's phone number - he wanted to take a look,
on his nickle, and see if he could find out what the hell was going on.

I was even more impressed when he spend about 45 minutes on the system, all
the while sending me email from his site about what he was doing. THAT was
above and beyond the call of duty! After this period, he left me this note,
which conveys our frustrations nicely:

>From server Wed Oct  7 13:21:32 1992
To: kmcvay
Date: Wed Oct  7 13:21:32 1992
Status: RO

I am running listserv -1 -e by hand it does not do anything until I
hit ^C. It actually does not execute ONLY ONCE as I tell it.

Moreover, if I put it in the background (listserv -1 -e &) then I STILL
HAVE TO HIT ^C AT THE SHELL PROMPT TO MAKE IT STOP!!!!!!

If I dont, then the cp, sh, listserv processes run for ever. At this
point I am tempted to say you will never be able to run this system.

Since the system executes the cp command by doing a system() (which uses
the Bourne shell) it looks like sh takes control of the tty (Oh my God)
and it runs in the background (!!!) until I hit ^C (!!!!)

I really do not know what the hell is going on.

Tasos

--------30--------

Stephen Walik (steve@nshore.org), who originally compiled listserv for me,
noticed something that had puzzled me for years (still does), but which I
had long ago dismissed as the result of a sloppy compile/installation on my
part: smail throws group 32767 on everything it handles.. I was surprised
that someone else's machine behaved the same way....here's the interesting
part from last night's message about listserv:

------> steve@nshore.org:

Now, what I'm not real crazy about is --

	1)  The "WARNING" in the < /usr/server/.warning > file

	2)  All the ".ignored" files written....

	3)  This entry in < /usr/server/.report.catmail > file --

		--- NEW MAIL FOR LISTSERV ---
		Access granted to user id 32767 (nobody)
		Time/Date: 21:57:54, 10/08/92

....The reason I think (3) holds the key is because that's what I can re-
member once before with something, and I can't think at all what it might
have been, was that the uid of "32767", and gid (of 32767) seems to be
something on all SCO-Xenix systems that refer to "mail".  If you notice,
is says "Access granted to user id 32767 (nobody)".  I even tried to
make the user "server" have a uid of 32767, but that did nothing for the
price of fish!  :-(

Now, it would make sense that `` cp '' would hang there for "server" is
not 'suid', nor is `` cp '', and, if `` cp '' cannot write to a file (yes,
I even tried to created a 'null' file before hand) owned by "server",
nor, worse, cannot create that file in < /usr/server >, then, of course,
the process is going to hang!
				---30---

Can someone explain why this userid 32767  pops up? Having done that, can
they then go on to tell me whether or not this could be related to the
shell's inability to cp a file within its home directory, regardless of
ownership of the files or permissions of the files?

>Is there anyone out there who has successfully installed listserv on SCO
>XENIX 2.3.2?

Still waiting for a positive answer - hasn't ANYONE ported listserv to
XENIX?

>The reports are available to anyone who wants to see them

Still.

--
The Old Frog's Almanac - Public Access UseNet for Central Vancouver Island
     (604) 245-3205 (v32) (604) 245-4366 (2400x4) Waffle XENIX 1.64
Ladysmith, British Columbia, CANADA. kmcvay@oneb.almanac.bc.ca (Ken McVay)
                    < October 26th: voting NO >
Newsgroups: comp.unix.xenix.sco,comp.unix.questions,comp.sys.sun.misc