Fixing a busted Tridion publisher

So I have to work this evening… want to know why? Because today my Tridion virtual machine magically stopped publishing after a reboot, I could smell Java libraries from the start!

Let me explain…

I went to bed feeling pretty satisfied after a long, hard day of coding. Same as any other day I simply closed the lid of my laptop to send my computer into hibernation, I foolishly (I admit) left my VM running.

Lesson one, always close (suspend) your VM after use in case your laptop crashes. Guess what? My laptop crashed during wake up the next morning which required the holding of the power button with eyes closed and crossed fingers on the other hand.

This ‘hard’ shut down also shut down my VM which crashed (blue screen of death) and freshly rebooted on next load. After the reboot any pages I published were constantly ‘Waiting for publish’. I opened ‘services’ to find the Tridion Transport and Publisher services were stopped… for what reason?

Tridion services

I tried manually starting, but this lead to the immediate stopping with an error message stating:
“Some services stop automatically if they are not in use by other services or programs”

My next move… check the Tridion Content Manager section in the windows event viewer. It was here that my suspicion was confirmed…. JAVA!

How nice of it to tease me by not giving the path…

Looking in my program files revealed two installations of the Java runtime library.

  1. 32-bit version:  C:\Program Files (x86)\Java\jre6\ (Time stamp: 6 months ago)
  2. 64-bit version:  C:\Program Files\Java\jre6\ (Time stamp: 2 weeks ago (31st August 2012))

2 weeks ago!? I loaded the Oracle site and, boom, guess when the last release of Java was? 31st August 2012.

First thought: “my 64-bit Java files have had a monster lying in them for two weeks just waiting to get out.”

Second thought: “Had I really not rebooted my VM for two weeks!?”

It’s always important when installing Tridion to set the JRE to never auto update, so I headed over to Control Panel->Programs and clicked on the Java button to check my java settings and to confirm that the version was set to ‘never auto download’, it was:

Java never auto update

I still don’t know why my Java updated. Perhaps I installed something that updated the files without realising. Anyway, I knew I was getting closer to my error.

I checked my registry under HKEY_LOCAL_MACHINE/SOFTWARE/JAVASOFT/ and all the Java paths including JavaHome were pointing at my 32-bit version. So why had an update of the 64-bit version killed the publisher?

I copied the files from a backed up installation into my 64 bit Java folder then rebooted, still no joy even though the configuration now mimicked my working backup VM.

Concluding that Java had become miss configured somewhere I decided to fully reinstall Java from scratch. I went to Add/Remove Programs in Control Panel and uninstalled the Java SE. At this point it removed the 32-bit version because the JavaHome variable was pointing there. I headed over to my 64-bit program files folder and renamed the Java folder to ‘Java_bak’ (basically, the 64-bit installation had to go too).

Running “Java -version” in a CMD complained it didn’t know ‘java’… it was gone, my life was slowly getting better.

I downloaded the latest version of both the 64 and 32 bit installers from http://www.oracle.com/technetwork/java/javase/downloads/index.html.

At this point I was still curious as to why I needed both a 32 and 64-bit Java versions if my registry JavaHome was only using the 32-bit version. Since the Tridion CM is installed in /Program Files (x86), it was logical that it uses the 32-bit version of Java so that’s the version I installed first. Joy! The Transport and Publisher services now started, I had my life back! Or did I…?

A quick restart of all Tridion services, including ‘SDL Content Porter’ (don’t forget about that bad boy hiding a little further down the services list) and they all started except the Deployer. The problem had jumped ship

Checking the event viewer gave me a new error:

I googled around a bit, twiddled my thumbs and then realized that the Deployer is on the Content Delivery side and must be using the 64-bit Java. So I installed the latest 64-bit version of Java. At this point I again had two Java folders, one under /Program Files/ and one under /Program Files (x86)/.

Another shutdown/bootup and all my services started nice and dandy! I’ve been publishing my heart away ever since.

The 64-bit is required for the Deployer and Content Delivery server roles, and the 32-bit for the Content Manager; On a VM you typically have both CM and CD installed on the same host, hence needing both Javas.

Food for thought:
We all know you should set Java to never auto update, but sometimes it can sneak in there without you realising. I just wanted to share my experience with anyone who may come across a similar situation in the future.

At least now you may feel a little more confident on where to look when your Tridion suddenly stops publishing and hopefully have the confidence to remove Java and perform a new clean install.

7 thoughts on “Fixing a busted Tridion publisher

  1. Great post. One thing to add: if your Java configuration is somehow broken and your running the web site on IIS (.NET), the problem sometimes shows up as a ‘windows process activation service has stopped’ error. This stops your entire app pool instantly. The only way out is to check the JavaSoft key in the registry and make sure all the paths are correct. Or – of course – uninstall and reinstall java like you did.

  2. Thanks for your addition Quirijn. Java configuration errors can be one of those fiddly issues that has you pulling your hair out all day. The more places we know to look, the better.

  3. Hi,

    I had the some problem, about a month ago, on one of the instances we are running.

    It had not been accessed for a while, logged in and saw the install screen to update Java. It failed to install for some unknown reason then Publisher and Transport services failed to start. The other Tridion services were fine. The CMS and CDA were on the same instance.

    Solution was the reinstall Java, first the 32 bit then the 64 bit versions.

    Alastair

  4. Thank you for the post! A client had same issue with Tranport Service. They had Java update set to automatic on servers. The solution was to uninstall and reinstall specific version of Java (1.6.0_26).

  5. Just adding on to my last comment. The latest Java version probably would have worked as well. (I will give it a shot on local VM). Client just wanted to keep same Java version on all servers.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>