postflight script's time spent on rsync is not bounded

[velociraptor@…]

Using the GUI package installer hangs @ about 2/3 of the progress bar and does not complete. I was forced to use "force quit" or kill from the terminal.

Looking around in the shell, /opt/local/ and the other filesystem components were there, but the environment additions had not been added, so I assumed it was a problem with the postflight script and used the method mentioned in the "Hot Problems" page to run it. Postflight errored out and I had to manually edit the script to get it to complete.

This is obviously related to defects #14809 and #16199, but I have found additional issues.

a) shell is not recognized ("Unknown shell (sh)!") using:

sudo /bin/bash <path to postflight_script>/postflight <options>

As an aside, looking in the process table, the original postflight script was being called with:

sudo /bin/bash /Volumes/MacPorts-1.7.0/MacPorts-1.7.0.pkg/Contents/Resources/postflight  /Volumes/MacPorts-1.7.0/MacPorts-1.7.0.pkg / / /

(that's three trailing slashes)

b) postflight script errored out when trying to find dep_map_clean.tcl upgrade_sources_conf_default.tcl, due to $TCLSH and $PACKAGE_PATH variables not being set properly. I hard-coded in these for the appropriate path to get the postflight script to run after copying the package to a read/write location.

Thanks.

[jmroot (Joshua Root)]

The unknown shell error is not an additional issue, it's exactly what #16199 is about. It would be nice if you could supply the installer log for the failed attempt. It may have just been taking a long time to do the initial sync.

It's not surprising that the postflight script failed when you ran it manually, since it's only designed to be run from inside the installer. Previous recommendations to run it manually were with an older version, and only to set up .profile with 1.6.0 (which you can always do manually).

[blb@…]

Replying to velociraptor@…:

As an aside, looking in the process table, the original postflight script was being called with:

sudo /bin/bash /Volumes/MacPorts-1.7.0/MacPorts-1.7.0.pkg/Contents/Resources/postflight  /Volumes/MacPorts-1.7.0/MacPorts-1.7.0.pkg / / /

(that's three trailing slashes)

Yes, that's how Apple's installer works, it passes ​four arguments to the script, it just so happens that the way the install works those three arguments are all the root /.

b) postflight script errored out when trying to find dep_map_clean.tcl upgrade_sources_conf_default.tcl, due to $TCLSH and $PACKAGE_PATH variables not being set properly. I hard-coded in these for the appropriate path to get the postflight script to run after copying the package to a read/write location.

TCLSH is set in postflight itself, to /usr/bin/tclsh, so I'm not sure why that wouldn't be set properly; PACKAGE_PATH comes from Apple's installer like the arguments on the command line so running postflight manually means it won't be set unless you set it. Though running it manually was, as jmr said, just a workaround in 1.6.0 and isn't meant to be run that way now.

[testx@…]

Installer log showing this issue.

[testx@…]

I have the same issue here. I've just uploaded my installer log. The last entry there is a "configure" but I don't understand enough about the surrounding text and underlying system to troubleshoot further.

[jmroot (Joshua Root)]

The log ends with rsync still being run. Did you kill the installer at this point?

[testx@…]

No, I didn't kill the installer. But it was stuck there for a long time. I spoke to jmr_mp, and he advised force-quitting the installer and running it again. When I did that, it worked fine. Sheesh!

He suggested that possibly my internet connection got interrupted. It's possible, but I don't think so, since I was on IRC the entire time.

[jmroot (Joshua Root)]

Well, rsync appears to have got stuck for whatever reason. Unfortunately there's no way for the postflight script to tell if rsync is completely stuck or just going really slow.

[velociraptor@…]

I can attempt to re-run the installer after archiving off my existing ports and testing to see what happens again. The first time I attempted to install was over an existing PPC MacPorts install that had been migrated over by the Migration Assistant. That hung at about 1/3. I realized that it was going to leave me with a bunch of stupid work to do, since Mac Ports doesn't check for "arch" just "version" on ports. Rather than trying to come up with a script to fix it, I noted down all my key ports and wiped it and re-installed from scratch.

When I ran the re-install it got to the 2/3 point before it hung.

Unfortunately, I'm not going to have time to do a archive/re-install this week to test, due to work constraints.

Possible ways to test rsync's status would be to either send it's output to another log file and check that for changes, use lsof to check for an open, active ports (lsof -Pni) to the MacPorts repository, or possibly dtrace. Even doing a check of the number of bytes changed on disk at 3 minute intervals would do it. Or at least give the user some idea of how much data needs to be transferred so they can check it themselves.

[BlkDragon96@…]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!