libera/#devuan-dev/ Friday, 2022-09-30

bb|hcbLeePen: shall we trigger binNMUs as Debian did?00:33
LeePenbb|hcb: I can't immediately see any forked packages that might have been affected. Can you?08:27
bb|hcbLeePen: 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 everything12:14
LeePenbb|hcb: I don't know an easy way of doing reverse build-depends, but doesn't immediately show anything that might be relevant to forks. Or am I missing something?12:24
LeePenI have just change the backup of amprolla to use the rrsync script rather than sucker user.12:25
LeePenThis means the new keys and revocation certs are backed up correctly.12:25
bb|hcbHm, 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 generated12:29
bgstack15Anybody here do C development? I need some help with kill(2)21:30
amessermore details please.21:31
bgstack15I'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
bgstack15So now I'm storing my pid_child = fork() and want to kill(pid_child, 0)21:32
bgstack15but kill(pid_child,0) always returns 0 even when pid_child is long gone...21:33
bgstack15I thought a fifo would hang until a reader showed up, but my parent process doesn't hang, it straight up exits 14121:34
amesserHm, I would also expect the pipe to stall.21:34
amesserBut 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
bgstack15At one point in gdb I did see something about SIGPIPE21:41
bgstack15thank you, I will research this.21:42
amesserIt 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
amesserThis state is called a zombie process21:42
bgstack15well, 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 entry21:42
bgstack15And 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
bgstack15maybe I could turn off the loop logic for that one system tray icon and save some cpu cycles21:43
amesserDid 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 chapter 1.621:45
bgstack15I'm probably not properly detaching the parent/children. I will look into this as well.21:46
amesserGood luck :-)21:47
bgstack15I'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_c221:48
amesserOk. 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
bgstack15Huh, I was able to suppress sigpipe:22:21
bgstack15signal(SIGPIPE, SIG_IGN);22:21
bgstack15and 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
bgstack15So thank you for your guidance to the info!22:21
amesserhappy to help22:46

Generated by 2.17.0 by Marius Gedminas - find it at!