iTunes PKG leaving DMG mounted

[jlevitsk]

So I included the latest iTunes and noticed my DMG was still mounted when all was done. “lsof” is my friend and showed me there were two things in use that should not have been.

/Volumes/OS-Build-08-03-15/Applications/iTunes.app/Contents/Resources/iTunesHelper.app/Contents/MacOS/iTunesHelper
/Volumes/OS-Build-08-03-15/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice

I knew the framework was loaded from the binary since when I killed the iTunesHelper process the framework let go. Then I found this…

/iTunes.mpkg/Contents/Resources/iTunesX.pkg/Contents/Resources/postflight_actions/runiTunesHelper

The above is the dopey script that Apple made that simply launches the helper if a user is logged in. Why not also test if the target volume is the booted volume? I don’t know. Seems a little lame to me. For our purposes just delete this file. For InstaDMG there is no need to kill the current helper and certainly no need to launch the helper inside the DMG you are building.

[jlevitsk]

You very well may have. I’m simply terrible at reading release notes. 🙂 probably would save me some time. Hopefully the post will save other non-readers like me. 🙂

[larkost]

A simple way of doing the culling would be this line:

[code]/usr/sbin/lsof | grep “$CURRENT_IMAGE_MOUNT/” | /usr/bin/awk ‘{ print $2 }’ | /usr/bin/xargs /bin/kill [/code]

That should kill off any processes that have files open on the target volume. I have put this in my version of the script near the end of both the install_updates and install_custom sections. I am still working on completely checking this, but it seems to work out in my testing.

Edit: I forgot to mention that I am not combining the grep into the awk because the string we are testing for has “/”s in it, and would get awkward to escape.

[larkost]

Ok.. another version. This one will not try to kill the same process more than one time:

[code]/usr/sbin/lsof | /usr/bin/grep “$CURRENT_IMAGE_MOUNT/” | /usr/bin/awk ‘{ print $2 }’ | /usr/bin/sort -u | /usr/bin/xargs /bin/kill[/code]

I am also continuing to test.

[larkost]

Just in case you were waiting on my testing: so far I have not run into any unexpected problems.

There is only the single expected problem: since both the target volume and the installer disk mount visible to the finder, sometimes if you launch applications while the InstaDMG process is running you will get the application from either of those sources. When my one-liner gets called it will happily tell those processes to quit, which can be a little unexpected. I would argue that this is still the “correct” behavior, and that we should solve it by going the other way. I have a little code to this effect, but I need to do more work for the case that someone already has the OS disk mounted.

And if you have a process with child processes (rather common), then there is a chance that this will try and kill the child process after killing the parent process has already taken care of it. This is not a big deal, and will only result in a small error message. In theory another process could have assumed this process id, but the chances of that happening during the milliseconds between kill events is vanishingly small. And since we are already running as root, there are much better attack vectors through us than a timing exploit, so it is unlikely that someone would try and use this aspect in any malicious way.

[Author]

Posts