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 <vacc...@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 <ea...@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
>
