4 ms·

Option 1 explicitly discusses using pipes, which aren't hugely easier than sockets. The downsides of overloading sigstop have been fairly widely discussed.

by mjg59 12y ago

mzs 12y ago
I was responding to, "Rather than requiring library code to notify systemd that the daemon is ready, use some existing trivial method." It's even simpler and as a bonus the SIGSTOP approach is compatible with upstart. But for a pipe it does get more complicated. Do you have sscanf? How about strtol? Should you use atoi? Might want to just roll a for loop of your own for three digit integers say. Or what if the other end of the pipe was closed? I have to ignore SIGPIPE. Should I use sigaction? Well signal should always be there. But is my daemon multithreaded? Shoot, looks like I have to fork and immediately exec a helper that does the write. See where this is going? And the code someone linked to here for sd_notify style socket communication instead of linking with systemd (you are using pkgtools right?) used MSG_NOSIGNAL precisely for these signal issues. Guess what, it was different in Linux before 2.2 or something, can't remember the details. Also it's different in some FreeBSD versions as well. I'm pretty sure it was different on Darwin. I can't remember about Solaris. HPUX? AIX? Your guess is as good as mine. It's a portability PITA. Anyway, I really really dig the simplicity of raise(SIGSTOP). Also yes there are some detriments to overloading the use of SIGSTOP like this, maybe a small performance one, and maybe there is some concern another root process could use kill to send it SIGSTOP. But I think the simplicity and reliability outweighs all that stuff I mentioned above if you go for a robust portable alternative using a pipe or socket. Plus I can make arguments in a similar vein about the environment variable that systemd uses internally which is not pretended with something like "SYSTEMD_" or "_" even, but I wouldn't cause it's just as silly as complaining about the detriments of using a signal in my mind.
- bkor 12y ago
  Overloading SIGSTOP means the meaning of SIGSTOP changes, yet you say it will be reliable? Not very predictable behaviour. Also probably not UNIX like ;)

Option 1 explicitly discusses using pipes, which aren't hugely easier than sockets. The downsides of overloading sigstop have been fairly widely discussed.

by mjg59 12y ago

Option 1 explicitly discusses using pipes, which aren't hugely easier than sockets. The downsides of overloading sigstop have been fairly widely discussed.

mzs 12y ago

I was responding to, "Rather than requiring library code to notify systemd that the daemon is ready, use some existing trivial method." It's even simpler and as a bonus the SIGSTOP approach is compatible with upstart. But for a pipe it does get more complicated. Do you have sscanf? How about strtol? Should you use atoi? Might want to just roll a for loop of your own for three digit integers say. Or what if the other end of the pipe was closed? I have to ignore SIGPIPE. Should I use sigaction? Well signal should always be there. But is my daemon multithreaded? Shoot, looks like I have to fork and immediately exec a helper that does the write. See where this is going? And the code someone linked to here for sd_notify style socket communication instead of linking with systemd (you are using pkgtools right?) used MSG_NOSIGNAL precisely for these signal issues. Guess what, it was different in Linux before 2.2 or something, can't remember the details. Also it's different in some FreeBSD versions as well. I'm pretty sure it was different on Darwin. I can't remember about Solaris. HPUX? AIX? Your guess is as good as mine. It's a portability PITA. Anyway, I really really dig the simplicity of raise(SIGSTOP). Also yes there are some detriments to overloading the use of SIGSTOP like this, maybe a small performance one, and maybe there is some concern another root process could use kill to send it SIGSTOP. But I think the simplicity and reliability outweighs all that stuff I mentioned above if you go for a robust portable alternative using a pipe or socket. Plus I can make arguments in a similar vein about the environment variable that systemd uses internally which is not pretended with something like "SYSTEMD_" or "_" even, but I wouldn't cause it's just as silly as complaining about the detriments of using a signal in my mind.

bkor 12y ago
Overloading SIGSTOP means the meaning of SIGSTOP changes, yet you say it will be reliable? Not very predictable behaviour. Also probably not UNIX like ;)