Persistent connection to named pipe
Some years back I created a little FIFO-reader utility that can be used to relay data via a named pipe (FIFO) such that it keeps the output end of the FIFO open despite multiple opens/closes of the input end by one or more writers. This is necessary because the naive approach only works once, as illustrated here: # mknod /tmp/FIFO p #(could also have used mkfifo) # cat /tmp/FIFO #Have an instance of cat waiting for data. [1] 25868 # (bash confirms backgrounded process) # date /tmp/FIFO# 1st date opens FIFO, writes it, closes it. Wed Jul 14 11:45:04 EDT 2010 # cat shows data but exits as next read() = 0. [1]- Done cat /tmp/FIFO # (bash confirms exit of backgrounded process) # date /tmp/FIFO# 2nd date hangs - nobody reading the FIFO If I had used my FIFO-reader utility instead of cat in this example I could have had as many instances of date (or whatever) spewing sequentially into the FIFO and it would have relayed everything and none of the writers would have blocked. I'm now working with a cantankerous old app that can't easily be modified and it'd be handy to have multiple sequential invocations of that app each spew some logging data into a FIFO (without blocking) so it could be processed by a single persistent instance of a filter connected to the output of that FIFO. I'm therefore about to dredge up my little utility and put it back into service in this situation but before I do I wonder if anybody knows of something that's part of the standard Gnu/Linux stuff that already solves this problem. I thought I'd recently heard that some surprisingly complex options are/were being added to cat and half expected to find this behavior is now an option, but maybe that was just some smarta** taking a cheap-shot at the Gnu folks... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Persistent connection to named pipe
Well... interesting. I wonder why cat acts that way. Interestingly, I'd played around with FIFOs some time ago, and there's a fine way to cheat: tail -f. k...@minastirith:~$ mknod /tmp/FIFO p k...@minastirith:~$ tail -f /tmp/FIFO /tmp/FIFO.log [1] 13082 k...@minastirith:~$ date /tmp/FIFO k...@minastirith:~$ date /tmp/FIFO k...@minastirith:~$ cat /tmp/FIFO.log Wed Jul 14 13:22:04 EDT 2010 Wed Jul 14 13:22:07 EDT 2010 -Ken On Wed, July 14, 2010 12:26 pm, Michael ODonnell wrote: Some years back I created a little FIFO-reader utility that can be used to relay data via a named pipe (FIFO) such that it keeps the output end of the FIFO open despite multiple opens/closes of the input end by one or more writers. This is necessary because the naive approach only works once, as illustrated here: # mknod /tmp/FIFO p #(could also have used mkfifo) # cat /tmp/FIFO #Have an instance of cat waiting for data. [1] 25868 # (bash confirms backgrounded process) # date /tmp/FIFO# 1st date opens FIFO, writes it, closes it. Wed Jul 14 11:45:04 EDT 2010 # cat shows data but exits as next read() = 0. [1]- Done cat /tmp/FIFO # (bash confirms exit of backgrounded process) # date /tmp/FIFO# 2nd date hangs - nobody reading the FIFO If I had used my FIFO-reader utility instead of cat in this example I could have had as many instances of date (or whatever) spewing sequentially into the FIFO and it would have relayed everything and none of the writers would have blocked. I'm now working with a cantankerous old app that can't easily be modified and it'd be handy to have multiple sequential invocations of that app each spew some logging data into a FIFO (without blocking) so it could be processed by a single persistent instance of a filter connected to the output of that FIFO. I'm therefore about to dredge up my little utility and put it back into service in this situation but before I do I wonder if anybody knows of something that's part of the standard Gnu/Linux stuff that already solves this problem. I thought I'd recently heard that some surprisingly complex options are/were being added to cat and half expected to find this behavior is now an option, but maybe that was just some smarta** taking a cheap-shot at the Gnu folks... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Persistent connection to named pipe
Michael ODonnell writes: I'm now working with a cantankerous old app that can't easily be modified and it'd be handy to have multiple sequential invocations of that app each spew some logging data into a FIFO (without blocking) so it could be processed by a single persistent instance of a filter connected to the output of that FIFO. I'm therefore about to dredge up my little utility and put it back into service in this situation but before I do I wonder if anybody knows of something that's part of the standard Gnu/Linux stuff that already solves this problem. (dd's noerror option didn't do what you wanted here) How about: (while true ; do cat ; done ) /tmp/FIFO Regards, --kevin -- alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/ GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E Wipe him down with gasoline 'til his arms are hard and mean From now on boys this iron boat's your home So heave away, boys. -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Persistent connection to named pipe
Ken wrote: Well... interesting. I wonder why cat acts that way. IIRC a read() of the FIFO when all data have been consumed and the writer has closed his end yields -1 with errno EAGAIN and most apps just call it quits at that point. Interestingly, I'd played around with FIFOs some time ago, and there's a fine way to cheat: tail -f. D'oh!!! Kevin wrote: How about: (while true ; do cat ; done ) /tmp/FIFO Again: D'oh!!! Couldn't you guys have suggested more obscure solutions? Did they have to be things I use every fscking day? (They're just the sort of stuff I was looking for - thx) GNHLUG rocks. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Persistent connection to named pipe
Interestingly, I'd played around with FIFOs some time ago, and there's a fine way to cheat: tail -f. D'oh!!! It might be coming back to me now, why I didn't use the tail -f trick Way Back When; although it appears to work as expected with a FIFO on a CentOS5.4 box I have yet to see any output when used on the RHEL3 system where I actually need to do the filtering. Fortunately, Kevin's approach is working there... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
dhclient and DNS registration
I cannot seem to get Fedora 13 (or any other Linux distro) to register with our local nameserver. I feel like this should be a simple process (maybe it is and I'm just slow) So far, all my attempts and man page/InterWeb research have come up short. The system looks like it's trying to register but all requests go to a multicast addr (224.0.0.251) and the protocol is MDNS. Since it's multicast, there's no guarantee I'll ever get a response (positive or negative), but it clearly does not work because I can't reach the machine via hostname or fqdn. On windoze I see no MulticastDNS requests, but I do see standard SOA request directly to the nameserver, followed by a dynamic update exchange indicating the PTR was successfully updated. All my winders boxes seem to have no problem dynamically registering to the nameserver, but none of my linux systems (dhcp or static addr) are resolvable without having IT manually add a PTR. I've asked a couple other *nix hackers in the office, but they all shake their heads and say Let me know if you get it to work Following the suggestion found in several threads on linuxquestions.org and the fedora forums I've tweaked various network files that should make it work. sysconfig/network and resolv.conf are fine. sysconfig/network-scripts/ifcfg-eth0 has an entry: DHCP_CLIENT_ID=my_hostname I see NetworkManager generated/updated the file /var/run/nm-dhclient-eth0.conf with: send dhcp-client-identifier my_hostname None of it made a difference. Now I turn to the all-knowing gnhlug... Any ideas? Regards, -- Joel ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
