Rethinking race-free process signaling

Posted Apr 8, 2019 21:51 UTC (Mon) by rweikusat2 (subscriber, #117920)
In reply to: Rethinking race-free process signaling by Cyberax
Parent article: Rethinking race-free process signaling

I don't know where the "pid files" etc hacks originated from but they aren't inherently associated with UNIX process management, just with some people's stubborn refusal to use that properly.

to post comments

Rethinking race-free process signaling

Posted Apr 8, 2019 22:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

The problem is not in pidfiles. It's the whole process management thingie, that is impossible to use safely in many cases.

For example, a general-purpose library can't even do something as simple as create a process and wait for it to finish. This is just ridiculous.

Rethinking race-free process signaling

Posted Apr 9, 2019 14:21 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (5 responses)

Different topic.

"A general purpose library", IOW, some random, binary only code with undefined behaviour (in the sense that no specific behaviour is ever defined when this 'argument' shows up) is a situation which cannot be handled.

Rethinking race-free process signaling

Posted Apr 9, 2019 15:08 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

No, a 'general purpose library' is any library which does not know what its caller is and what its caller expects in regard to process-global or thread-global attributes like the file descriptor table or signal dispositions. This includes most if not all core free software libraries. In particular it includes things like glibc, which cannot do a lot of things in the most obvious way because callers expect to have complete control over signals (except for a tiny set which glibc has reserved *forever* so can keep hold of without breaking existing users) and fds ('loop over lots of fds, close() them all, and hope you got them all' is still a thing a huge number of processes do), and processes, and threads... which makes it more or less impossible for glibc to do anything asynchronous without madness like the shared memory regions used by nscd (which have caused bugs in the past due to programs thinking they can MAP_FIXED in the same place and screaming when they couldn't). I do wonder how many programs the gai_*() APIs, which use threads, have broken -- probably not many since those APIs are Linux-specific and not terribly popular.

Rethinking race-free process signaling

Posted Apr 9, 2019 16:39 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (3 responses)

> fds ('loop over lots of fds, close() them all, and hope you got them all' is still a thing a huge number of processes do),

I have zero qualms about breaking programs that are so obviously broken themselves. You don't free resources you didn't create: that's a rule for any system, not just unix. Just no. Let's no enable programs that break this rule.

Rethinking race-free process signaling

Posted Apr 9, 2019 19:50 UTC (Tue) by roc (subscriber, #30627) [Link]

Applications that launch a securely sandboxed child process need to do this in the child process before they exec. Leaking a file descriptor across the sandbox boundary would be devastating.

Rethinking race-free process signaling

Posted Apr 13, 2019 15:01 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

The problem is that a loop closing the first 1024 fds before exit is incredibly common. Almost everything written before O_CLOEXEC became commonplace does that. Are you willing to break everything written before then? I'm certainly not. People are using those programs.

Rethinking race-free process signaling

Posted Apr 13, 2019 15:58 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

It's less of a problem when the FDs are closed just before exec. Fewer programs randomly close all FDs in steady-state execution, unforked.