Struggling with mkfifo

Gurus,

I did my research (on google, this site and my local library) but I am *still* lost. I am trying to teach myself about `named pipes` playing around with MKFIFO (Why not?).

(1) It seems MKNOD is reserved to ROOT whereas MKFIFO is accessible to all users. Am I correct? If the answer is `yes,` can someone explain why? Based on what I read, both commands seem to produce the same results...

(2) I can create a fifo on a empty file e.g. `mkfifo empty_file` but when I attempt to edit it in VI (as myself or another userid), my editor never comes up. Is it because the blocking nature of the named pipe I created?

(3) It seems that when a process (here, VI) reads from a named pipe that has no data in it (here, `empty_file), the reading process is blocked. Fine. So, how do I write to it??

(4) Why can't I create a fifo out of an already existing file? Is it possible if I specify the correct mode e.g. `mkfifo already_existing_file +RW...`?

(5) Where can I find more *detailed* info about this topic?

Thanks in advance to all for sharing your knowledge. Al.

PS: I am on HP-UX B.11.00 U 9000/800.

So-rry your Unix-ness... I should have been more specific & I apologize: I'm still very new to Unix. I meant to say that on the machine I work on, I (as a user) can only use MKFIFO.

If I do `mknod bla`, I get an error message "mknod: must be super-user". BTW, I tried to do the same thing as you did: it did not work.

[dev1@la]/home/dev1% mknod bla p
[dev1@la]/home/dev1% cat bla &
[2] 23119
[dev1@la]/home/dev1% echo "hello world" > bla
ksh: bla: cannot create

I am working in my /home directory. What am I doing wrong?

if a user was allowed to mknod he woudl be able to create his own device files and could potentially really mess things up for an administrator.

mkfifo allows you to create a buffer area that is read by different process.

mknod is very strong. i would put it up there w/ allowing a user to issue adn execute the format utility.

I've been looking over my documentation for early versions of unix. The mknod system call and the mknod utility are restricted to root only until the arrivial of named pipes. When unix has named pipes, both the mknod system call and the mknod utility make an exception that allows anyone to create named pipes. I can't find a counter example to this, but I can accept that alan has found one.

I too am interested in which version of unix that alan is using. Alan since you are new to unix, you may not yet know about the uname command. "uname -a" is a command that will tell us about your version of unix.

As for mkfifo, both the function and utility seems to have come from posix. Originally, it seems, posix did not support mknod as being too unix-like. But it looks like mknod is there now, so i guess that they got over it.

Now concerning this:

[dev1@la]/home/dev1% echo "hello world" > bla
ksh: bla: cannot create

Before ksh can run the echo command, it must open bla. I would interpret this as ksh decided that it must create "bla" and was not succeeding. That would be very odd since the preceding "cat bla" seems to have worked.

alan, since mknod was not working for you, why did you use it in the example you posted? Were you running as root? Did you try the mkfifo command instead? Also after you create bla, run the command "ls -l bla" and post the results of that.

mkdir() preceded posix. When mknod() creates a directory, it is truly emply. It takes two link() calls to create the . and .. entries. This leaves a window where the directory has an illegal structure. This caused race conditions and if the program died before the link calls succeeded, the filesystem was left in an illegal state. Ordinary users had to invoke a suid program to make directories, in part to ensure that the links were at least attempted.

That's why the mkdir() system call was created...it atomically creates a valid directory in one system call. And user programs can invoke it. The mkdir utility no longer needs to be suid.

mknod() has been deprecated for creating directories for some time.

I am familiar with `uname -a`: I put my OS info in my first post but I guess it got lost in the clutter. I am on HP-UX B.11.00 U 9000/800.

I am NOT running as root. I know nothing about my user ("dev1") permissions but I am certain that I don't have super-user privilege. I have tried to use both `mknod` and `mkfifo`in my /home directory but to no avail:

[dev1@la]/home/dev1% mkfifo bla
[dev1@la]/home/dev1% cat bla &
[1] 10907
[dev1@la]/home/dev1% echo "hello world" > bla
ksh: bla: cannot create
[dev1@la]/home/dev1% ls -l bla
prw-rw-r-- 1 dev1 cadev 0 Apr 15 10:43 bla|
[dev1@la]/home/dev1%

I got the same error msg when I use "mknod". Obviously (see the "p"), I am able to create my fifo but it is as far as I can go.

I am confused: If I look at the permission bits, it seems that my fifo is usable by my userid for read/write, correct?

Can this be related to my user permissions? How can I know which those are? I have no super-user privileges so SAM is not accessible...

Just in case you're wondering why I am bothering with MKFIFO, MKNOD etc... is for the following reason:

I want to uncompress/compress a database binary (export) file and import/export the output into difference instances of my database simultaneously. I know that this can be done using a "named pipe" alongside with un/compress being run in the background.

That's what I am trying to accomplish. FYI.

alan, I just tried this stuff on a 9000/800 running HP-UX 11.00.

As a non-root user, I do get "mknod: must be super-user" with the command "/usr/sbin/mknod bla". But that is an illegal command. When I run the same command as root as get "illegal argument count" and a usage statement.

"/usr/sbin/mknod bla p" works fine for all users.

When I try:
cat bla &
echo "hello world" > bla

it works fine for me. I cannot reproduce that error. Yes, your fifo looks like it has both read and write for you.

Try switching shells. Just type "sh" which will start up a posix shell. It's very close to ksh. Does thast work any better? When I type "what /usr/bin/ksh", I get:

$ Revision: 82.10 $
Version 11/16/88

When I type "what /usr/bin/ksh", I get this
/usr/bin/ksh:
$Revision: 82.10.1.61 $
Version 11/16/88
PATCH_11_00: arith.o blok.o ctype.o defs.o edit.o echo.o expand.o fault.o io.o string.o stak.o word.o emacs.o vi.o hpux_rel.o args.o builtin.o cmd.o main.o msg.o print.o xec.o name.o macro.o error.o service.o test.o jobs.o history.o 02/09/04

I try switching to "sh". Same thing:
[dev1@la]/home/dev1% sh
[dev1@la]/home/dev1% mkfifo bla
[dev1@la]/home/dev1% cat bla &
[1] 13618
[dev1@la]/home/dev1% echo "hello world" > bla
sh: bla: Cannot create the specified file.
[dev1@la]/home/dev1% ls -l bla
prw-rw-r-- 1 dev1 cadev 0 Apr 15 13:37 bla|
[dev1@la]/home/dev1%

I also tried "csh" (just in case).Same thing:
% csh
% mkfifo bla2
% cat bla2 &
[1] 14009
% echo "hello world" > bla2
bla2: Is a directory.
% ls -l bla2
prw-rw-r-- 1 dev1 cadev 0 Apr 15 13:55 bla2
%

I am stumped. Could all of this be due that my userid is forbidden to use shell commands such as these? If it is the case, wouldn't I be getting an "error" message like "You are not authorized to ... this command..."??

This is an odd problem. What does "df -n ." and "bdf ." say? Also "cd /tmp" and repeat the mkfifo stuff.

"df -n" gives me (sorry, it's a lot of output)
/home/dev1 (cafs:/shared/homedirs/dev1) : nfs3
/users/oracle_backup (/dev/vgfc10/lvol1 ) : vxfs
/logs (/dev/vg00/lvol5 ) : vxfs
/opt (/dev/vg00/lvol6 ) : vxfs
/tmp (/dev/vg00/lvol4 ) : vxfs
/users/oracle (/dev/vgfc9/lvol1 ) : vxfs
/users/oracle_dump (/dev/vgfc8/lvol1 ) : vxfs
/users (/dev/vg00/lvol9 ) : vxfs
/usr (/dev/vg00/lvol7 ) : vxfs
/var (/dev/vg00/lvol8 ) : vxfs
/stand (/dev/vg00/lvol1 ) : hfs
/ (/dev/vg00/lvol3 ) : vxfs

"bdf" gives me (sorry, it's a lot of output too)
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 307200 74281 218393 25% /
/dev/vg00/lvol1 199381 43308 136134 24% /stand
/dev/vg00/lvol8 2048000 1408577 599802 70% /var
/dev/vg00/lvol7 2048000 684491 1278326 35% /usr
/dev/vg00/lvol9 4517888 2896020 1520504 66% /users
/dev/vgfc8/lvol1 226443264 195601336 30601024 86% /users/oracle_dump
/dev/vgfc9/lvol1 20951040 17467736 3428880 84% /users/oracle
/dev/vg00/lvol4 409600 39856 347349 10% /tmp
/dev/vg00/lvol6 2048000 778280 1190425 40% /opt
/dev/vg00/lvol5 1048576 16444 967669 2% /logs
/dev/vgfc10/lvol1 492306432 348862320 142323464 71% /users/oracle_backup
cafs:/shared/homedirs/dev1
427924288 153771888 252415104 38% /home/dev1

[dev1@la]/home/dev1% cd /tmp
[dev1@la]/tmp% mkfifo bla
[dev1@la]/tmp% cat bla &
[1] 14891
[dev1@la]/tmp% echo "this is a test" > bla
this is a test
[dev1@la]/tmp% ls -l bla
prw-rw-r-- 1 dev1 cadev 0 Apr 15 19:52 bla|
[1] + Done cat bla &
[dev1@la]/tmp%

IT WORKS??!! Can you please explain why it worked in /tmp but not in my /home directory??

Driver, I'm thinking alan has an nfs mounted home directory with the nodevs option set. I would still expect fifos to work under that scenario, but I'm not totally sure.

alan, give Driver's program a try. Knowing which system call is failing with which error will help.

Okay...I need somebody to whack me on the head with a 2x4...DRIVER : you wrote "That should yield a more descriptive error message" when talking about this program. Are you saying it should return an error when I run it against my fifo? Because it does not...

(1)log in to my account:
[dev1@la]/home/dev1
(2)paste DRIVER's code vi new.c ...
(3) compile it: cc new.c -o new
(4)[dev1@la]/home/dev1% mkfifo bla
(5)[dev1@la]/home/dev1% cat bla &
[1] 15141
(6)[dev1@la]/home/dev1% ./new bla
x
[dev1@la]/home/dev1%

Looking at the output of bdf and df, it seems that indeed, the file system for my /home directory is NFS mounted while /TMP is on "vxfs". Why does it matter? Can somebody PLEASE enlighten me?

Okay....using ">>" instead of ">" worked.

[dev1@la]/home/dev1% mkfifo bla
[dev1@la]/home/dev1% cat bla &
[1] 15586
[dev1@la]/home/dev1% echo "test" >> bla
test
[dev1@la]/home/dev1% ls -l bla
prw-rw-r-- 1 dev1 cadev 0 Apr 15 20:36 bla|
[1] + Done cat bla &
[dev1@la]/home/dev1%

It also worked successfully with MKNOD. It seems to confirm that the file system is the culprit, correct?

I agree there is an nfs bug here. I still would like to know if nodevs is set. What does "nfsstat -m" say?

Is it because the shell issue by default an OPEN() statement as opposed to a CREAT()??

The man page for CREAT() tells me "this system call creates a new regular file or prepares to rewrite an existing file...".

The man page for OPEN() seem to hint that when a file is first created with that system call using the general flag O_CREAT.

The first one seems to make more sense than the latter to me. Regardless of the file-system in use. It makes me think that I would better off learning C to circumvent this type of issues...

There you go:
[dev1@la]/home/dev1% nfsstat -m
/home/dev1 from cafs:/shared/homedirs/dev1 (Addr 10.27.230.133)
Flags: vers=3,proto=udp,auth=unix,soft,intr,link,symlink,rsize=8192,wsize=8192,retrans=5
Lookups: srtt= 7 ( 17ms), dev= 3 ( 15ms), cur= 2 ( 40ms)
Reads: srtt= 8 ( 20ms), dev= 4 ( 20ms), cur= 3 ( 60ms)
Writes: srtt= 17 ( 42ms), dev= 6 ( 30ms), cur= 5 (100ms)
All: srtt= 7 ( 17ms), dev= 3 ( 15ms), cur= 2 ( 40ms)

/admin from oak:/admin (Addr 176.36.50.231)
Flags: vers=3,proto=udp,auth=unix,hard,intr,link,symlink,rsize=8192,wsize=8192,retrans=5
Lookups: srtt= 8 ( 20ms), dev= 4 ( 20ms), cur= 3 ( 60ms)
Reads: srtt= 13 ( 32ms), dev= 7 ( 35ms), cur= 5 (100ms)
Writes: srtt= 1 ( 2ms), dev= 1 ( 5ms), cur= 0 ( 0ms)
All: srtt= 8 ( 20ms), dev= 4 ( 20ms), cur= 3 ( 60ms)

/home/labcop from opsla:/users/labcop (Addr 176.36.50.207)
Flags: vers=3,proto=udp,auth=unix,soft,intr,link,symlink,rsize=8192,wsize=8192,retrans=5
All: srtt= 0 ( 0ms), dev= 0 ( 0ms), cur= 0 ( 0ms)

/export from dbsla:/export1 (Addr 172.31.50.210)
Flags: vers=3,proto=udp,auth=unix,hard,intr,link,symlink,rsize=8192,wsize=8192,retrans=5
Lookups: srtt= 3 ( 7ms), dev= 3 ( 15ms), cur= 1 ( 20ms)
Reads: srtt= 1 ( 2ms), dev= 1 ( 5ms), cur= 0 ( 0ms)
Writes: srtt= 1 ( 2ms), dev= 1 ( 5ms), cur= 0 ( 0ms)
All: srtt= 5 ( 12ms), dev= 3 ( 15ms), cur= 2 ( 40ms)

[dev1@la]/home/dev1%

Thanks for taking the time to help me with this. I appreciate it.

Though I may do more harm than good, I agree with you. Any book suggestion that could get me started?

Well, it doesn't even have nodevs set. This is a very nasty bug because the behavior it exhibits is hard to understand. Bugs like that are a real problem when you're learning unix.

And yes, a deep understanding of the kernel can be gained by being a C programmer. And that is a big help with cases like this. Advanced Programming in the UNIX Environment by Richard Stevens is the best book I know of.

I would check to see if I had the latest nfs patches. But your system administrator will need to do that.

Thanks guys for all your help. I reported your findings to our SysAdmin.

Thanks again!