| rwp | bgstack15, SIGPIPE is 13 and 13+128 = 141 as returned by the shell encoded to know it is a signal exit. | 00:00 |
|---|---|---|
| rwp | A write to a named pipe without any readers returns a SIGPIPE. Processes should never ignore SIGPIPE. Lots of cascade problems. | 00:01 |
| rwp | A time honored technique for named pipes is to have one process open it for reading but never read from it. Then writes to the pipe block until there is a reader. | 00:01 |
| bgstack15 | Ah, thank you, rwp. I had decoded 141 down to binary 10001101 but hadn't realized the 13 was significant. I thought maybe it was 4 separate flags that I didn't know how to proceed further with. | 00:12 |
| bgstack15 | Do you think that I should therefore make yet another fork()ed child process that opens fifo and just while(1) or something? | 00:13 |
| bgstack15 | while(1); | 00:13 |
| rwp | I would need to see what your code is doing in order to make an opinion about it. | 00:14 |
| rwp | Other than the strong opinion that ignoring sigpipe has long caused problems. I have chased problems with it again and again. | 00:15 |
| rwp | Though if you never fork a child then it's all contained in your program code and that is okay. | 00:15 |
| rwp | But for example a low level init process on another software distro ignored SIGPIPE at one point. That is inherited. And there is no way for the child to un-ignore it. | 00:16 |
| rwp | Which just created a nasty cascade of errors! It's been such a long journey that it is a pet peeve of mine now. | 00:17 |
| bgstack15 | This is a user-level "daemon" for monitoring and displaying capslock+numlock status in system tray icons | 00:18 |
| bgstack15 | I wrap around https://github.com/jonhoo/mktrayicon which used name pipes as an interface | 00:19 |
| bgstack15 | maybe I can rewrite major parts of it to use a socket and then I won't need named pipes or even child processes. | 00:19 |
| bgstack15 | https://bgstack15.ddns.net/cgit/keyboard-leds-trayicons/tree/experimental/keyboard-leds-trayicons.c?h=experimental&id=29fa73d2f5013c9502934bc8252014a211d7f7a8 | 00:21 |
| rwp | I don't have a negative immune response to using named pipes. (shrug.) However if you are in C code then Unix domain sockets are slightly more efficient. And more typically used. | 00:21 |
| Xenguy | Wow, you guys are rockin' today | 00:24 |
| * Xenguy bows before such expertise... | 00:24 | |
| rwp | Xenguy, Experience and Treachery will always triumph over Youth and Enthusiasm. Especially the treachery part. :-) | 00:26 |
| bgstack15 | Hm, I think I more closely match the enthusiasm bit. | 00:26 |
| Xenguy | To me treachery seems like an alliteration | 00:28 |
| bgstack15 | I like the way C operates; I just barely know how to use it. | 00:28 |
| Xenguy | If my brain serves me correctly | 00:28 |
| rwp | I am reading through your code bgstack15 and it will take a moment to get the vision of it. | 00:29 |
| bgstack15 | It's a C rewrite of a shell script in the same repo, if shell is easier for you to read. | 00:29 |
| bgstack15 | (and get the vision) | 00:29 |
| Xenguy | bgstack15, Can't go wrong learning some C me thinks | 00:30 |
| rwp | I will go look at the shell too. I am pretty bilingual between C and sh. | 00:33 |
| rwp | But with C (and most other languages) the library used with it can be unfamiliar. | 00:33 |
| bgstack15 | I also love how you can just run man <FUNCTIONNAME>. I wanted to try a libini-config5 (dependency of sssd which is a major thing I use, so it's on every system I have) C library for parsing ini files but it had no freaking documentation AT ALL | 00:33 |
| rwp | bgstack15, I rather wish we had a code review site, such as garrit or something, so that comments could be logged on sections. | 00:44 |
| rwp | I think in main() around line 775 where the fifo is opened O_WRONLY that if that were O_RDWR then the parent would have an open read on the fifo and that would prevent the SIGPIPE and makes writes block if the pipe fills instead of sending a SIGPIPE. | 00:46 |
| rwp | With my "peephole" looking at the code I think that might help improve that small bit of things. | 00:47 |
| rwp | But for other things... Please put a space between the "#include" part and the "<foo.h>" file part. "#include<stdlib.h>" offends my sensibilities. | 00:48 |
| rwp | Also use of signal(2) should be replaced with sigaction(2) throughout. | 00:49 |
| rwp | I haven't see a goto used in code since it was declared the keyword of the damned. I think you don't need it anyway. In both use locations the code is closing the fifo and re-opening it. But that is because there are no more writers on the pipe and so EOF is being returned If there is at least one writer, same issue as one reader, then the read will block instead of return EOF. | 00:52 |
| rwp | That's all the time I have today. I need to take off in five minutes. Gotta fly! | 00:53 |
| Xenguy | Gawdspeed | 00:54 |
| bgstack15 | thanks so much, rwp! I think I can tolerate the suppressed SIGPIPE. I don't want it to block, at all, for any reason. | 01:19 |
| bgstack15 | But this O_RDWR isn't so bad either. | 01:23 |
| rwp | bgstack15, I was taught all about IPC message passing with named pipes by Marc J. Rochkind, Advanced UNIX Programming, Prentice-Hall, 1985. Pages 160 on. | 03:29 |
| rwp | It's an ancient book now and severely dated for details of C and such but the walk through of how the kernel handles pipes is still valid. | 03:29 |
| rwp | If you have a library this is the type of book that might be found there. Or brought over by inter-library loan. | 03:30 |
| rwp | Note that he updated to a 2nd edition though and I think all of that got removed from that second edition. If I can dig up a copy of it I will look. | 03:30 |
| rwp | I can't recommend buying such a book now but I would recommend borrowing it from the library. Perfect for a library loan. | 03:31 |
| rwp | Oh my! Have I got a deal for you. It's so old now that the Internet Archive has it online! https://archive.org/details/advancedunixprog00roch | 03:33 |
| rwp | The Internet Archive is AWESOME! :-) | 03:34 |
| Xenguy | re: Interenet Archive: +1 | 10:00 |
| Xenguy | er, Internet | 10:01 |
| bgstack15 | is the devuan mirror having any issues at the moment? | 21:34 |
| bgstack15 | at deb.devuan.org | 21:35 |
| onefang | https://sledjhamr.org/apt-panopticon/results/Report-web.html says no. | 21:39 |
| onefang | deb.devuan.org is a DNS round robin, so might be one particular mirror that is having trouble at your end. | 21:40 |
| brocashelm | it's usually the tw mirror that fucks up for me | 21:44 |
| brocashelm | blendbyte | 21:44 |
| brocashelm | beard.ly is what i've been using to avoid that issue | 21:45 |
| bgstack15 | I'm going to probably test connecting directly to beard.ly if my current debmirror process fails out. | 21:46 |
| bgstack15 | beard.ly doesn't seem to support https (according to my debmirror invocation), so I'm trying devuan.ipacct.com now which appears to be working | 21:57 |
| onefang | beard.ly passed the HTPS tests from apt-panopticon. | 22:00 |
| bgstack15 | Perhaps debmirror (as packaged on centos 7) is faulty. | 22:00 |
| bgstack15 | Doesn't matter. devuan.ipacct.com is doing what I want. | 22:00 |
| onefang | beard.ly even redirects HTTP to HTTPS. No idea about debmirror. | 22:01 |
| bgstack15 | In this apt+dpkg world, there's many, many ways to duplicate a deb mirror. I had picked debmirror. | 22:02 |
| onefang | You gonna be adding an official Devuan package mirror soon? | 22:02 |
| bgstack15 | No. | 22:06 |
| bgstack15 | I don't do it in the proper Devuan way. | 22:06 |
| bgstack15 | I don't place a ton of apache redirects to Debian files. I download absolutely everything and have an entirely offline, flattened Devuan mirror. | 22:07 |
| onefang | Well only three rewrite rules needed. B-) | 22:09 |
| bgstack15 | Oh, that's right, it uses a DEBIAN/ directory iirc | 22:11 |
| bgstack15 | Still, I want an offline mirror so that I can be entirely decoupled from the Internet and still have full operations. | 22:11 |
| bgstack15 | It has come in handy before. | 22:11 |
| onefang | Fair enough. | 22:11 |
| onefang | Correct. DEVUAN/ DEBIAN/ and DEBIAN-SECURITY/ are the redirects. | 22:12 |
| bb|hcb | bgstack15: devuan.ipacct.comis mine... In case it fails let me know ;) | 22:18 |
| bgstack15 | I check my debmirror logs maybe weekly, and there's always some errors. It matters the most at the beginning of the month when all my systems pull all OS updates. In the past, I've had to run my debmirror script manually 1-8 times, but today it was just straight not ever finding all listed packages. It's like a lot of our public mirrors are not up to date with the package files. | 22:20 |
| bgstack15 | bb|hcb: I will do that. I hope it performs better than the deb.devuan.org round-robin hosts, which are hit-or-miss. | 22:21 |
| onefang | Probably just a timing thing. | 22:21 |
| bgstack15 | I run my daily debmirror at 10:00 UTC | 22:23 |
| onefang | Most of the mirrors update every 30 minutes. | 22:24 |
| onefang | https://sledjhamr.org/apt-panopticon/results/Report-web.html is useful for checking details. In particular the weekly stats for updated. | 22:24 |
| onefang | Beard.ly is currently on 99.31%, devuan.ipacct.com on 100%. | 22:25 |
| bgstack15 | That's probably my problem: I'm probably catching nodes during their upgrade process. | 22:26 |
| bgstack15 | I'm guessing a their debmirror processes take longer than 15 minutes, so they spend the majority of their time in pulling down updates and not having a 100%-correct packages.tgz | 22:27 |
| onefang | I have a TODO to write a mirror update script that pulls down new packages, then pulls down updated metadata, then deletes old packages. Then suggest the other mirror admins switch to it. ZThat'll help | 22:32 |
| onefang | Also, since we are a layer on top of Debian, you also get to trip over the Debian mirrors update windows. | 22:36 |
| bb|hcb | I'd suppose that most problems are with the Debian part, because many mirrors use external stuff for that | 22:38 |
| onefang | I should try to sleep now. The sun is up. | 22:41 |
| brocashelm | night shift? | 22:43 |
| Xenguy | Holiday time maybe; been staying up late myself the last couple of nights | 23:55 |
| Xenguy | Or Vampire Time, nuff said, ahem | 23:56 |
| golinux | onfang is not standard issue. :D | 23:56 |
| golinux | onefang | 23:56 |
| Xenguy | hah, who is, around here? | 23:57 |
| golinux | We are "special" and offtopic | 23:58 |
| Xenguy | aye | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!