Office 2011 SP2 waiting at "Finishing"

[Timothy Sutton]

I've just tried two different install scenarios of Office 2011 SP2 in Munki:

1) My own desktop running 10.7, doing the install in a logged-in session, build 1473 and

2) A freshly-imaged test machine with our standard 10.6 image, doing the install at the loginwindow, build 1363

Both went from 14.1.4 to 14.2.0. On both, I'm seeing "Finishing the Installation…" at the MSU dialog for a long time.

In install.log, I don't see anything out of the ordinary. Wondering if anyone else is seeing the same?

The last lines of ManagedSoftwareUpdate.log are:

Apr 12 15:43:41 Registering updated applications…
Apr 12 15:43:42 Registering updated applications…
Apr 12 15:43:42 Registering updated applications…
Apr 12 15:43:43 Registering updated applications…
Apr 12 15:43:43 Registering updated applications…
Apr 12 15:43:44 Validating packages…
Apr 12 15:43:44 Running installer actions…
Apr 12 15:43:44 Finishing the Installation…

And a larger chunk of the end of the install.log:

Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.readme.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.core_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.core_themes.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.ooxml.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.sounds.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.clipart.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.clipart_search9.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.equationeditor_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.graph_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.silverlight.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.flip4mac.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.langregister.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.sharepointbrowserplugin_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.word_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.word_templates.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.word_wizards.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.excel_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.excel_templates.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.excel_webqueries.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.query.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.solver.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.powerpoint_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.powerpoint_templates.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.powerpoint_guidedmethods.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.outlook_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.outlook_scriptmenuitems.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.vb_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.proofing_english.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.proofing_french.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.dcc_resources.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.fonts.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.fonts_fontcollection.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.automator.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.en.automator_workflow.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.equationeditor.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.graph.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.sharepointbrowserplugin.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.word.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.excel.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.powerpoint.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.outlook.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.vb.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.dcc.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Writing receipt for com.microsoft.office.all.core.pkg.14.2.0.update to /private/var/db/receipts
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Clip%20Gallery.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Database%20Daemon.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Database%20Utility.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Office%20Reminders.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Upload%20Center.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Open%20XML%20for%20Excel.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Equation%20Editor.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Graph.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Additional%20Tools/Microsoft%20Language%20Register/Microsoft%20Language%20Register.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Word.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Excel.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Query.app/
Apr 12 15:43:41 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Add-Ins/Solver.app/
Apr 12 15:43:42 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20PowerPoint.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Outlook.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/My%20Day.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Document%20Connection.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Equation%20Editor.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Graph.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Word.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Excel.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20PowerPoint.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Outlook.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/My%20Day.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Microsoft%20Document%20Connection.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Office%20Reminders.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/SyncServicesAgent.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Chart%20Converter.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Database%20Utility.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Database%20Daemon.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Clip%20Gallery.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Upload%20Center.app/
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Alerts%20Daemon.app/
Apr 12 15:43:43 tim-imac installd[10940]: Installed "Office 2011 14.2.0 Update" ()
Apr 12 15:43:43 tim-imac installd[10940]: PackageKit: ----- End install -----
Apr 12 15:43:44 tim-imac installer[10683]: Running install actions
Apr 12 15:43:44 tim-imac installer[10683]: Removing temporary directory "/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T//Install.10683RICdIh"
Apr 12 15:43:44 tim-imac installer[10683]: Finalize disk "Macintosh HD"
Apr 12 15:43:44 tim-imac installer[10683]: Notifying system of updated components
Apr 12 15:43:44 tim-imac installer[10683]:
Apr 12 15:43:44 tim-imac installer[10683]: **** Summary Information ****
Apr 12 15:43:44 tim-imac installer[10683]: Operation Elapsed time
Apr 12 15:43:44 tim-imac installer[10683]: -----------------------------
Apr 12 15:43:44 tim-imac installer[10683]: disk 0.01 seconds
Apr 12 15:43:44 tim-imac installer[10683]: script 0.00 seconds
Apr 12 15:43:44 tim-imac installer[10683]: zero 0.03 seconds
Apr 12 15:43:44 tim-imac installer[10683]: install 30.55 seconds
Apr 12 15:43:44 tim-imac installer[10683]: -total- 30.59 seconds
Apr 12 15:43:44 tim-imac installer[10683]:

[Greg Neagle]

I'm seeing that as well.

Doing a `ps axwww`, I see a zombie (installer) process and a suspicious script still running:

7985 ?? Z 0:00.00 (installer)
8064 ?? S 0:00.25 /bin/sh /private/tmp/dmg.b4SpfY/Office 2011 14.2.0 Update.pkg/Contents/Resources/clean_path 7985 /private/tmp/com.microsoft.updater.root.1334263904381

So let's look at that script:

#!/bin/sh

pid="$1"
path="$2"
delay="$3"

if [ "$delay" == "" ]
then
delay="1"
fi

while [ $(/bin/ps -o pid -p"$pid" | /usr/bin/grep "$pid" | /usr/bin/awk '{print $1}') ]
do
/bin/sleep "$delay"
done

if [ -e "$path" ]
then
if [ "$path" != "/" ]
then
/bin/rm -rf "$path"
fi
fi

/usr/bin/whoami | /usr/bin/grep root &> /dev/null
status=$?
if [ $status == 0 ]
then
plist=/tmp/com.microsoft.updater.root.plist
else
plist=/tmp/com.microsoft.updater.user.plist
fi
if [ -e "$plist" ]
then
/bin/rm -rf "$plist"
fi

exit 0

Oh, dear.

The purpose of the script seems to be to remove a couple of temp files or directories after the installer exits.

The script is checking for the PID 7985, which is the installer process that has been zombied. It loops - if the PID is in the output of ps, it sleeps one second and checks again. As long as the installer process stays in the process table, the script will never exit.

If the PID does disappear from the process table, the second parameter to the script, in this case "/private/tmp/com.microsoft.updater.root.1334263904381" is recursively removed. Looking at the contents of this directory, it contains a bunch of symlinks to the found location of the Microsoft Office 2011 folder and symlinks to the subpackages of the update.

Finally, it removes either /tmp/com.microsoft.updater.user.plist or if we are running as root, /tmp/com.microsoft.updater.root.plist:

defaults read /tmp/com.microsoft.updater.root
{
"com.microsoft.updater" = "/tmp/com.microsoft.updater.root.1334263904381";
}

That's the same directory the script removed earlier.

Since all of this is stuff sitting in /tmp, which is cleaned up on reboot, it is not vital that this removal actually happen, so finding and removing this script from the metapackage should prevent this issue.

I suspect this is _not_ a munki-specific problem; I suspect that any command-line installs of this metapackage will trigger the issue.

Still investigating...

-Greg

[Greg Neagle]

The relevant scripts are in Office 2011 14.2.0 Update.pkg/Contents/Resources/ and are invoked by JavaScript calls inside the distribution.dist file.

So the problem is not (directly) with the clean_path script, as variations of it have been in use since at least the 14.0.1 update.

But this script is launched by the volume_updatable script. In the 14.1.4 and earlier updates, this script was launched only if the GUI Installer was used to install the update. But the 14.2.0 update tries to be more clever (this is Python, using the deprecated popen2 module):

r,w = popen2.popen2("/bin/ps -o pid,command -ax | /usr/bin/grep -e 'installer.*-pkg' | /usr/bin/grep -v grep | /usr/bin/awk '{print $1}'")
w.close()
installer_pid = r.read().rstrip('\n')
r.close()
temp_path = os.path.join(target_volume, kUpdaterTempLocation.lstrip('/'))
if installer_pid:
print "Found command line installer, spawning %s %s %s..." % (clean_path_exe, installer_pid, temp_path)
os.spawnv(os.P_NOWAIT, clean_path_exe, [clean_path_exe, installer_pid, temp_path])

I still don't understand why the installer process is not cleanly exiting after installation; I can't reproduce this issue when running this from the shell, like:

installer -target / -pkg /Volumes/Microsoft\ Office\ 2011\ 14.2.0\ Update/Office\ 2011\ 14.2.0\ Update.pkg

It seems possibly relevant that when this is happening, at the same time hdiutil is trying to unmount the disk image, but can't because there are busy files.

Anybody else got anything to add?

-Greg

[Rob Middleton]

Greg,

in munki's installer.py:

# run installer, setting the program id of the process (all child
# processes will also use the same program id), making it easier to kill
# not only hung installer but also any child processes it started.
proc = munkicommon.Popen(cmd, shell=False, bufsize=1, env=env_vars,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
preexec_fn=lambda: os.setpgid(
os.getpid(), os.getpid()))

What does "same program id" mean?

Rob.

[Greg Neagle]

Ccing Justin and John; one of them added that bit of code.

Sent from my iPhone

[William Smith]

On Thursday, April 12, 2012 7:02:43 PM UTC-5, gregn...@mac.com wrote:

Anybody else got anything to add?

Casper folks are having problems as well. I tested using Apple's command line "installer" on Snow Leopard and Lion machines and the package won't install. I've escalated this to my contacts at Microsoft and pointed them to this thread. Very insightful stuff.

Note that the package is shipped as a .pkg. file and not a .mpkg. Yet it contains .pkg sub-packages. It's not a flat package. Not sure what's going on here.

[Greg Neagle]

Thanks for the info. Reading through the discussion on JAMFNation, I'm not sure if the issue with Casper is the exact same issue that we're seeing with Munki, but it's likely to be related.

-Greg

[Confusion]

I am having an issue where i installed it via the dog on a lab machine
and the install went ahead fine and finished.
However when you open an office app it wants you to put in a
registration code, purchase a code online, Or click to use a 30 day
trial.

We have an education copy of office that does not have a registration
code. Has anybody else had this issue?

[Confusion]

i like how 10.7 changes dmg to dog for you if you are not paying
attention

On Apr 13, 2:01 pm, Confusion <nicoipho...@gmail.com> wrote:
> I am having an issue where i installed it via the dog on a lab machine
> and the install went ahead fine and finished.

> However when you open anofficeapp it wants you to put in a

> registration code, purchase a code online, Or click to use a 30 day
> trial.
>

> We have an education copy ofofficethat does not have a registration

[Justin McWilliams]

On Fri, Apr 13, 2012 at 8:43 AM, Rob Middleton <rrmid...@gmail.com> wrote:
> Greg,
>
> in munki's installer.py:
>
>    # run installer, setting the program id of the process (all child
>    # processes will also use the same program id), making it easier to kill
>    # not only hung installer but also any child processes it started.
>    proc = munkicommon.Popen(cmd, shell=False, bufsize=1, env=env_vars,
>                             stdin=subprocess.PIPE,
>                             stdout=subprocess.PIPE,
>                             stderr=subprocess.STDOUT,
>                             preexec_fn=lambda: os.setpgid(
>                                 os.getpid(), os.getpid()))
>
> What does "same program id" mean?

Per pydoc for the os module, I think that should read "process group id":

http://docs.python.org/library/os.html
"""
os.setpgid(pid, pgrp)
Call the system call setpgid() to set the process group id of the
process with id pid to the process group with id pgrp. See the Unix
manual for the semantics.
"""

preexec_fn pydoc says "If preexec_fn is set to a callable object, this
object will be called in the child process just before the child is
executed.", so that just sets the same process group id for all child
processes that are started.

Make sense?

[Rob Middleton]

OK - just wondering if any of that causes the installer app & its children not to want to die in the right order.

That is -- what should happen:
** dmg mounted **
installer launches
-- spawns an orphaned waiting script that waits for installer to quit
installer quits
-- waiting script does some work after it believes installer has quit
-- waiting script dies

** dmg unmounted **

If installer doesn't quit because it believes it is dependent on the orphaned waiting script this is no good (the symptoms being reported).

Perhaps we are doing something to our munki environment to change how happy installer is to exit (still floundering for a good explanation ... or I would have fixed it already!).

Rob.

[Greg Neagle]

This doesn't explain the behavior we're seeing, but I'd expect this:

** dmg mounted **
installer launches
-- spawns an orphaned waiting script that waits for installer to quit

installer exits

Munki knows nothing about waiting script and attempts to unmount dmg
After that, what happens is unclear, but might include:

-- waiting script does some work after it believes installer has quit
-- waiting script dies

** dmg unmounted **

-Greg

[Justin McWilliams]

I haven't seen this problem firsthand, so it's hard to wrap my head
around it. How long are things hung on "Finishing" before the zombie
process is seen? Is it immediate? Is it over 2 hours later?

Note, the reason I ask is that we're killing installer and it's
children if it has't outputted to stdout in 2 hours:
http://code.google.com/p/munki/source/browse/code/client/munkilib/installer.py#163

So I'm curious if the zombies are seen before or after that code runs.

[Greg Neagle]

It's definitely before that code runs. I haven't been patient enough to wait two hours to see if it gets killed. I assume it will be.

-Greg

[Sean]

I let it run in its entirety, here is the error that is thrown up:

***********************

Finishing the Installation…
ERROR: /usr/sbin/installer timeout after 7200 seconds
ERROR: Unexpected error in munkilib.installer:
ERROR: Traceback (most recent call last):
File "/usr/local/munki/managedsoftwareupdate", line 216, in
doInstallTasks
need_to_restart = installer.run(only_unattended=only_unattended)
File "/usr/local/munki/munkilib/installer.py", line 1190, in run
only_unattended=only_unattended)
File "/usr/local/munki/munkilib/installer.py", line 681, in
installWithInfo
suppressBundleRelocation)
File "/usr/local/munki/munkilib/installer.py", line 265, in
installall
suppressBundleRelocation)
File "/usr/local/munki/munkilib/installer.py", line 159, in install
os.kill(-1 * proc.pid, signal.SIGTERM)
OSError: [Errno 1] Operation not permitted


*********************

So I installed it via Munki, let it run for the 2 hours as well.

I open Word and get errors about upgrading the Office database and
have the options to Upgrade or "Quit Outlook"??? Even though I haven't
opened outlook?
Then I get told there is a problem with the office database by Word.
Fantastic

This doesn't really have much of a bearing on me as I just manage the
Mac labs, so Outlook isn't being used and the office db error isn't
too much for the users to worry about. However they may not know that
I will have to see if this can be fixed before deploying the update
and freaking a bunch of users out.

I don't think any of this is a problem with Munki though, just how MS
have packaged the installer

On Apr 13, 7:07 am, Greg Neagle <gregnea...@mac.com> wrote:
> It's definitely before that code runs. I haven't been patient enough to wait two hours to see if it gets killed. I assume it will be.
>
> -Greg
>
> On Apr 12, 2012, at 11:04 PM, Justin McWilliams wrote:
>
>
>
>
>
>
>
> > I haven't seen this problem firsthand, so it's hard to wrap my head
> > around it.  How long are things hung on "Finishing" before the zombie
> > process is seen?  Is it immediate?  Is it over 2 hours later?
>
> > Note, the reason I ask is that we're killing installer and it's
> > children if it has't outputted to stdout in 2 hours:

> >http://code.google.com/p/munki/source/browse/code/client/munkilib/ins...

>
> > So I'm curious if the zombies are seen before or after that code runs.
>

> > On Fri, Apr 13, 2012 at 11:26 AM, Greg Neagle <gregnea...@mac.com> wrote:
> >> This doesn't explain the behavior we're seeing, but I'd expect this:
>
> >> ** dmg mounted **
> >> installer launches
> >> -- spawns an orphaned waiting script that waits for installer to quit
> >> installer exits
>
> >> Munki knows nothing about waiting script and attempts to unmount dmg
> >> After that, what happens is unclear, but might include:
>
> >> -- waiting script does some work after it believes installer has quit
> >> -- waiting script dies
>
> >> ** dmg unmounted **
>
> >> -Greg
>
> >> On Apr 12, 2012, at 10:50 PM, Rob Middleton wrote:
>
> >>> On 13/04/2012, at 3:30 PM, Justin McWilliams wrote:
>

> >>>>>>>> Apr 12 15:43:40 tim-imac installd[10940]: PackageKit: Writing receipt for...
>
> read more »

[Joe Wollard]

I just saw this same symptom on my test machine. Our installer is also an educational version which doesn't require registration code, yet now it's prompts. I think Microsoft may have been a bit laxed on their testing of this update.

--
--

Joe Wollard

[dav...@comcast.net]

On Friday, April 13, 2012 7:41:27 AM UTC-7, Sean wrote:

I open Word and get errors about upgrading the Office database and
have the options to Upgrade or "Quit Outlook"??? Even though I haven't
opened outlook?
Then I get told there is a problem with the office database by Word.
Fantastic

================

This is mixing a couple of issues.

1) We (Microsoft) are investigating the issues with munki/Casper/Education License

2) This issue here (database upgrade) is by design - more explanation below

The database in Office 14.2 has taken some changes to be more robust, so it needs to be updated with these new changes - thus the dialog when you first launch about upgrading the database. Word/Excel/PowerPoint all tie into the database for information like the Me Contact (which fills in the Edit information in the Properties dialog) and Word ties in with the database to populate the Address Book (available with mail merges). If you choose to Quit Outlook (yes, a poorly worded dialog since Outlook is not launched) rather than Upgrade, then the database did not upgrade, and Word cannot read it. Thus the second alert you got about an issue with the database since it is not in the format expected.

Hope this helps, and we will report more as we investigate. We are not seeing these issues in house, so we may ping folks here for more information.

Thanks

David Pelton

Release Test Lead

Microsoft, Macintosh Group

[Hannes Juutilainen]

Thank you David for taking the time to comment on these issues. It is definitely appreciated!

We will start testing on 14.2 update next week so I'll be chiming in with any issues.

--

Hannes Juutilainen

University of Jyväskylä

[immoral]

All

Just wondering if there are any gotcha's regards running Munki on an Xserve running Lion server (10.7.3)? apart for Apple not having the full admin tools installed by default. Thanks a bunch Apple.

[Greg Neagle]

All Munki requires on the server is a functional webserver. If you can successfully configure web services on Lion server, you can host a Munki repo on a Lion server.

-Greg

[Timothy Sutton]

"Running Munki" only involves running a web server that's serving out the static files of your Munki repo, so as long as you can configure one on Lion Server, you should be fine. You'll also need some way of mounting the repo for administration, usually done via a file share service.

Personally, I tend to avoid OS X Server's built-in web services, but for the basics it can suffice. I seem to recall something about Apple adding the "Allow overrides" option back to the GUI only in 10.7.3, which if it's the true, is ridiculous. You'll probably want that for at least Basic Authorization and to prevent directory listings.

Tim

[The Immoral Tristy]

thanks all. just upgrading from snow to lion so as long as everything holds together my existing setup should stay up. just thought someone may have noticed a thing or two...

tristan

sent via my pocket...

[Shawn]

It has been getting killed after two hours. We noticed that on a few machines in our management group.

[Greg Neagle]

After that, Office 2011 SP2 is installed, yes?

The problem is a cleanup script that is forked by the distribution script prior to the install. It waits for the installer to exit, and then removes files and directories from /tmp. For a reason we don't yet understand, the installer does not exit cleanly, and stays in a sort of zombie state. Therefore the script circles in an infinite loop.

-Greg

[Jaylon]

Ours is doing the same thing too.

What I've noticed is when I manually kill the sp2 update process I'll
go to upgrade another client machine but it then gets stuck at trying
to mount the dmg. It's as if it didn't unmount the dmg when I killed
it and then attempts to mount it again but can't because it's already
mounted? so it just stays at "mounting disk image"

On Apr 17, 1:58 am, Greg Neagle <gregnea...@mac.com> wrote:
> After that, Office 2011 SP2 is installed, yes?
>
> The problem is a cleanup script that is forked by the distribution script prior to the install. It waits for the installer to exit, and then removes files and directories from /tmp. For a reason we don't yet understand, the installer does not exit cleanly, and stays in a sort of zombie state. Therefore the script circles in an infinite loop.
>
> -Greg
>
> On Apr 16, 2012, at 8:43 AM, Shawn wrote:
>
>
>
> > It has been getting killed after two hours. We noticed that on a few machines in our management group.
>
> > On Friday, April 13, 2012 2:04:10 AM UTC-4, Justin McWilliams wrote:
> > I haven't seen this problem firsthand, so it's hard to wrap my head
> > around it.  How long are things hung on "Finishing" before the zombie
> > process is seen?  Is it immediate?  Is it over 2 hours later?
> > Note, the reason I ask is that we're killing installer and it's
> > children if it has't outputted to stdout in 2 hours:

> >http://code.google.com/p/munki/source/browse/code/client/munkilib/ins...

>
> > So I'm curious if the zombies are seen before or after that code runs.
>

> > On Fri, Apr 13, 2012 at 11:26 AM, Greg Neagle <gregnea...@mac.com> wrote:
> > > This doesn't explain the behavior we're seeing, but I'd expect this:
>
> > > ** dmg mounted **
> > > installer launches
> > > -- spawns an orphaned waiting script that waits for installer to quit
> > > installer exits
>
> > > Munki knows nothing about waiting script and attempts to unmount dmg
> > > After that, what happens is unclear, but might include:
>
> > > -- waiting script does some work after it believes installer has quit
> > > -- waiting script dies
>
> > > ** dmg unmounted **
>
> > > -Greg
>
> > > On Apr 12, 2012, at 10:50 PM, Rob Middleton wrote:
>
> > >> On 13/04/2012, at 3:30 PM, Justin McWilliams wrote:
>

> ...
>
> read more »

[dav...@comcast.net]

Attempts to do a command line install on Lion are failing due to the script to clean up the temporary folder used to hold the bits during installation. This issue can also occur on any OS if multiple command line installs are being done at the same time.

 

Microsoft is aware of the issue and looking to remedy it, but in the meantime, the following steps will allow you to edit the offending script and carry on with your deployment.

 

1.     Open the 14.2.0 updater DMG

2.   Drag the Office 2011 14.2.0 Update.pkg to your desktop

3.     CTRL+Click on the Office 2011 14.2.0 Update.pkg and choose Show Package Contents from the contextual menu

4.     Navigate to the Resource folder from within the Contents folder.

5.     Open the clean_path script with any text editor

6.     On the second line (a blank line) add this text    exit 0

      7.   Save the script and then run your installation with this modified pkg

Your final code should look like this:

 

#!/bin/sh

exit 0

 

We recommend that you restart after this installation to remove the temporary folder from the machine and avoid potential update problems in the future if the temporary folder still existed.

 

I am sorry for any inconvenience this has caused you.

 

David Pelton

Release Test Lead, Microsoft Macintosh group.

[Hannes Juutilainen]

Thanks for the info. Will you be reposting the 14.2 update once the issues are resolved or will you create a new 14.2.1 update? For munkiers, I would suggest cleaning the temporary files with a postinstall_script key in the pkginfo and _not_ requiring a restart. So basically:

#!/bin/sh

if [[ -e "/tmp/com.microsoft.updater.root.plist" ]]; then

/bin/rm -rf "/tmp/com.microsoft.updater.root.plist"

fi

if [[ -e "/tmp/com.microsoft.updater.user.plist" ]]; then

/bin/rm -rf "/tmp/com.microsoft.updater.user.plist"

fi

exit 0

One question: What is in the $path variable the clean_path is trying to remove? I see it is provided by the $2 argument when the script is called.

--

Hannes Juutilainen

University of Jyväskylä

[Hannes Juutilainen]

And Greg seems to have answered my question about the $path in an earlier message in this very same thread. I really need some coffee...

--

Hannes

[Greg Neagle]

I haven't tested this (because I'm really hoping for a fixed update from Microsoft), but I think this postinstall_script would do a better job:

#!/bin/sh

# An attempt to clean up after the Office 2011 14.2.0 update

PLIST="/tmp/com.microsoft.updater.root.plist"

if [ -e "$PLIST" ]; then

    TMPDIR=`/usr/bin/defaults read $PLIST com.microsoft.updater`

    if [ -d "$TMPDIR" ]; then

        /bin/rm -rf "$TMPDIR"

    fi

    /bin/rm "$PLIST"

fi

----

It reads the com.microsoft.updater key from the /tmp/com.microsoft.updater.root.plist to determine which directory to clean up. (The directory name is different for each install.)

So: if you really wanted/needed to install the Office 2011 SP2 14.2.0 update with Munki, you could:

1) Neuter the clean_path script as described by David Pelton, and

2) Use the above postinstall_script to do the cleanup that the clean_path script would have.

-Greg

[Rob Middleton]

Greg,

I would be surprised if this works without also modifying the update package. I don't think munki's postinstall_script would run because installer has not yet exited (due to the bug causing installer not to exit which you are trying to workaround after installer exits)??

Rob.

[Greg Neagle]

You didn't read the whole thing:

So: if you really wanted/needed to install the Office 2011 SP2 14.2.0 update with Munki, you could:

1) Neuter the clean_path script as described by David Pelton, and

2) Use the above postinstall_script to do the cleanup that the clean_path script would have.

1) is a modification of the update package.

-Greg

[Rob Middleton]

Sorry - still waking up. Read that as OR.

[Greg Neagle]

Yet another reason to hold off on this update and wait for a revised update:

http://blog.officeformac.com/update-on-service-pack-2/

-Greg

[jps3]

I just tried the 14.2.1 installer and it still hangs at the same place with the same "clean_path" script. I guess the new MS paradigm is to walk around to hundreds of computers and install manually? Oy.

[Samuel Keeley]

The best part is that Microsoft claims that it is fixed in the KB article.  I just cleared out the clean_path script and have it exit 0 immediately, it works fine.  Not too worried about some files sitting in /tmp, they will get cleared out automatically anyways.

You can now deploy Office 2011 SP2 updates by using a command-line installation or by using tools that call the command line, such as Casper or Munki, on Mac OS X 10.7 (Lion) and on later versions of Mac OS X.

On Wed, Apr 25, 2012 at 3:48 PM, jps3 <jp...@lehigh.edu> wrote:

I just tried the 14.2.1 installer and it still hangs at the same place with the same "clean_path" script. I guess the new MS paradigm is to walk around to hundreds of computers and install manually? Oy.

--
Samuel Keeley

[jps3]

I repackaged the *.pkg installer having commented out two lines in Office 2011 14.2.1 Update.pkg/Contents/Resources/volume_updatable to prevent clean_path from running. Then created new dmg with updated package, and updated my munki pkginfo accordingly. It seems to run now. Will test a little bit more before putting into production...

[Samuel Keeley]

The update itself seems to run very fast, just a couple minutes, but make sure to warn your users that the Outlook database upgrade may take a VERY long time.  It'll do about 500-1000 messages a minute going from 14.1.4 to 14.2.1, so it could take an hour or two for those with tens of thousands of messages.

On Wed, Apr 25, 2012 at 6:01 PM, jps3 <jp...@lehigh.edu> wrote:

I repackaged the *.pkg installer having commented out two lines in Office 2011 14.2.1 Update.pkg/Contents/Resources/volume_updatable to prevent clean_path from running. Then created new dmg with updated package, and updated my munki pkginfo accordingly. It seems to run now. Will test a little bit more before putting into production...

--
Samuel Keeley

[jps3]

Thankfully(?) I don't have Outlook deployed!

[dav...@comcast.net]

Greetings and Salutations

Sorry to be so long to reply about the Product Activation issue. We have been able to reproduce in house and I want to make sure the scenario matches yours.

To reproduce this behavior we have found that you need to be 

• pushing both the last Setup Build you have in your establishment (14.0 or 14.1) and the updater (14.2.1 or 14.2.0) at the same time, OR
  
• pushing the 14.2.x updater to a machine that a) has had the setup build pushed via Munki/ARD and b) never run any of the office installs

Does this match the scenarios you see?

We do not have a fix, but we have a workaround. Everyone should have access to the 14.2.0 setup image now, and you can push the 14.2.0 setup image (rather than the 14.0 or 14.1 setup image) with the 14.2.1 updater and not have this issue.

Please either email me or respond back here if you are seeing something different.

Thanks

David Pelton

[dav...@comcast.net]

Greetings and Salutations

We are not reproducing the issue with the clean script in house, nor have we heard of others still facing this issue. JPS3 and Samuel, could you please pass on any other information or get in touch with me so we can get to the bottom of your issue?

Thanks

David Pelton

[Greg Neagle]

I can reproduce the issue, and it acts the same as it did with the 14.2.0 update.

This machine is running 10.6.8, and had Office 2011 installed and successfully updated to 14.1.4.

I then used Munki to attempt to install the 14.2.1 update. After /usr/sbin/installer finished installing packaged, Munki gets stuck at "Finishing the Installation..."

ps axwww has these two entries of interest; essentially identical to what we saw with the 14.2.0 update.

61413 ?? Z 0:00.00 (installer)
61490 ?? S 0:00.09 /bin/sh /private/tmp/dmg.5YMdle/Office 2011 14.2.1 Update.pkg/Contents/Resources/clean_path 61413 /private/tmp/com.microsoft.updater.root.1336167780704

The last 20 lines of install.log:

May 4 14:44:40 tic installer[61413]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Office%20Reminders.app/
May 4 14:44:40 tic installer[61413]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Upload%20Center.app/
May 4 14:44:40 tic installer[61413]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Chart%20Converter.app/
May 4 14:44:40 tic installer[61413]: PackageKit: Registered bundle file://localhost/Applications/Microsoft%20Office%202011/Office/Microsoft%20Database%20Daemon.app/
May 4 14:44:41 tic installer[61413]: Installed "Office 2011 14.2.1 Update" ()
May 4 14:44:41 tic installer[61413]: PackageKit: ----- End install -----
May 4 14:44:42 tic installer[61413]: Running install actions
May 4 14:44:42 tic installer[61413]: Removing temporary directory "/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-//Install.61413Ox6HTC"
May 4 14:44:42 tic installer[61413]: Finalize disk "Snow Leopard"
May 4 14:44:42 tic installer[61413]: Notifying system of updated components
May 4 14:44:43 tic installer[61413]:
May 4 14:44:43 tic installer[61413]: **** Summary Information ****
May 4 14:44:43 tic installer[61413]: Operation Elapsed time
May 4 14:44:43 tic installer[61413]: -----------------------------
May 4 14:44:43 tic installer[61413]: disk 0.02 seconds
May 4 14:44:43 tic installer[61413]: zero 0.01 seconds
May 4 14:44:43 tic installer[61413]: install 85.13 seconds
May 4 14:44:43 tic installer[61413]: script 0.01 seconds
May 4 14:44:43 tic installer[61413]: -total- 85.17 seconds
May 4 14:44:43 tic installer[61413]:

If I kill 61490, Munki finishes up, but obviously clean_path does not do its thing.

In this case, Munki was installing while the Mac was at the login window and there was no logged-in user; but I saw the same problem with the 14.2.0 update with a GUI user.

I'd be happy to provide additional data to help you reproduce this issue, or try additional testing scenarios.

-Greg

[Samuel Keeley]

My log shows it getting stuck at the same place, though our systems are all on 10.7.3.

It got stuck both with a user logged in and at the login window under all of the following:

1. Office 2011 14.0.0 installed, 14.1.0 applied, 14.1.4 applied, got stuck at 14.2.0 and 14.2.1

2. Office 2011 14.0.0 installed, 14.1.0 applied, got stuck at 14.2.0 and 14.2.1

3. Office 2011 14.1.0 installed, 14.1.4 applied, got stuck at 14.2.0 and 14.2.1

4. Office 2001 14.1.0 installed, got stuck at 14.2.0 and 14.2.1

3 and 4 were done in testing, 1 would be any machine that already exists getting the update, and 2 would be a machine getting bootstrapped with munki.  Editing the clean_path script down to exit 0 immediately fixed all of these.

I can e-mail the full logs if requested, but they effectively identical to Greg's.

-sam

--
Samuel Keeley

[Greg Neagle]

One more bit that might be important:

Munki is installing these updates from a mounted disk image. As soon as /usr/sbin/installer returns, Munki attempts to eject the disk image. But of course, the clean_path script is still open and running from that volume, so presumably the unmount would fail or hang. Perhaps this creates a race condition of some sort?

Sent from my iPhone

[Greg Neagle]

Upon further testing, I don' t think the mounted disk image is a factor here.

I modified Munki to sleep a few seconds after /usr/sbin/installer returns, but before unmounting the image. I saw no change in behavior. It appears (to me) that /usr/sbin/installer is not exiting.

Since /usr/sbin/installer is not exiting, the clean_path script never exits.

There is something about the clean_path script that is causing  /usr/sbin/installer to NOT exit. Proof of this is the original workaround for this problem, which was to disable the clean_path script. If the clean_path script is not running when it's time for /usr/sbin/installer to exit,  /usr/sbin/installer exits cleanly. If we kill the clean_path script, /usr/sbin/installer exits.

Some more data. Here is the end of a run of /usr/sbin/installer where the Office 2011 14.1.0 update is installed:

May 04 16:00:21     Writing package receipts…

May 04 16:00:22     Cleaning up…

May 04 16:00:22     Running installer actions…

May 04 16:00:23     Finishing the Installation…

May 04 16:00:27     The software was successfully installed.

May 04 16:00:27  The install was successful.

May 04 16:00:27 Install of Office 2011 14.1.0 Update was successful.

The lines "Finishing the Installation…" and "The software was successfully installed." come from /usr/sbin/installer's output to stdout.

Here is a run where it attempts to install the Office 2011 14.2.1 update:

May 04 16:02:24     Registering updated applications…

May 04 16:02:24     Writing package receipts…

May 04 16:02:25     Writing package receipts…

May 04 16:02:25     Writing package receipts…

May 04 16:02:25     Running installer actions…

May 04 16:02:26     Finishing the Installation…

and there it sits indefinitely. Note that /usr/sbin/installer outputs "Finishing the Installation…" but not "The software was successfully installed.". This, to me, indicates that /usr/sbin/installer is stuck in a wait loop, most likely waiting for clean_path to exit.  (and clean_path is itself waiting for /usr/sbin/installer to exit.) 

If I kill the clean_path process, /usr/sbin/installer finishes up normally:

May 04 16:13:21     The software was successfully installed.

May 04 16:13:21  The install was successful.

May 04 16:13:21 Install of Office 2011 14.2.1 Update was successful.

May 04 16:13:23 ###    End managed installer session    ###

So in some circumstances which correspond with the way Munki runs /usr/sbin/installer, /usr/sbin/installer is aware of and waits for child processes it spawned to exit before it itself exits.

-Greg

[Greg Neagle]

For those of you playing along at home and familiar with some of the internal workings of Munki, here's a few other things I tried to see if I could narrow down the trigger for this issue:

Munki uses a subclass of the Python subprocess module to run /usr/sbin/installer:

    proc = munkicommon.Popen(cmd, shell=False, bufsize=1, env=env_vars,

                             stdin=subprocess.PIPE,

                             stdout=subprocess.PIPE,

                             stderr=subprocess.STDOUT,

                             preexec_fn=lambda: os.setpgid(

                                 os.getpid(), os.getpid()))

I tried removing the preexec_fn bit, which sets a process group id so if the installer hangs, we can more easily kill it and any subprocesses. Removing that had no effect on the issue.

A second thing I tried was converting the cmd sequence to a shell-escaped string and setting shell=True. Still no difference.

Ultimately, it's strange thing that the metapackage is doing -- the javascript in the Distribution file ends up starting a script that tries to live past the end of the installer process.

-Greg

[dav...@comcast.net]

Greg and Samuel - could you please post your full log especially the beginning of the log?

Thanks a bunch

David

[Greg Neagle]

I assume you mean /var/log/install.log?

Sent from my iPhone

[dav...@comcast.net]

Actually I would like both. We are trying to see why Munki is behaving different from ARD and regular command line installs.

 

Appreciate the help by supplying the logs.

 

David

[Rob Middleton]

Given the above --

I have previously discovered that there is some bug in the ObjC bridge to python -- if a python command imports any of "Foundation" then it changes the execution environment sufficiently (some form of sandbox?) that certain commands don't work right.

Python with an import of Foundation is used fairly heavily for administering Macs in general - not just by munki.

Below is a previous example of the simplest test case -- perhaps try running the MS Office updater within these two test cases.

*WORKS* -- No Foundation/PyObjC bridge imported.
import subprocess
cmd = ['/usr/bin/script', '-q', '-t', '1', '/dev/null',
'/usr/sbin/softwareupdate','-v',
'--CatalogURL',
'file://localhost/Library/Managed%20Installs/swupd/mirror/content/catalogs/local_install.sucatalog',
'-i','-a']
subprocess.call(cmd)


FAILS -- Foundation imported.
from Foundation import NSDate
import subprocess
cmd = ['/usr/bin/script', '-q', '-t', '1', '/dev/null',
'/usr/sbin/softwareupdate','-v',
'--CatalogURL',
'file://localhost/Library/Managed%20Installs/swupd/mirror/content/catalogs/local_install.sucatalog',
'-i','-a']
subprocess.call(cmd)


Something this updater is doing requires processes to end in a particular order, perhaps this execution mode (as tweaked by Apple) doesn't allow things to die in the expected order (parent won't die until child has died??).

Cheers,
Rob Middleton.
Centenary Institute
Sydney, Australia.

[Rob Middleton]

On 08/05/2012, at 11:53 AM, Rob Middleton wrote:

> On 08/05/2012, at 12:25 AM, dav...@comcast.net wrote:
>
>> Actually I would like both. We are trying to see why Munki is behaving different from ARD and regular command line installs.
>>
>> Appreciate the help by supplying the logs.
>>
>> David
>
>
> Given the above --
>
> I have previously discovered that there is some bug in the ObjC bridge to python -- if a python command imports any of "Foundation" then it changes the execution environment sufficiently (some form of sandbox?) that certain commands don't work right.
>
> Python with an import of Foundation is used fairly heavily for administering Macs in general - not just by munki.
>
> Below is a previous example of the simplest test case -- perhaps try running the MS Office updater within these two test cases.
>
> *WORKS* -- No Foundation/PyObjC bridge imported.
> import subprocess
> cmd = ['/usr/bin/script', '-q', '-t', '1', '/dev/null',
> '/usr/sbin/softwareupdate','-v',
> '--CatalogURL',
> 'file://localhost/Library/Managed%20Installs/swupd/mirror/content/catalogs/local_install.sucatalog',
> '-i','-a']
> subprocess.call(cmd)

Oops - should clarify
cmd = ['/usr/sbin/installer','-package','...','-target','/']
should do the job. The extra cmd components confuse the issue.

The extract I gave above was using an unbuffering wrapper when solving softwareupdate problems.

Rob.

[Greg Neagle]

You have 4 or 5 more office hours in Sydney....

Sent from my iPhone

[jps3]

Just tried the 14.2.2 update using Munki/MSU. Still hangs at the same place with the same script (clean_path). This is getting somewhat farcical now, Microsoft!

[Greg Neagle]

So this is fun.

from Foundation import NSDate
import subprocess

cmd = ['/usr/sbin/installer', '-pkg', '/Volumes/Microsoft Office 2011 14.2.1 Update/Office 2011 14.2.1 Update.pkg', '-target', '/']
subprocess.call(cmd)

Completes successfully.

Now I need to add back more of the Munki environment...

-Greg

[jps3]

The pkg installer for 14.2.2 seems to install just fine when no user at console and run from command line remotely. Perhaps something in munki "losing track" along the way? When installed via MSU/munki I see from /var/log/install.log that the installation is finished yet the clean_path script is still an active process yet the "installer" process is "(installer)" (zombified?)

Perhaps munki can't track or loses track of that script since exec'd/forked from one of the pkg install scripts?

[Greg Neagle]

I can reliably reproduce this issue using this Python script:

#!/usr/bin/env python
# encoding: utf-8

import sys
import os

import subprocess

cmd = ['/usr/sbin/installer',
'-pkg', '/Volumes/Microsoft Office 2011 14.2.1 Update/Office 2011 14.2.1 Update.pkg',
'-target', '/']

proc = subprocess.Popen(cmd, shell=False, bufsize=-1,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)

while True:
installinfo = proc.stdout.readline()
if (proc.poll() != None):
break
print installinfo.rstrip('\n')

print "Done!"


------
Mount the 14.2.1 update diskimage on a machine and run the script. It will fail to exit and you will see the zombie installer process and the clean_path script in the output of `ps axwww`:

63473 ?? S 0:00.25 /bin/sh /Volumes/Microsoft Office 2011 14.2.1 Update/Office 2011 14.2.1 Update.pkg/Contents/Resources/clean_path 63402 /private/tmp/com.microsoft.updater.root.1336521048382
65289 ?? S 0:00.00 /bin/sleep 1
26954 s000 Ss 0:00.11 -sh
63401 s000 S+ 0:00.09 python ./installer_test.py
63402 s000 Z+ 0:00.00 (installer)

kill the process id with the clean_path script and the installer_test.py script will exit.

This script and test works whether or not you can actually install the Office 2011 14.2.1 update, since the clean_path script is launched as part of the processing of the distribution file.

-Greg

[Greg Neagle]

And for what it's worth, the same issue is reproducable using the Office 2011 14.2.2 update.

-Greg

[Rob Middleton]

I wonder if we are stuck on the readline or the proc.poll() not letting us break.

Sorry to only throw ideas in at the moment -- need to get my server room ready for new Isilon gear :). I'm running late! And Office 2011 with SP2 took 2 hours to download yesterday ... must be coming from the other side of the world :).

stdout is an interesting one here ... the child process will still be connected the stdout we are trying to read from. I suspect changing to the launchd method we use for softwareupdate would resolve the issue. Perhaps it would resolve it due to the different handling of stdout (tailing the file), rather than the "import Foundation" issue it was originally implemented for.

Rob.

[Greg Neagle]

I did a test, changing munkilib/installer.py's install() function to use the same launchd wrapper that appleupdates.py uses to work with softwareupdate.

It successfully installed the 14.2.1 update without the hang at the end.

I'm going to do a little more testing, but might commit this change.

This might also eliminate the use of the custom subprocess class that does reads with timeouts...

-Greg

[Greg Neagle]

No feedback or reaction from anyone, so please test this in your environment:

http://code.google.com/p/munki/source/detail?r=db7624502393

For those of you who can't build from source, http://munkibuilds.org should have an auto-build at some point.

-Greg

[Heig Gregorian]

Testing now...thanks for taking a "deep dive" into this!

--Heig

[Greg Neagle]

Auto-built version here: http://munkibuilds.org/0.8.3.1489.0/

(Thanks to Timothy Sutton for building and running this service.)

-Greg

On May 9, 2012, at 4:48 PM, Greg Neagle wrote:

[jps3]

FYI this build (1490) worked for me installing MSOffice 14.2.2 via munki over 10.7.4's loginwindow on my test machine.

[Samuel Keeley]

I can't get the update to import correctly, whether or not I've modified the clean_path script.

If I copy the .pkg out of the disk image to my desktop, and then run munkiimport, I get the following:

munkiimport /Users/adminuser/Desktop/Office\ 2011\ 14.2.2\ Update.pkg 

Making disk image containing Office 2011 14.2.2 Update.pkg...

diskimages-helper: resize request is above maximum size allowed.

hdiutil: create failed - Invalid argument

Disk image creation failed.

Could not convert /Users/adminuser/Desktop/Office 2011 14.2.2 Update.pkg to a disk image.

If I manually create a disk image and place the .pkg inside of it, munkiimport will handle it fine, but then it fails on the client end:

May 10 11:31:26     Office 2011-14.2.2 requires Office 2011-14.1.0. Getting info on Office 2011-14.1.0...

May 10 11:31:26     Office 2011-14.1.0 requires Office 2011-14.0.0. Getting info on Office 2011-14.0.0...

May 10 11:31:26     Office 2011 version 14.0.0 (or newer) is already installed.

May 10 11:31:26     Office 2011 version 14.1.0 (or newer) is already installed.

May 10 11:31:26     Office 2011-14.2.2 requires Office 2011-14.2.1. Getting info on Office 2011-14.2.1...

May 10 11:31:26     Need to install Office 2011

May 10 11:31:26     Downloading Office 2011 14.2.2 Update.dmg from Microsoft/Office 2011/Office 2011 14.2.2 Update.dmg

May 10 11:31:26     Downloading Office 2011 14.2.2 Update.dmg from Microsoft/Office 2011/Office 2011 14.2.2 Update.dmg

May 10 11:31:26     Downloading Office 2011 14.2.2 Update.dmg...

May 10 11:31:30     Verifying package integrity...

May 10 11:31:30 ERROR: Hash value integrity check for Office 2011 14.2.2 Update.dmg failed.

May 10 11:31:30 WARNING: Can't install Office 2011 because the integrity check failed.

This is all on 0.8.2.1475, both on 10.7.4 and 10.7.3.  I've redownloaded and hash checked the disk image from Microsoft, so I don't think that is the issue.

sam

On Thu, May 10, 2012 at 11:22 AM, jps3 <jp...@lehigh.edu> wrote:

FYI this build (1490) worked for me installing MSOffice 14.2.2 via munki over 10.7.4's loginwindow on my test machine.

--
Samuel Keeley

[Joseph Rafferty]

If you manually create your disk images, make sure you create or convert them read-only, otherwise the hash will change every time they're opened.

Not sure on the diskimages-helper error :/

-Joseph

[tackyy]

Might be helpful to add the read-only hash bit to https://code.google.com/p/munki/wiki/CreatingDiskImages

[Greg Neagle]

The best approach is to not create disk images yourself, but rather let munkiimport do it for you:

munkiimport /path/to/bundle.pkg

Will create a read-only disk image of the package.

munkiimport /Applications/Firefox.app

Will create a disk image containing Firefox.app.

-Greg

[Heig Gregorian]

Greg,

Looking good!  Tested an unmodified deployment of "Office2011-1420UpdateEN.dmg" to 5 clients last night successfully last night.

So far, I've got about 150 clients that have gone ahead with the deployment today with no issues reported (munkireport shows success as well).

--Heig

[Greg Neagle]

My concern is that we've modified the installer execution environment in a way that the stupid things the Office updater is doing are happier now, but that some other package doing stupid/unusual things will now be less happy. I need to find time to rebuild a machine from scratch using the new code to exercise more packages. (Adobe CS packages would be an important test.)

-Greg

[immoral]

so to clarify 14.2.2 negates all the stalling shenanigans that screeds have been written about? the older one was a clunker from a Munki point of view?

[Greg Neagle]

On May 10, 2012, at 3:40 PM, immoral wrote:

> so to clarify 14.2.2 negates all the stalling shenanigans that screeds have been written about?

Nope.

You either need to neuter the clean_path script, or use a test build of Munki:

http://munkibuilds.org/

0.8.3.1489.0 or later.

> the older one was a clunker from a Munki point of view?

14.2.0, 14.2.1, and 14.2.2 all exhibit the same issue when installed with Munki prior to 0.8.3.1489.0.

-Greg

[Rob Middleton]

I had the same thought. Theoretically I believe this should be safer in all cases -- however it is a *major* change.

My initial thought had been that the pkginfo file should specify whether the execution method should be old style or new. That thought wasn't only for reason of it being a potential breaking change -- but due to time to execute.

I'm not sure how much time the launchd method adds to execution - perhaps not significant. In the case of softwareupdate we only make one launchd call to install all updates. In the case of munki managed packages we have a separate call for each install.

With a little luck this will be perfect for all situations, removing the need for different execution methods of apple update vs installer.

I'm happily running 0.8.3.1490

Rob.

[immoral]

Thanks Greg

Am only using it to run SUS at present so am sitting on the sidelines playing along at home to keep up with the crowd.

Am looking to implement app updates very soon. These types of issues somewhat frighten me from a time investment point of view in managing the back end. The administrative time cost as it where.

Just a thought.

Regards

Tristan

[Greg Neagle]

On May 10, 2012, at 4:02 PM, immoral wrote:

> Thanks Greg
>
> Am only using it to run SUS at present so am sitting on the sidelines playing along at home to keep up with the crowd.
>
> Am looking to implement app updates very soon. These types of issues somewhat frighten me from a time investment point of view in managing the back end. The administrative time cost as it where.

So you watch and wait when there are new updates to see if there are any gotchas. Same as the process for Apple updates, frankly.
>
> Just a thought.

As opposed to not updating the apps?

Not sure what you are implying here.

[immoral]

we don't currently update existing apps. the machine gets re-imaged with an entirely new image containing updates, but not very often. just looking to move from away from this.

looks like the same players cause issues here as they do with instaDMG that require time to resolve.

just looking at how much pre-processing time is involved vs how much time i have. nothing to do with the product...

[MikeW]

I have just tried an Audition CS6 install packaged using the newly released AAMEE 3.0 tool and Munki 0.8.3.1489.0 build.  

Install and uninstall both worked as expected.

Mike

[Greg Neagle]

Thanks.

Of course, testing CS6 and AAMEE 3 packages is a whole new set of issues, but that's encouraging nonetheless.

-Greg

[Richard Chilcott]

Successfully deployed MS Office 2011 14.2.0 and 14.2.2 to a clean installed machine.  Also successfully installed the following apps:

Maya 2012

Firefox

Adobe Flash Player (11.2)

Adobe CS 5.5

Adobe Lightroom 4

Silverlight

Final Cut Pro X (10.0.4)

OnLive

It was in a VM, and it was slow, but other than that, they all worked fine. Some of these include preflight/postflight scripts, and the Adobe installers were fine.

Ricky Chilcott

[MikeW]

I can recreate the Product Activation issue that Dave mentions here..

If I import the Office SP2 setup image into Munki with the same name as the SP1 image, machines that already have Office installed also want to pull the full SP2 installer.  The 14.2.2 updater then gets laid over the top anyway so it ends up being a waste of time/bandwidth etc.

Is there any way around this without having to import the SP2 setup image with a totally different munki name?  The added administrative burden with having two versions of the full installer is not something I really want to deal with.

Mike

On Friday, May 4, 2012 10:08:13 PM UTC+1, David Pelton wrote:

Greetings and Salutations

Sorry to be so long to reply about the Product Activation issue. We have been able to reproduce in house and I want to make sure the scenario matches yours.

To reproduce this behavior we have found that you need to be 

• pushing both the last Setup Build you have in your establishment (14.0 or 14.1) and the updater (14.2.1 or 14.2.0) at the same time, OR
  
• pushing the 14.2.x updater to a machine that a) has had the setup build pushed via Munki/ARD and b) never run any of the office installs

Does this match the scenarios you see?

We do not have a fix, but we have a workaround. Everyone should have access to the 14.2.0 setup image now, and you can push the 14.2.0 setup image (rather than the 14.0 or 14.1 setup image) with the 14.2.1 updater and not have this issue.

Please either email me or respond back here if you are seeing something different.

Thanks

David Pelton

[Jim Zajkowski]

Is there a good trick to make sure Munki updates before Office?

I could make my Office package require a specific Munki version, but I don't know if that will cause a problem down the road when I update Munki again.

--Jim

[Greg Neagle]

Not currently.

-Greg