bb|hcb | LeePen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000421 shall we trigger binNMUs as Debian did? | 00:33 |
---|---|---|
LeePen | bb|hcb: I can't immediately see any forked packages that might have been affected. Can you? | 08:27 |
bb|hcb | LeePen: I didn't check, that is why I raise the topic... My thinking was that checking and rebuilding a few would be much more effort than rebuilding everything | 12:14 |
LeePen | bb|hcb: I don't know an easy way of doing reverse build-depends, but https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+cppcheck&perpkg=1 doesn't immediately show anything that might be relevant to forks. Or am I missing something? | 12:24 |
LeePen | I have just change the backup of amprolla to use the rrsync script rather than sucker user. | 12:25 |
LeePen | This means the new keys and revocation certs are backed up correctly. | 12:25 |
bb|hcb | Hm, I saw much more packages rebuilt; some of mine do not mention cppcheck at all. As far as I understand the problem is with wrong shared lib deps generated | 12:29 |
bgstack15 | Anybody here do C development? I need some help with kill(2) | 21:30 |
amesser | ? | 21:30 |
amesser | more details please. | 21:31 |
bgstack15 | I'm doing really dangerous stuff with named pipes, (not negotiable) and apparently if I fprintf to my named pipe where the reader has now exited, the parent process immediately exits with ec 141 which I haven't yet deciphered. | 21:32 |
bgstack15 | So now I'm storing my pid_child = fork() and want to kill(pid_child, 0) | 21:32 |
bgstack15 | but kill(pid_child,0) always returns 0 even when pid_child is long gone... | 21:33 |
bgstack15 | I thought a fifo would hang until a reader showed up, but my parent process doesn't hang, it straight up exits 141 | 21:34 |
amesser | Hm, I would also expect the pipe to stall. | 21:34 |
amesser | But your porcess might see a signal when the other side closes. Try installing a signal handler for SIGPIPE. | 21:39 |
amesser | (See man 2 write, EPIPE error) | 21:40 |
bgstack15 | At one point in gdb I did see something about SIGPIPE | 21:41 |
bgstack15 | thank you, I will research this. | 21:42 |
amesser | It could be, that the process killed by SIGPIPE is in a floating state. I think a parent process must collect a forked process information before its cleared from meory. | 21:42 |
amesser | This state is called a zombie process | 21:42 |
bgstack15 | well, the child process runs Gtk_main() for a system tray icon, so it's going to stick around until I kill it from a menu entry | 21:42 |
bgstack15 | And I don't actually care anything about the child process. If the user closes the tray icon, I just want the stuff going to the named pipe to [not error] disappear quietly. | 21:43 |
amesser | https://en.wikipedia.org/wiki/Zombie_process | 21:43 |
bgstack15 | maybe I could turn off the loop logic for that one system tray icon and save some cpu cycles | 21:43 |
amesser | Did you properly detach your parent from the child? I barely remind that there is more to do than just forking. For daemon processes you typically do a double fork. | 21:44 |
amesser | http://www.faqs.org/faqs/unix-faq/programmer/faq/ chapter 1.6 | 21:45 |
bgstack15 | I'm probably not properly detaching the parent/children. I will look into this as well. | 21:46 |
amesser | Good luck :-) | 21:47 |
bgstack15 | I'm not sure I want the child processes actually moved to ppid=1. I wouldn't mind the process tree showing ppid owning both pid_c1 and pid_c2 | 21:48 |
amesser | Ok. So then you should probably have a look at SIGPIPE and SIGCHLD signal handlers. I think yoy just need to register an empty one for SIGPIPE to avoid beeing killed when writing to the closed pipe. | 21:50 |
bgstack15 | Huh, I was able to suppress sigpipe: | 22:21 |
bgstack15 | signal(SIGPIPE, SIG_IGN); | 22:21 |
bgstack15 | and now my child processes (upon getting past that gtk_main() part) kill(ppid, SIGUSR1) and I count SIGUSR1 with a handler and then when both child processes send that signal, the parent quits. | 22:21 |
bgstack15 | So thank you for your guidance to the info! | 22:21 |
amesser | happy to help | 22:46 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!