Processes getting wedged in "U" (uninterruptible wait) state after Security Update 2020-003

[Prokash Sinha]

Hi Greg !

If you still have the recent update ( meaning you did not revert yet
), perhaps you can try into recovery boot ( At boot time  Command + R
). When you get to recover mode, somewhere in Utilities, you will see
the terminal -- try disabling it  ( $csrutil disable, then reboot ).

Yes, the security updates are gradually being pushed to MacOS since
10.12 ( before that time, hardly much security was there ). So
sandboxing, CSR, and a whole lot of authorization related stuff (
coming from BSD, after Darwinised).

I think if you disable CSR, it would work ( macports, brew, and other
common utilities can fail, and any binaries in 32 bit will cause havoc
).  Try finding the binary ( Bundle Types ) specially inside of your
macports directory ( somewhere /usr/... ).  $file <filename>. or some
command.

Usually all these 3rd party packages being updated to 64 bits.

Hope it helps!
~pro

On Thu, May 28, 2020 at 5:10 PM Franco Vaccari <vaccari at units.it> wrote:
>
> Hi Greg…
>
> I’m on 10.14.6 and I installed the security update on my MacBook Pro (Retina Mid 2012).  Didn’t face any problem with MacPorts. I don’t use the same ports you are mentioning, but I’ve just installed htop to give it a try, and here it works.
>
> I’m sorry I can’t help more than this, but at least you know it’s not a general problem, and there must be something specific that went broken on your Mini…
>
> Ciao
>
> Franco
>
> > On 29 May 2020, at 01:25, Greg Earle <earle at isolar.DynDNS.ORG> wrote:
> >
> > Hi all,
> >
> > Kind of a long shot here, but given the level of Mac expertise on this list ...
> >
> > At work I have a production Mac mini running macOS Mojave 10.14.6.  It ran perfectly fine - with several MacPorts ports in regular use - until last night.
> >
> > I made the mistake of installing Security Update 2020-003.
> >
> > After the reboot I started noticing things going haywire quickly.
> >
> > - Servers that were running but not listening on their usual ports (or at all)
> >
> > - Servers that were running normally but could not be killed (not even kill -9)
> >
> > - Processes (including MacPorts apps) that get wedged as soon as they run
> >
> > The common thread through all these is that the processes - whether you tried to kill them or run them from scratch - all get wedged in "U" (uninterruptible wait) state.  (Nothing is NFS or CIFS mounted so I doubt it's due to disk I/O.)
> >
> > For example:
> >
> > A COTS product we have uses Postgres as the back-end database; the Postgres server starts at boot time, but it doesn't bind to its normal listening port.  If I try to kill the process, it wedges - just like these other ones do.
> >
> > If I try to run MacPorts' "htop" port ("/opt/local/bin/htop") - it immediately wedges.  I can't even run it under "dtruss" - I get no output at all, like as if it never even gets off the ground to run.
> >
> > (Strangely, the normal system "top" runs fine and doesn't wedge - it also shows these processes as being in "stuck" state, as expected.)
> >
> > If I try to restart MacPorts' Xymon monitoring port (which has several persistent processes started at boot time), one of them, "xymonlaunch", won't quit and it gets wedged in "U" state.
> >
> > I was able to use "gcore" to get a core dump of one of the wedged processes, but when I tried to use the MacPorts "gdb" (/opt/local/bin/ggdb) to examine it, you guessed it ... instantly wedged.
> >
> > In fact, pretty much EVERYTHING in the MacPorts "/opt/local/bin" directory is wedging on me at startup!  I'm completely baffled at this point.
> >
> > Tried running the MacPorts "tree" and "openssl" next.  Stuck.
> >
> > The list of wedged processes is getting impressive:
> >
> > --
> > whdmac:~ root# top -l 1 | egrep STATE\|stuck | sed -e 's/stuck.*/stuck/g' -e 's/STATE.*/STATE/g' -e 's/     //g'
> > Processes: 152 total, 2 running, 5 stuck
> > PID   COMMAND    %CPU TIME     #TH #WQ #PORTS MEM  PURG CMPRS PGRP PPID STATE
> > 993   openssl     0.0  00:00.00 1   0   0     8192B+ 0B 0B    993  1    stuck
> > 973   tree        0.0  00:00.00 1   0   0     8192B+ 0B 0B    973  445  stuck
> > 956   htop        0.0  00:00.00 1   0   0     8192B+ 0B 0B    956  1    stuck
> > 261   xymonlaunch 0.0  00:00.00 1   0   0     8192B+ 0B 0B    246  246  stuck
> > 100   dbus-daemon 0.0  00:00.00 1   0   0     8192B+ 0B 0B    100  1    stuck
> > --
> >
> > I'm resigned to probably having to boot it into Recovery Mode and restore the system from a pre-Security Update 2020-003 Time Machine backup, but I thought I'd run it up the flagpole here first just to see if I was the only person in the world experiencing this.  Maybe this Mac is possessed ...
> >
> >               - Greg
>