Killing processes that don't want to die

Posted May 29, 2018 7:44 UTC (Tue) by k8to (guest, #15413)
In reply to: Killing processes that don't want to die by smurf
Parent article: Killing processes that don't want to die

The main upside to the ancient posix behavior is often someone wrote down a clear explanation of the behavior (typically R Stevens). The new interfaces coming along tend to have an out of date text file somewhere or a half-maintained website that eventually goes offline.

Otherwise, sure, strict compliance with a spec that isn't really living anymore doesn't seem very valuable.

to post comments

Killing processes that don't want to die

Posted May 29, 2018 14:37 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (9 responses)

This is just a question: as a sysadmin, I've been spoiled by POSIX and Linux's attempts to keep within its specifications. As you say, I have nice documentation on expected behaviors, when I need it for that wonderful 3:37 AM troubleshooting call. :)

I see at https://en.wikipedia.org/wiki/POSIX that indeed, there is some modern work (2017?), but is that work just whistling past the graveyard? Is there something waiting in the wings to replace POSIX? Or is that what the JVM is now for (as a "standard system interface"). (I'm half-joking with the last one, but I'm in a world of web and mobile commercial apps where few with the money or authority apparently care what is running between the metal and the application... and the JVM under Linux seems like the worst of both worlds, at least from a troubleshooting perspective.)

Killing processes that don't want to die

Posted May 29, 2018 15:13 UTC (Tue) by k8to (guest, #15413) [Link] (1 responses)

In industry, I find most people want to pretend the operating system isn't a matter of much concern anymore. Various abstractions should make it go away, for example no one wants to see what's going wrong with software, just reboot the VM/container programmatically with more software.

In the opengroup docs, scanning for "what changed in here for POSIX.1-2017" which seems to be forming into SUS2018, I find items like:

"The UUCP utilities option is added."

It seems like mostly "a clarifying type was added to these two arguments to one function" is a pretty big change for this update. Mostly it seems like it's a matter of officially dropping already deprecated things.

The most significant set of changes appear to be here:

http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_x...

They seem to have sort of unbroken locale a bit, by letting the program ask for an answer in a specific locale.
the *at set of functions are moved from some kind of API annex to the main spec.

It's difficult to figure out what's truly new.

Killing processes that don't want to die

Posted Sep 25, 2018 2:29 UTC (Tue) by lukeshu (guest, #105612) [Link]

That page is a bit confusing in what it is and what it's describing. It's describing the major changes between POSIX Issue 6 (AKA POSIX-2001) and POSIX Issue 7 (AKA POSIX-2008).

So where do 2017 & 2018 come in on that page? POSIX Issue 7 has had several "bugfix" releases since it was released in 2008. The most recent of which was "1003.1-2017", which didn't actually become official until January 2018.

There are real changes and additions being worked on by the POSIX committee, but they won't show up in a "bugfix" release to Issue 7, they're being held until Issue 8. I'm unsure what the release timeline looks like for Issue 8.

Killing processes that don't want to die

Posted May 29, 2018 15:45 UTC (Tue) by k8to (guest, #15413) [Link]

Or comparably, do you find the opengroup docs very readable? I don't. They're not bad for what they are, but I find them laborious to follow and missing information about purpose and intent.

Basically the value to me as a higher level user of computer systems is that someone has created more digestible information that contains what is in them and more. Is anyone doing that anymore with libc & system calls?

For example, I can work out for myself that call_l(..., locale_choice) allows me to to write code that doesn't break when someone creates a goofy set of env vars, but can most modern developers work that out on their own with the information provided in POSIX? I'd expect not.

Killing processes that don't want to die

Posted May 29, 2018 19:15 UTC (Tue) by xtifr (guest, #143) [Link] (5 responses)

The replacement is basically SUS (the Single Unix Specification).

The big things that changed are that 1. VMS died, and 2. the Open Group took over the Unix trademark. Which means, modern OSes can basically be divided into two families: Unix-like, which includes Linux and MacOS, and Microsoft. So we no longer need a watered-down "in-between" standard like Posix. Microsoft (unlike DEC) just doesn't care, and everyone else just went ahead and became a more-or-less "real" Unix.

Single Unix

Posted May 30, 2018 16:58 UTC (Wed) by marcH (subscriber, #57642) [Link] (4 responses)

> So we no longer need a watered-down "in-between" standard like Posix.

What are the difference today between "POSIX" and "Single Unix"? Only the former is available on line? :-)

Single Unix

Posted Jun 1, 2018 13:30 UTC (Fri) by jschrod (subscriber, #1646) [Link] (2 responses)

Download the latter at https://publications.opengroup.org/t101

Single Unix

Posted Jun 1, 2018 18:32 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

Sorry I meant: only the latter is behind a registration/paywall? (which?)

This was just a side and half-joke actually, I don't really care that much. My more important question is: what are in a nutshell the *technical* differences between today's POSIX and today's Single Unix? Assuming of course these can fit in a nutshell. For instance: is Single Unix just a new name fancy name for what could have been just called POSIX 2018? Or is POSIX is an outdated and significantly smaller subset of Single Unix? Are the exact same players shooting again? Etc.

xtifr seemed to know much more than he shared.

Single Unix

Posted Jun 1, 2018 20:00 UTC (Fri) by jschrod (subscriber, #1646) [Link]

> Sorry I meant: only the latter is behind a registration/paywall? (which?)

registration

> what are in a nutshell the *technical* differences between today's POSIX and today's Single Unix?

POSIX is a part of SUS.

In fact, current POSIX publication is also done by OpenGroup; e.g. http://pubs.opengroup.org/onlinepubs/9699919799/nframe.html is POSIX.1-2017, which is the most important part of SUS Version 4.

Single Unix

Posted Sep 25, 2018 2:41 UTC (Tue) by lukeshu (guest, #105612) [Link]

Back in the day, there were many differences between SUS and POSIX, but today SUS is just POSIX+Curses. SUSv4 is literally a document set (Open Group T101) of two separate documents; Open Group C165 (POSIX-2008, 2016 edition), and Open Group C094 (X/Open Curses, Issue 7).