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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Greg Earle
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
Reply | Threaded
Open this post in threaded view
|

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

Franco Vaccari
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Franco Vaccari
I add to my previous description that on my system, SIP is enabled (just checked with csrutil status), but maybe turning it off will work…

Do you see any error message in console when you launch a process and it get stuck?

Ciao

Franco

> On 29 May 2020, at 02:27, Prokash Sinha <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

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

Franco Vaccari
Since I’ve SIP enabled and no problems, maybe give it a try and enable it… Who knows…

And if you use Console app, you can filter by process name or PID to (maybe) find the messages related to your troubles

Good luck!

Franco


> On 29 May 2020, at 02:41, Greg Earle <[hidden email]> wrote:
>
> On 28 May 2020, at 17:33, Franco Vaccari wrote:
>
>> I add to my previous description that on my system, SIP is enabled (just checked with csrutil status), but maybe turning it off will work…
>
> I already had SIP disabled before I ever installed Security Update 2020-003 ...
>
> whdmac:~ root# csrutil status
> System Integrity Protection status: disabled.
>
>> Do you see any error message in console when you launch a process and it get stuck?
>
> Unfortunately no  :-(
>
> Plus, Console.app output scrolls so fast nowadays, it is hard to read ...
>
> Ciao,
>
> - Greg

Reply | Threaded
Open this post in threaded view
|

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

Greg Earle
On 28 May 2020, at 17:56, Franco Vaccari wrote:

> Since I’ve SIP enabled and no problems, maybe give it a try and
> enable it… Who knows…
>
> And if you use Console app, you can filter by process name or PID to
> (maybe) find the messages related to your troubles

Update:

I've found a post on a Hackintosh site that describes the issue exactly:

https://www.tonymacx86.com/threads/solved-taskgated-service-exited-with-abnormal-code-2.263859/

Every 10 seconds I was getting these error messages in
"/var/log/system.log":

May 29 02:49:05 whdmac com.apple.xpc.launchd[1]
(com.apple.taskgated[394]): Service exited with abnormal code: 2
May 29 02:49:05 whdmac com.apple.xpc.launchd[1] (com.apple.taskgated):
Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

I took the poster's advice and unloaded the 2 "taskgated" LaunchDaemons
and now my MacPorts binaries are working again.  I have no idea why
Security Update 2020-003 broke this particular Mac's "taskgated" but
like the poster it looks like I'll probably have to re-install Mojave to
try and fix it.

Thanks to Franco Vaccari and Prokash Sinha for their kind responses.

        - Greg
Reply | Threaded
Open this post in threaded view
|

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

Franco Vaccari
I would try other options before reinstalling the system, who knows, reinstalling the developer tools, restarting with shift to clean caches, reinstalling the security update, but ok, maybe reinstalling everything from backup may be the easiest…

Let us know how it went…

Franco



> On 29 May 2020, at 12:09, Greg Earle <[hidden email]> wrote:
>
> On 28 May 2020, at 17:56, Franco Vaccari wrote:
>
>> Since I’ve SIP enabled and no problems, maybe give it a try and enable it… Who knows…
>>
>> And if you use Console app, you can filter by process name or PID to (maybe) find the messages related to your troubles
>
> Update:
>
> I've found a post on a Hackintosh site that describes the issue exactly:
>
> https://www.tonymacx86.com/threads/solved-taskgated-service-exited-with-abnormal-code-2.263859/
>
> Every 10 seconds I was getting these error messages in "/var/log/system.log":
>
> May 29 02:49:05 whdmac com.apple.xpc.launchd[1] (com.apple.taskgated[394]): Service exited with abnormal code: 2
> May 29 02:49:05 whdmac com.apple.xpc.launchd[1] (com.apple.taskgated): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
>
> I took the poster's advice and unloaded the 2 "taskgated" LaunchDaemons and now my MacPorts binaries are working again.  I have no idea why Security Update 2020-003 broke this particular Mac's "taskgated" but like the poster it looks like I'll probably have to re-install Mojave to try and fix it.
>
> Thanks to Franco Vaccari and Prokash Sinha for their kind responses.
>
> - Greg

Reply | Threaded
Open this post in threaded view
|

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

Greg Earle
On 29 May 2020, at 4:47, Franco Vaccari wrote:

> I would try other options before reinstalling the system, who knows,
> reinstalling the developer tools, restarting with shift to clean
> caches, reinstalling the security update, but ok, maybe reinstalling
> everything from backup may be the easiest…
>
> Let us know how it went…

Just to summarize the (apparent) solution for the list:

It looks like Security Update 2020-003 changed the "taskgated" plist
file

/System/Library/LaunchDaemons/com.apple.taskgated.plist

It added a single line with a new "-sp" switch:

--
whdmac:~ root# diff -rC 3
/System/Library/LaunchDaemons/*com.apple.taskgated.plist*
***
/System/Library/LaunchDaemons/DO_NOT_USE_com.apple.taskgated.plist_BAD 2020-04-16
21:28:38.000000000 -0700
--- /System/Library/LaunchDaemons/com.apple.taskgated.plist 2019-04-14
18:58:56.000000000 -0700
***************
*** 19,25 ****
    <key>ProgramArguments</key>
    <array>
    <string>/usr/libexec/taskgated</string>
- <string>-sp</string>
    </array>
   </dict>
   </plist>
--- 19,24 ----
--

The trouble is, "taskgated" does not seem to support "-sp":

--
whdmac:/ root# /usr/libexec/taskgated -sp
taskgated: invalid option -- s
Usage: taskgated [-ps] [-t seconds] [-i pid]
--

So, I don't understand why Apple added this switch.

I also don't understand why everyone who installed this Security Update
has not also been affected by this?!?

Anyway, I removed the "-sp" line, rebooted, and now everything works
again - "taskgated" is running and isn't exiting anymore, my Postgres
server is running happily, and my MacPorts binaries are running without
wedging.

Apologies for the slightly off-topic thread ...

                - Greg
Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator
On May 29, 2020, at 07:44, Greg Earle wrote:

> On 29 May 2020, at 4:47, Franco Vaccari wrote:
>
>> I would try other options before reinstalling the system, who knows, reinstalling the developer tools, restarting with shift to clean caches, reinstalling the security update, but ok, maybe reinstalling everything from backup may be the easiest…
>>
>> Let us know how it went…
>
> Just to summarize the (apparent) solution for the list:
>
> It looks like Security Update 2020-003 changed the "taskgated" plist file
>
> /System/Library/LaunchDaemons/com.apple.taskgated.plist
>
> It added a single line with a new "-sp" switch:
>
> --
> whdmac:~ root# diff -rC 3 /System/Library/LaunchDaemons/*com.apple.taskgated.plist*
> *** /System/Library/LaunchDaemons/DO_NOT_USE_com.apple.taskgated.plist_BAD 2020-04-16 21:28:38.000000000 -0700
> --- /System/Library/LaunchDaemons/com.apple.taskgated.plist 2019-04-14 18:58:56.000000000 -0700
> ***************
> *** 19,25 ****
>   <key>ProgramArguments</key>
>   <array>
>   <string>/usr/libexec/taskgated</string>
> - <string>-sp</string>
>   </array>
>  </dict>
>  </plist>
> --- 19,24 ----
> --
>
> The trouble is, "taskgated" does not seem to support "-sp":
>
> --
> whdmac:/ root# /usr/libexec/taskgated -sp
> taskgated: invalid option -- s
> Usage: taskgated [-ps] [-t seconds] [-i pid]
> --
>
> So, I don't understand why Apple added this switch.
>
> I also don't understand why everyone who installed this Security Update has not also been affected by this?!?
>
> Anyway, I removed the "-sp" line, rebooted, and now everything works again - "taskgated" is running and isn't exiting anymore, my Postgres server is running happily, and my MacPorts binaries are running without wedging.
>
> Apologies for the slightly off-topic thread

Possibly off-topic, but if an Apple update causes problems for MacPorts users we do want to know about it in case it's something we need to address in MacPorts.



If taskgated behaves like other normal command line programs, then the flag `-sp` should be equivalent to the flags `-s` and `-p`. (Apple command line programs often aren't like other programs, erroneously using a single dash where they mean to use a double dash, but I don't think taskgated is one of those programs.)



I checked my High Sierra system. According to `man taskgated` it does support the `-s` flag but not the `-p` flag:

> SYNOPSIS
>      taskgated [-s] [-t timeout] [-i pid]

The description of the `-s` flag is:

>      -s       Allow signed applications marked as "safe" to have free access to task ports, without having to pass an authorization check. Note that such callers must be marked both allowed and safe.


There is a note at the bottom that says:

>      Procmod and procview support (-p) was removed in 10.11.


On High Sierra, the com.apple.taskgated.plist file specifies the `-s` flag.



Checking on Mojave and Catalina systems, the taskgated manpage still shows that the `-s` flag is supported but the description of that flag has disappeared. The launchd plist does not specify any flags anymore.

If I try, similar to what you did, to run `/usr/libexec/taskgated -s` I get the same result as you: the message that "s" is an invalid option, despite what the manpage says, and despite the following usage message showing both the "s" and "p" options as supported. I guess Apple forgot to update the manpage and the usage message.



So I'm not sure how the `-sp` flags got into your launchd plist again when they're not supported anymore. Maybe Apple made a mistake in the security update. If so, I'd expect them to reissue it. If they do, the macOS build number should change. I'm running Mojave 10.14.6 build 18G5033. How about you? If you're running less than that, run Software Update again, or try downloading the security update from Apple's web site.

Alternately, is it possible that you edited the plist file yourself to add the -sp flags? MacPorts used to have instructions in the notes of the gdb port telling users to add the -p flag to the existing -s flag since this was required for gdb to work in OS X 10.10. We removed those instructions some years ago since they were no longer helpful in OS X 10.11 and later but maybe you found and followed similar instructions elsewhere on the Internet, or you ran some installer or script that edited it for you. On my Mojave system, the plist hasn't been modified since 2018-08-21, but you showed that on your system it was modified on 2020-04-16. Of course, editing that file manually would require disabling System Integrity Protection. Have you disabled SIP? If so, consider reenabling it to protect your system from unwanted modifications.



Reply | Threaded
Open this post in threaded view
|

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

Prokash Sinha
In reply to this post by Greg Earle
First, I'm not sure how they are parsing . I see -sp, but the help is
showing -ps. Here is a link for this
---https://www.manpagez.com/man/8/taskgated/

You know that taskgated is a daemon launched by launchctl service -
which more like crond. Now comes the - task_for_pid () functionality.
From 10.14 Apple did restrict accesses to XPC ports, which is the core
IPC on darwin. Basically any program tries to access task_for_pid()
will fail from that version onward, but in this case SIP is disabled
the booting from a different image ( internally). ___ So I think Apple
made a mistake while they were pushing out the beta. It's not unusual.
I've seen many times.

Catalina ( 10.15.N) will have more restrictions, 10.16 will have
different 3rd party supports ( kext, kernel pseudo drivers will not be
loaded, unless they allow, based on specific notarization - yet to be
seen ).

So if your machines are being used ( or a part of some infrastructure
) by many people, backup/downtime/migration/etc seems to be logical
path.

~pro

On Fri, May 29, 2020 at 5:44 AM Greg Earle <[hidden email]> wrote:

>
> On 29 May 2020, at 4:47, Franco Vaccari wrote:
>
> > I would try other options before reinstalling the system, who knows,
> > reinstalling the developer tools, restarting with shift to clean
> > caches, reinstalling the security update, but ok, maybe reinstalling
> > everything from backup may be the easiest…
> >
> > Let us know how it went…
>
> Just to summarize the (apparent) solution for the list:
>
> It looks like Security Update 2020-003 changed the "taskgated" plist
> file
>
> /System/Library/LaunchDaemons/com.apple.taskgated.plist
>
> It added a single line with a new "-sp" switch:
>
> --
> whdmac:~ root# diff -rC 3
> /System/Library/LaunchDaemons/*com.apple.taskgated.plist*
> ***
> /System/Library/LaunchDaemons/DO_NOT_USE_com.apple.taskgated.plist_BAD  2020-04-16
> 21:28:38.000000000 -0700
> --- /System/Library/LaunchDaemons/com.apple.taskgated.plist     2019-04-14
> 18:58:56.000000000 -0700
> ***************
> *** 19,25 ****
>         <key>ProgramArguments</key>
>         <array>
>                 <string>/usr/libexec/taskgated</string>
> -               <string>-sp</string>
>         </array>
>    </dict>
>    </plist>
> --- 19,24 ----
> --
>
> The trouble is, "taskgated" does not seem to support "-sp":
>
> --
> whdmac:/ root# /usr/libexec/taskgated -sp
> taskgated: invalid option -- s
> Usage: taskgated [-ps] [-t seconds] [-i pid]
> --
>
> So, I don't understand why Apple added this switch.
>
> I also don't understand why everyone who installed this Security Update
> has not also been affected by this?!?
>
> Anyway, I removed the "-sp" line, rebooted, and now everything works
> again - "taskgated" is running and isn't exiting anymore, my Postgres
> server is running happily, and my MacPorts binaries are running without
> wedging.
>
> Apologies for the slightly off-topic thread ...
>
>                 - Greg
Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator
On May 29, 2020, at 09:04, Prokash Sinha wrote:

> First, I'm not sure how they are parsing . I see -sp, but the help is
> showing -ps. Here is a link for this
> ---https://www.manpagez.com/man/8/taskgated/

That is the manual for taskgated on Mac OS X 10.6. Things have changed singe then; see my previous message in this thread.

Reply | Threaded
Open this post in threaded view
|

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

Prokash Sinha
Yes indeed, Ryan...

Usage: taskgated [-ps] [-t seconds] [-i pid]

Jinbors-MacBook-Air:LaunchDaemons prokash$ sw_vers

ProductName: Mac OS X

ProductVersion: 10.15.5

BuildVersion: 19F62f

Frankly speaking, I burnt my finger tackling some of these from a
kernel developer's perspective. get_task_for_pid() etc.

As I mentioned, a beta pushed out in the morning and another in the
eventing of the same day, make huge difference. Since tailgate daemon
is theirs, I think they made a mistake. If someones systems work,
another's don't, best way to look at the BuildVersion of the patch
applied.

Macports, brew, jams, autotools, gnu gcc  etc., can get broken some
time, and more so from July this year. VMware Fusion was broken for
sometime when they pushed 10.15 out in the market.

iPhone OS's security area is being brought down to other OS they have.

~pro

On Fri, May 29, 2020 at 7:07 AM Ryan Schmidt <[hidden email]> wrote:
>
> On May 29, 2020, at 09:04, Prokash Sinha wrote:
>
> > First, I'm not sure how they are parsing . I see -sp, but the help is
> > showing -ps. Here is a link for this
> > ---https://www.manpagez.com/man/8/taskgated/
>
> That is the manual for taskgated on Mac OS X 10.6. Things have changed singe then; see my previous message in this thread.
>
Reply | Threaded
Open this post in threaded view
|

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

dan d.
In reply to this post by Greg Earle
Not if he only wats confirmation the wifi signal is presentt.  The friend will see it as available or not.

On Fri, 29 May 2020, Franco Vaccari wrote:

> Since I???ve SIP enabled and no problems, maybe give it a try and enable it??? Who knows???
>
> And if you use Console app, you can filter by process name or PID to (maybe) find the messages related to your troubles
>
> Good luck!
>
> Franco
>
>
> > On 29 May 2020, at 02:41, Greg Earle <[hidden email]> wrote:
> >
> > On 28 May 2020, at 17:33, Franco Vaccari wrote:
> >
> >> I add to my previous description that on my system, SIP is enabled (just checked with csrutil status), but maybe turning it off will work???
> >
> > I already had SIP disabled before I ever installed Security Update 2020-003 ...
> >
> > whdmac:~ root# csrutil status
> > System Integrity Protection status: disabled.
> >
> >> Do you see any error message in console when you launch a process and it get stuck?
> >
> > Unfortunately no  :-(
> >
> > Plus, Console.app output scrolls so fast nowadays, it is hard to read ...
> >
> > Ciao,
> >
> > - Greg
>
>

--
XR