Error: Failed to deactivate icu: error deleting "/opt/local/sbin": not owner

[ryandesign (Ryan Carsten Schmidt)]

On the 10.14 buildbot worker, ​deactivating icu fails every time:

--->  Deactivating icu @67.1_2
Error: Failed to deactivate icu: error deleting "/opt/local/sbin": not owner
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_icu-67.1_2_a378da60f280c35e56f278e217bef6dd27e3c615ab268975ca5f6d68bc3b0f9d-8866/icu/main.log for details.
Warning: Failed to execute portfile from registry for icu @67.1_2
--->  Deactivating icu @67.1_2

Well, it says "Failed to deactivate", but in fact it does appear to have been deactivated.

I cannot look at the log file because mpbb cleanup deletes all MacPorts logs.

I only see this on the 10.14 worker and only the icu port seems to be affected.

I'm not sure what's meant by "not owner". The permissions and ownership of /opt/local/sbin look no different than the other directories in /opt/local:

$ ls -l /opt/local/
total 0
drwxr-xr-x    3 root  wheel    96 Aug 20 19:15 Library
drwxr-xr-x    5 root  admin   160 Mar 22  2019 apache22
drwxr-xr-x   42 root  admin  1344 Sep 11 19:56 bin
drwxr-xr-x  124 root  admin  3968 Sep 11 19:56 etc
drwxr-xr-x    8 root  admin   256 Sep 11 19:56 lib
drwxr-xr-x    4 root  admin   128 Sep 11 19:55 libexec
lrwxr-xr-x    1 root  admin     9 Oct  1  2018 man -> share/man
drwxr-xr-x    2 root  admin    64 Sep 11 19:56 sbin
drwxr-xr-x   24 root  admin   768 Sep 11 19:56 share
drwxr-xr-x   20 root  admin   640 Sep 10 19:46 var
drwxr-xr-x    3 root  admin    96 Sep  9 19:26 www

[jmroot (Joshua Root)]

Replying to ryandesign:

Well, it says "Failed to deactivate", but in fact it does appear to have been deactivated.

The deactivate action runs the deactivate target on the Porfile in the registry. That's what's failing. When that fails, the deactivate action then falls back to using registry calls to deactivate the port directly, which is not the preferred option because it can't run any pre- or post-deactivate or -uninstall code.

I cannot look at the log file because mpbb cleanup deletes all MacPorts logs.

That certainly makes it difficult to debug.

[jmroot (Joshua Root)]

It is a bit unusual to be trying to delete ${prefix}/sbin in the first place, since it would normally have at least one file in it.

[ryandesign (Ryan Carsten Schmidt)]

If you are referring to the file .turd_MacPorts, that would only be created if MacPorts had been installed by using the installer pkg but not when it is installed from source.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

That certainly makes it difficult to debug.

I don't think the logs would have been there even if mpbb wasn't deleting them; see #61191.

[ryandesign (Ryan Carsten Schmidt)]

Now that the mpbb scripts have been changed to deactivate ports only before installing dependencies, more or less random builds of ports are now affected by this problem. For example, ​this build of recode failed because:

Error: Failed to deactivate quagga: error deleting "/opt/local/var/quagga": not owner
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_quagga-1.2.4_0_c99f61b5db228d867868415040150082c2ecf1d7200c9c820ca061776f91e715-3315/quagga/main.log for details.
Warning: Failed to execute portfile from registry for quagga @1.2.4_0
--->  Deactivating quagga @1.2.4_0
error deleting "/opt/local/sbin": not owner
    while executing
"::file delete -- $dstfile"
    (procedure "_deactivate_file" line 15)
    invoked from within
"_deactivate_file $file"
    ("foreach" body line 2)
    invoked from within
"foreach file $files {
                    _deactivate_file $file
                }"
    invoked from within
"registry::write {
                $port deactivate $imagefiles
                foreach file $files {
                    _deactivate_file $file
      ..."
    invoked from within
"try {
        # Block the TERM and INT signals to avoid being interrupted. Note that
        # they might already be block at this point because
     ..."
    (procedure "_deactivate_contents" line 39)
    invoked from within
"_deactivate_contents $requested [$requested files] $force"
    (procedure "portimage::deactivate" line 82)
    invoked from within
"portimage::deactivate [$e name] [$e version] [$e revision] [$e variants] [list ports_force yes]"
Deactivating quagga @1.2.4_0 failed: error deleting "/opt/local/sbin": not owner
Processing dependencies for 'recode' failed, aborting.
./mpbb/mpbb: error: `install-dependencies' failed to run successfully

A ​retry of recode succeeds presumably since that time quagga wasn't active before.

I can and maybe should just run the MacPorts installer on all the builders where that wasn't the way MacPorts was initially installed so that they all have the .turd_MacPorts files and hopefully all behave the same way with regard to that.

[jmroot (Joshua Root)]

On the base side, we could look into making more use of precious_dirs in the deactivate code. That would help with /opt/local/sbin but not with /opt/local/var/quagga.

[jmroot (Joshua Root)]

The really interesting question is why deactivating quagga succeeds in the next build after the failure: ​https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/116723/steps/install-dependencies/logs/stdio

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

I can and maybe should just run the MacPorts installer on all the builders where that wasn't the way MacPorts was initially installed so that they all have the .turd_MacPorts files and hopefully all behave the same way with regard to that.

This is now done for Mac OS X 10.6 thru macOS 11 workers.