Unix administration - name pipe problem, quick question

Author

name pipe problem, quick question

187

2004-06-11, 5:35 pm

I'm trying to re-write a start up script for a game server (hl ds) and
setup named-pipes (cmd-1, for input, and res-1, for output, in
/home187/b/), but when I use the syntax in an example, it never actually
runns ./hlds as far as I can see from ps -x after running the script
(./tfcrun &), I just see a couple extra 'tfcrun's listed, where ther
should be just one, and an instance of ./hlds.

The pipes do seem to be created though:

$ ls -l b | grep prw
prw-r--r-- 1 187 187 0 Jun 11 00:58 cmd-1
prw-r--r-- 1 187 187 0 Jun 11 00:58 res-1

What am I doing wrong? (script is below)

system info:

$ uname -a
FreeBSD alderaan.matchservers.com 4.6-RELEASE FreeBSD 4.6-RELEASE #0:
Mon Dec 8 18:42:42 EST 2003
root@yoda.quakeserver.org:/usr/src/sys/compile/GENERIC i386

$ echo thanks for any help
thanks for any help

$ cat tfcrun

#!/bin/sh

cd ~/hlds_l
b='/home/187/b'

rm $b/cmd-1
mkfifo $b/cmd-1
rm $b/res-1
mkfifo $b/res-1

while true
do

d=`date`
echo "Starting TFC Server now ($d)." >> tfc.log

echo "" > $b/cmd-1&
echo "" > $b/res-1&
#./hlds -game tfc -port 27015 +ip 206.216.122.21 +maxplayers 18 +map
2fort
../hlds -game tfc -port 27015 +ip 206.216.122.21 +maxplayers 18 +map
2fort < $b/cmd-1 > $b/res-1

d=`date`
echo "Server stopped for some reason...restarting ($d)" >> tfc.log

sleep 20 # Wait 20 seconds after a crash, then restart.

done

$ exit
logout

those who know me have no need of my name

2004-06-11, 5:35 pm

in comp.unix.admin i read:

>rm $b/cmd-1
>mkfifo $b/cmd-1
>rm $b/res-1
>mkfifo $b/res-1
[...]
>echo "" > $b/cmd-1&

your script stops here, waiting for something to open $b/cmd-1 for reading.

--
a signature

187

2004-06-11, 5:35 pm

those who know me have no need of my name wrote:
> in comp.unix.admin i read:
>
> [...]
>
> your script stops here, waiting for something to open $b/cmd-1 for
> reading.

I even tried starting the script with nohup ./tfcrun &

How can I fix the problem? Any suggestions?

Richard Tobin

2004-06-11, 5:35 pm

In article <2itvdsFqt04iU1@uni-berlin.de>,
187 <bigal187.invalid@adexec.com> wrote:

[vbcol=seagreen]
[vbcol=seagreen]
>How can I fix the problem? Any suggestions?

Don't write to the named pipes until the program is listening on them.

-- Richard

187

2004-06-11, 5:35 pm

"Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message
news:cacln2$7j6$1@pc-news.cogsci.ed.ac.uk...
> In article <2itvdsFqt04iU1@uni-berlin.de>,
> 187 <bigal187.invalid@adexec.com> wrote:
>
>
>
>
> Don't write to the named pipes until the program is listening on them.

I'm not entirely sure what I'm doing (I've never worked with named pipes
before), could you please elaborate a little? What do you mean exactly?

I did try running with nohup, but hlds still doesn't run unless I remove
the name pipes from its execing line.

One think I'm not sure about is what the two echo lines are supposed to
do (shown below and the last line of code you quoted.) I only put them
in because they were in the example. As I said I'm not used to working
with named pipes so any help would be appreciated.

It still doesn't work even if I comment these lines:

echo "" > $b/cmd-1&
echo "" > $b/res-1&

Please, if you know how ot make this work (that is, have named pipes to
read and send to hlds), please help. I did search around google and
google groups but nothing help and could not find any good examplesor
help either.

Thank you

Lew Pitcher

2004-06-11, 5:35 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

187 wrote:

> "Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message
> news:cacln2$7j6$1@pc-news.cogsci.ed.ac.uk...
>
>
>
> I'm not entirely sure what I'm doing (I've never worked with named pipes
> before), could you please elaborate a little? What do you mean exactly?

Unless the programs handle named pipes with special settings
(O_NONBLOCK, IIRC), you get blocking behaviour by default.

A named pipe can have multiple writers, but only one reader. Any process
that opens the pipe for writing blocks until the pipe has also been
opened for reading. Any process that opens the pipe for reading blocks
on the first read until the pipe has been opened for writing.

The only way around this is to open the pipe in non-blocking mode, and
you can't do this in a script.

- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAygLCagVFX4UWr64RAkNfAKDqf4IpcMR3
4/+SXCo2JIHO6uuT7ACfa4S7
GYvOhWNRxjhXZBxiCqzYMEM=
=InmX
-----END PGP SIGNATURE-----

Barry Margolin

2004-06-11, 5:35 pm

In article <m18yeua2b8.gnus@usa.net>,
those who know me have no need of my name <not-a-real-address@usa.net>
wrote:

> in comp.unix.admin i read:
>
> [...]
>
> your script stops here, waiting for something to open $b/cmd-1 for reading.

It shouldn't, since he's running that command in the background. The
background process will block until another process opens the pipe for
reading, but the script should continue.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Richard Tobin

2004-06-11, 5:35 pm

In article <2it480Fr6g3jU1@uni-berlin.de>,
187 <bigal187.invalid@adexec.com> wrote:

>echo "" > $b/cmd-1&
>echo "" > $b/res-1&

In my earler message I didn't notice that you were running these in the
background, so ignore that.

>I just see a couple extra 'tfcrun's listed, where ther
>should be just one, and an instance of ./hlds.

Those are probably the echo commands, since echo is a shell built-in.

>it never actually
>runns ./hlds as far as I can see from ps -x after running the script
>(./tfcrun &)

Presumably you've checked the log file to be sure that it's not just
exiting immediately.

Try running it with "sh -x tfcrun" so that you see what commands are
executed.

-- Richard

187

2004-06-11, 6:32 pm

Richard Tobin wrote:
> In article <2it480Fr6g3jU1@uni-berlin.de>,
> 187 <bigal187.invalid@adexec.com> wrote:
>
>
> In my earler message I didn't notice that you were running these in
> the background, so ignore that.
>
>
> Those are probably the echo commands, since echo is a shell built-in.
>
>
> Presumably you've checked the log file to be sure that it's not just
> exiting immediately.
>
> Try running it with "sh -x tfcrun" so that you see what commands are
> executed.

Well using ps I know hlds isnt running, unless I remove the

< $b/cmd-1 > $b/res-1

part. Is it possible ther is someting wrong with the way this is setup?
Does the script need to be run with nohup?

i tried

nohup ./tfcrun &

but hlds still doesnt seem to run.

Richard Tobin

2004-06-11, 11:50 pm

In article <2iupk3FrvlrvU1@uni-berlin.de>,
187 <bigal187.invalid@adexec.com> wrote:

>Well using ps I know hlds isnt running, unless I remove the
>
> < $b/cmd-1 > $b/res-1

Ah, ok. What's reading from res-1? Nothing as far as I can see.
The shell won't be able to open it until something's reading.

(And if res-1 is for output, why did you echo something to it?)

The rule with named pipes is that you must set the readers going
before anything can be written; the writers will block until something
reads.

>Does the script need to be run with nohup?

Nohup has nothing to do with this.

-- Richard

Richard Tobin

2004-06-12, 2:50 am

Doug Freyburger

2004-06-14, 5:56 pm

187 wrote:
>
> I'm trying to re-write a start up script for a game server (hl ds) and
> setup named-pipes

Why are you using named pipes for a game server?

> What am I doing wrong? (script is below)

At a glance, using named pipes is what you are doing wrong. Game
servers are usually designed to operate over the network using
sockets. I'm not surprised that this one does not handle haivng
its stdin and stdout put into a pipe that doesn't have anything
on the other side.

> echo "" > $b/cmd-1&
> echo "" > $b/res-1&

Putting these in backgroupnd is not enough to keep the shell from
waiting. It's a bit like tape movement. The tape movement command
will comlete asynchronously, but if the next coomand deals with a
tape it has to do a sync/wait for the movement to complete. The
pipe device itself hangs waiting for something to read from it.

> ./hlds -game tfc -port 27015 +ip 206.216.122.21 +maxplayers 18 +map
> 2fort < $b/cmd-1 > $b/res-1

Remember that I/O redirection happens before the image is
launched. One of the echo's above to cmd-1 puts data into that
pipe, and the input redirection here takes that empty line
back out. The other echo above to res-1 puts data into that
pipe, and the output redirection above to res-1 puts more
data into it. Since there's an EOL in the buffer, the pipe hangs
waiting for some process to start reading from it.

Going over the order of I/O redirection resolves many issues
like this.

If there's a program that logs the game server's output, it needs
to be launched from a different shell. That should unhang the
pipe and allow this thread to launch the game server image.

Why are you using named pipes to log data? The game server
isn't set up to handle it.

Why did you prime the pump of both pipes with an empty line?
The game server better expect a blank line as its first input
line to make that pipe available for other processes.

Lesson learned #1 - If you set up a named pipe make very certain
you launch a reader on it in background before you launch any
writers to it.

Lesson learned #2 - Be very hesitant to use named pipes on any
server that normally uses pipes.

187

2004-06-15, 5:56 pm

Doug Freyburger wrote:
> 187 wrote:
>
> Why are you using named pipes for a game server?
>
>
> At a glance, using named pipes is what you are doing wrong. Game
> servers are usually designed to operate over the network using
> sockets. I'm not surprised that this one does not handle haivng
> its stdin and stdout put into a pipe that doesn't have anything
> on the other side.

Ok, sorry for the confusion. This game server (half-life) doesnt do the
game stuff from thep ipes, it uses udp sockets for that. THe purpose of
the pieps is the be able to use the console you'd otherwise have access
to if you ran hlds in the foreground. In other words theres a console
scroll of whats going on and chats, etc, and one can send commands. If
ran in foreground, normal STDOUT/STDIN action. Thats what the pipes were
suppost to capture and send to.

>
> Putting these in backgroupnd is not enough to keep the shell from
> waiting. It's a bit like tape movement. The tape movement command
> will comlete asynchronously, but if the next coomand deals with a
> tape it has to do a sync/wait for the movement to complete. The
> pipe device itself hangs waiting for something to read from it.
>
>
> Remember that I/O redirection happens before the image is
> launched. One of the echo's above to cmd-1 puts data into that
> pipe, and the input redirection here takes that empty line
> back out. The other echo above to res-1 puts data into that
> pipe, and the output redirection above to res-1 puts more
> data into it. Since there's an EOL in the buffer, the pipe hangs
> waiting for some process to start reading from it.
>
> Going over the order of I/O redirection resolves many issues
> like this.
>
> If there's a program that logs the game server's output, it needs
> to be launched from a different shell. That should unhang the
> pipe and allow this thread to launch the game server image.
>
> Why are you using named pipes to log data? The game server
> isn't set up to handle it.
>
> Why did you prime the pump of both pipes with an empty line?
> The game server better expect a blank line as its first input
> line to make that pipe available for other processes.
>
> Lesson learned #1 - If you set up a named pipe make very certain
> you launch a reader on it in background before you launch any
> writers to it.
>
> Lesson learned #2 - Be very hesitant to use named pipes on any
> server that normally uses pipes.

Thank you.