Monthly Archives: November 2011

Symantec AntiVirus LiveUpdate – “There was an error performing the update”

Symantec Antivirus (for the Mac) LiveUpdate fails with an alert stating, “There was an error performing the update”

This occurred on a Mac OS X client workstation running Symantec AntiVirus for Mac – the Enterprise product version, not the consumer-oriented Norton AntiVirus for Mac – when attempting to run LiveUpdate.

In order to see a more helpful error message, you’d need to know to look at
/Library/Application Support/Symantec/LiveUpdate/liveupdt.log
where you’ll find the more descriptive:
"verifyCertPath():  objCertJ.buildCertPath failed to get cert path."

When I saw the above error message, it occurred to me right away that communication between the Symantec client and their servers was failing.Perhaps I might need to update a certificate by manually installing it ? The fix is easier, in fact. Update the Symantec LiveUpdate itself, which is a 4.6 MB .dmg file.

See Symantec’s article here: http://www.symantec.com/business/support/index?page=content&id=TECH154634

If you are managing your Macs centrally with Apple Remote Desktop (aka “ARD”), you can use “Send Unix command…”
to verify the LiveUpdate version on the client workstations using the following:

defaults read /Applications/Symantec\ Solutions/LiveUpdate.app/Contents/Info CFBundleGetInfoString

Using ARD, you can centrally push/distribute the updated LiveUpdate by mounting the .dmg download from Symantec, and using the package installer within.
After that, use the following command to get the client workstations to update. I suggest updating everything, rather than just (virus) definitions:

/Applications/Symantec\ Solutions/LiveUpdate.app/Contents/MacOS/LiveUpdate -liveupdatequiet YES -liveupdateautoquit YES -update LUal

The command to update definitions only is:

/Applications/Symantec\ Solutions/LiveUpdate.app/Contents/MacOS/LiveUpdate -liveupdatequiet YES -liveupdateautoquit YES -update LUdf

You can monitor some information about the update process by watching the log file (via ssh access, for example):

tail -f /Library/Application Support/Symantec/LiveUpdate/liveupdt.log

Please note that after repairing the problem (updating applying the LiveUpdate package/updating LiveUpdate itself), the update process can take a very long time ! Just let it do its thing.

Note that this problem can also occur on a Windows client where – for example -you might be trying to run LiveUpdate from a batch file or other script. See:

http://www.symantec.com/business/support/index?page=content&id=TECH167145

Note that the specific error message is the same (“verifyCertPath():  objCertJ.buildCertPath failed to get cert path”)

The most likely cause of this problem on either platform (Mac or Windows) is that the software is installed without then updating all components right away. And/or updating only virus definitions over a long period of time, without updating the program components – the the extent that the client falls too far out of date to communicate with the update server(s) correctly.

Some tips for troubleshooting Apple’s Mail.app

PLEASE NOTE: The following is being provided for informational purposes ONLY and should not be attempted if unless you are already familiar and comfortable with working in the Terminal. In no way is this meant to be a comprehensive method (not at all) for troubleshooting Mail.app.

When you get a spinning cursor (also known as the “spinning cursor of death” or the “spinning pinwheel of death” (SPOD) or “spinning beach-ball of death” (SBOD), this typically indicates that some task or event (internal to, for the application) is not completing – and the application (Mail) is waiting and so are you. Apple states the following about the spinning cursor: “The spinning wait cursor… is displayed automatically by the window server when an application can’t handle all of the events it receives. In general, if an app does not respond for about 2 to 4 seconds, the spinning wait cursor appears.” See http://developer.apple.com

In 10.4 and 10.5 you can use the Terminal to get the process id of Mail and then watch what files it’s accessing. As of OS X 10.5, fs_usage probably won’t give the expected result(s), and so for 10.5 and later, it’s better to use dtrace tools such as rwsnoop and opensnoop.

To look for specific mail message that might be causing the problem, try the following, using the Terminal (Applications/Utilties)

(The initial “sudo” is just to escalate privileges early, so as to avoid a delay between launching Mail and authenticating afterward and missing the output. This assumes the user (account) in question has administrative privileges).

sudo echo ''; open -a /Applications/Mail.app; sudo opensnoop | grep mbox

To see more of what Mail is accessing, try (all one one line):

sudo echo ''; open -a /Applications/Mail.app; sudo opensnoop | grep -v mds | grep -v grep | grep $(ps aux | grep [M]ail | grep -v bundle | awk '{ print $2 }')

In both cases, press ctl (control) and: c simultaneously in the Terminal to cancel the operation. Mail will still continue to run, quit it normally as desired.

Please *DO NOT DELETE ANYTHING* at all, especially while Mail is running. If necessary, force-quit Mail (see “Force Quit” in the Apple menu). However it’s best not to force-quit an application until you’re quite certain that it’s hung.

Please do not touch anything outside of the user’s Library/Mail directory, unless the problem turns out to be a 3rd-party bundle, which you should see listed as being in /Users//Library/Mail/Bundles/

Whatever you do, please make sure you have a full, known-good backup (of your Home folder at the very least in this case).

Rather than attempting to state what you might do with what you find, if you’re not sure then please contact us at the Core Solution Group to arrange to bring your Apple computer to us, or if that’s not an option we can arrange a remote support session (it’s easy to set up).