I want to use named fifo channel and I want to implement a timeout when I write in this fifo.
fd = open(pipe, O_WRONLY);
write(fd, msg, len);
Program is blocked by function open, so using the function select will not work.
Thanks.
use select() and its timeout argument.
Read pipe(7), fifo(7), poll(2)
You might setup a timer or or alarm with a signal handler (see time(7) & signal(7)) before your call to open(2) - but I won't do that - or you could use the O_NONBLOCK flag, since fifo(7) says:
A process can open a FIFO in nonblocking mode. In this case, opening
for read-only will succeed even if no-one has opened on the write
side yet, opening for write-only will fail with ENXIO (no such device
or address) unless the other end has already been opened.
However, you need something (some other process reading) on the other side of the FIFO or pipe.
Perhaps you should consider using unix(7) sockets, i.e. the AF_UNIX address family. It looks more relevant to your case: change your code above (trying to open for writing a FIFO) to a AF_UNIX socket on the client side (with a connect), and change the other process to become an AF_UNIX socket server.
As 5gon12eder commented, you might also look into inotify(7). Or even perhaps D-bus !
I'm guessing that FIFOs or pipes are not the right solution in your situation. You should explain more and give a broader picture of your concerns and goals.
Related
I have read the Linux manpage of pipe2, that states that you can use the O_DIRECT flag to create a pipe that performs I/O in packet mode.
I haven't found anything similar for fifos (named pipes) although I have heard that pipes and fifos share a lot of code in Linux, and it could be useful to me in a project (we already pass messages in fifos, but we have to seek for an especial terminator, reading one byte at a time).
Is there anything equivalent to perform fifo I/O in packet mode?
The O_* flags on a file descriptor can usually be changed by fcntl(fd, F_SETFL, ...) but in this case I don't think it will work, because of this:
https://lkml.org/lkml/2015/12/15/480
It's a patch that was submitted just 2 weeks ago to support exactly this use case, and the only replies to it have been a couple of build failures from an automated tester.
So you can try fixing that patch and applying it (should be easy - looks like a typo, the f should be filp)...
or (this is the option I'd prefer) see if your needs can be met by an AF_UNIX, SOCK_SEQPACKET socket instead of a pipe with this new flag. They're more powerful and more portable.
(I assume you already tried passing the O_DIRECT to open when you open the named pipe, since that's the most obvious thing.)
Both pipe & fifo are byte stream, it open a file descriptor, then use read() and write() to do communication.
If u want a packet (I am not sure what u mean, I assume you want to read a block of data without determine the boundary by yourself), POSIX - message queue might be a good choice. It send / receive data in unit of a message instead of byte by byte.
And you can also set priority on the messages which change the order of receiving, if all messages have the same priority (e.g 0), then the send & receive order is the same as FIFO.
If that's what u want, then check man mq_overview for details.
I'm not able to switch to a socket or message queue, and am stuck with using pipe. But good news, the patch refereed to in user2404501's answer eventually got accepted and is in linux v4.5 and newer. So using fnctl() to set O_DIRECT on a named pipe is valid.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0dbf5f20652108106cb822ad7662c786baaa03ff
How do I get the descriptor type? I am using epoll to monitor lots of descriptors like sockets, timers, and signals. I saw it is possible using fstat, but the mode only says something about sockets and pipes. fstat manpage. Is there a special function to identity a descriptor?
I do not think there is any simple or uniform way to do what you are asking. The command lsof]1 manages to determine this information so you may want to take a look at that code to see what they are doing.
Off the top of my head to determine if a descriptor is a socket you can use getsockopt(2). If a call to getsockopt fails and errno == ENOTSOCK then your descriptor is not a socket. likewise you can use isatty(3) to determine if a descriptor belongs to a serial port or terminal.
I have to write a chat client-server for a class using unix sockets (without O_NONBLOCK) and select for asynchronous I/O on them. At the moment, on the server, i read 1024 bytes from the client, and directly handle it.
For example, in case of a message, i will receive a command formatted as MSG <msg> (representing a client sending a message), i will go through all the sockets of the connected clients and write the message on them.
This approach actually works but i recently found by reading the man of send that it can blocks if the socket buffer is full and is the flag O_NONBLOCK is not set on the socket.
I think this problem could happen when a client does not read for some reasons (crash, bugged etc.) and this would be critical for my server since it will basically blocks until this client read again.
So here is my question:
What is the correct approach on a potentially blocking socket to avoid send to block if the socket buffer is full?
I'm currently using select only to check if there is something to read on sockets but maybe i should use it also to see if i can write on a particular socket too? And also, can i know how many bytes i can read/write when select returns? For example, if select "tells" that i can write on this socket, how can i know how many bytes i can write at most before writing on this socket actually becomes blocking?
Thanks.
You could use setsockopt() together with SO_SNDTIMEO to set up a maximum amount of time send() will try to do its work.
See man setsockoptand man 7 socket for details.
It might be horrible. If you don't go NONBLOCK-ing mode and calling select(), which internally puts the process on sleep for specific timeout value. That means, fd will be blocked for that specific time period.
This approach actually works but i recently found by reading the man of send that it can blocks if the socket buffer is full and is the flag O_NONBLOCK is not set on the socket.
This is why you use select, but it still isn't reliable, as man select states:
Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has
arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may
be safer to use O_NONBLOCK on sockets that should not block.
BackgroundI'm playing around with a FIFO and every time I try to write on my fifo it blocks until someone is reading the other side of the fd:
int fd;
char buffer[100] = {0};
char * myfifo = "/tmp/myfifo";
mkfifo(myfifo, 0666);
printf("What would you like to send?\n");
fgets(buffer, 100, stdin);
if((fd = open(myfifo, O_WRONLY)) < 0)
printf("Couldn't open the FIFO for writing!\n");
else {
write(fd, buffer, strlen(buffer));
close(fd);
This code works, but it blocks until I read the /tmp/myfifo side and get the data. When I change the code as such:
if((fd = open(myfifo, O_WRONLY | O_NONBLOCK)) < 0)
Then the open fails with error No such device or address, unless I have someone sitting blocked on the "read" side.
Analysis
As per the man page for fifo():
The kernel maintains exactly one pipe object for each FIFO special file that is opened by at least one process. The FIFO must be opened on both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also.
So this is expected operation.
Question
Based on my experiments, and what I'm reading... I have to assume a FIFO is a non-queued, non-buffered mechanism and only works when there is a process sitting and waiting for data.
Is there a different communication mechanism that works in a non-blocked buffered manor, basically a buffered FIFO, or would I have to make my own message storage/notification system for that?
EDIT
I say I'm "playing around" which is actually pretty descriptive here. I'm trying to learn the ins and outs of the various IPC mechanisms (FIFOs, sockets, and pipes). I'm working towards learning to use select() and understand what can be used to wake up sleeping processes which call select. Reason being it's part of a communications driver I'm analyzing for port to a new platform.
I excluded this from the original post as it is sort of irrelevant. I'm just trying to make sure I can understand (at the moment) FIFO's, how to use them, the limitations on them, and other IPC mechanism. Hence my original assumption/questions about "better" versions of FIFO that will store data and can be written to without blocking.
Not only is a FIFO buffered, but that's basically all a FIFO is. A FIFO is little more than a buffer in the kernel.
Discussion: The kernel has a policy that it refuses to write data to the buffer unless a process has the FIFO open for reading. This behavior is similar to pipes and TCP connections, although if there's no reader for a pipe or a TCP connection, the kernel will actually signal the writing process, terminating it (unless you install a handler). This behavior allows us to string together commands the way we expect, e.g.,
hexdump file.dat | head
The hexdump program gets killed once head reads a few lines. This is what we want 99% of the time, and hexdump doesn't need any special code to achieve this.
Solutions: It would help if you describe some more context about the problem you are trying to solve.
If you want a client/server system where the server queues messages that can be read by the clients, you can achieve this with Unix domain sockets. Unix domain sockets are similar to FIFOs but more flexible in various ways. (Most database servers prefer Unix domain sockets over other types of IPC.)
If you want to be able to store a persistent queue, where applications can independently enqueue and dequeue messages, then you will need to use ordinary files.
Unfortunately, "playing around with a FIFO" is not much to go on. If you want a good exercise in IPC, try writing a chat server that uses Unix domain sockets or TCP (or both at the same time, which isn't much harder). You can use telnet or nc (netcat) as a client. (Make sure you have the "OpenBSD" version of netcat.)
I have a sample application of a SIP server listening on both tcp and udp ports 5060.
At some point in the code, I do a system("pppd file /etc/ppp/myoptions &");
After this if I do a netstat -apn, It shows me that ports 5060 are also opened for pppd!
Is there any method to avoid this? Is this standard behaviour of the system function in Linux?
Thanks,
Elison
Yes, by default whenever you fork a process (which system does), the child inherits all the parent's file descriptors. If the child doesn't need those descriptors, it SHOULD close them. The way to do this with system (or any other method that does a fork+exec) is to set the FD_CLOEXEC flag on all file descriptors that shouldn't be used by the children of you process. This will cause them to be closed automatically whenever any child execs some other program.
In general, ANY TIME your program opens ANY KIND of file descriptor that will live for an extended period of time (such as a listen socket in your example), and which should not be shared with children, you should do
fcntl(fd, F_SETFD, fcntl(fd, F_GETFD) | FD_CLOEXEC);
on the file descriptor.
As of the 2016? revision of POSIX.1, you can use the SOCK_CLOEXEC flag or'd into the type of the socket to get this behavior automatically when you create the socket:
listenfd = socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0);
bind(listenfd, ...
listen(listemfd, ...
which guarentees it will be closed properly even if some other simultaneously running thread does a system or fork+exec call. Fortunately, this flag has been supported for awhile on Linux and BSD unixes (but not OSX, unfortunately).
You should probably avoid the system() function altogether. It's inherently dangerous, in that it invokes the shell, which can be tampered with and rather non-portable, even between Unicies.
What you should do is the fork()/exec() dance. It goes something like this
if(!fork()){
//close file descriptors
...
execlp("pppd", "pppd", "file", "/etc/ppp/myoptions", NULL);
perror("exec");
exit(-1);
}
Yes, this is standard behavior of fork() in Linux, from which system() is implemented.
The identifier returned from the socket() call is a valid file descriptor. This value is usable with file-oriented functions such as read(), write(), ioctl(), and close().
The converse, that every file descriptor is a socket, is not true. One cannot open a regular file with open() and pass that descriptor to, e.g., bind() or listen().
When you call system() the child process inherits the same file descriptors as the parent. This is how stdout (0), stdin (1), and stderr (2) are inherited by child processes. If you arrange to open a socket with a file descriptor of 0, 1 or 2, the child process will inherit that socket as one of the standard I/O file descriptors.
Your child process is inheriting every open file descriptor from the parent, including the socket you opened.
As others have stated, this is standard behavior that programs depend on.
When it comes to preventing it you have a few options. Firstly is closing all file descriptors after the fork(), as Dave suggests. Second, there is the POSIX support for using fcntl with FD_CLOEXEC to set a 'close on exec' bit on a per-fd basis.
Finally, though, since you mention you are running on Linux, there are a set of changes designed to let you set the bit right at the point of opening things. Naturally, this is platform dependent. An overview can be found at http://udrepper.livejournal.com/20407.html
What this means is that you can use a bitwise or with the 'type' in your socket creation call to set the SOCK_CLOEXEC flag. Provided you're running kernel 2.6.27 or later, that is.
system() copies current process and then launch a child on top of it. (current process is no more there. that is probably why pppd uses 5060. You can try fork()/exec() to create a child process and keep parent alive.