Upgrading Directory and Admin

When upgrading Percussion, the wizard asks for a Percussion directory. There is no information given as to what the starting directory is. Am I to put simply /Percussion? No clue.

Then, as perhaps a confirmation that I’ve gotten it wrong, it asks for an admin username and password. Nothing I try works.

Disappointingly, the documentation provides no insight on this.

Hi Matt,

To keep things simple, you can just input the full CM1 installation directory starting from the root of your server’s filesystem, which is typically:

/home/{linux_user}/Percussion

If I remember correctly, the user you installed CM1 with was named “webmaster”, so in your case the path would be /home/webmaster/Percussion

Yes, if the installer is unable to find a CM1 installation in the path you specified, you won’t be able to get past the authentication step.

I’m sorry this became a point of frustration for you, but this is actually is very helpful feedback, as we’ve been updating some of our technical documentation lately. I’ll certainly make a note of the issues you encountered here.

Thanks, Nathaniel.

When I finished the install, I get this message:

*****SERVER AND OTHER COMPONENTS INSTALLATION*****
You must now run the InstallDaemon.sh script located
in the root of your installation directory to complete
the install. You must have root privileges in order
to run this script.

When I type “sudo sh InstallDaemon.sh” I get errors:
“InstallDaemon.sh: 107: Syntax error: Bad fd number”

I’ve given that file all the permissions it needs to run. Still nothing.

Again, this step doesn’t seem to be in the documentation. Now our Percussion server is down mid-install and I can’t start it up without completing.

Hey Matt,

You should actually be all set to run CM1 at this point. Using the Daemon to start and stop CM1 is optional. If you’ve used the Daemon to start and stop CM1 in the past (by running ./RhythmyxDaemon start … from the {cm1_root}/bin directory), you should still be able to do so now. Alternately, you can bypass the Daemon (and maybe you have been doing so in the past) by running the CM1 start-up and shutdown scripts directly. To do this, navigate to your CM1 root directory and run:

To start CM1: nohup ./StartServer.sh &
To stop CM1: ./StopServer.sh

Neither command starts Percussion. When I try “./RhythmyxDaemon start …” it says “*** Percussion Rhythmyx Server daemon starting…” but it immediately drops to a command line and nothing in the log moves.

When I try nohup ./StartServer sh &, I get this error:
nohup: ignoring input and appending output to ‘nohup.out’

Here are the last lines in my server log:

2013-05-09 17:44:09,147 INFO [org.apache.coyote.ajp.AjpProtocol] Pausing Coyote AJP/1.3 on ajp-127.0.0.1-9998   
2013-05-09 17:44:10,147 INFO [org.apache.catalina.core.StandardService] Stopping service jboss.web   
2013-05-09 17:44:10,163 INFO [org.apache.coyote.http11.Http11Protocol] Stopping Coyote HTTP/1.1 on http-127.0.0.1-9992   
2013-05-09 17:44:10,164 INFO [org.apache.coyote.ajp.AjpProtocol] Stopping Coyote AJP/1.3 on ajp-127.0.0.1-9998   
2013-05-09 17:44:10,165 INFO [org.jboss.web.tomcat.service.TomcatDeployer] undeploy, ctxPath=/, warUrl=.../deploy/jboss-web.deployer/ROOT.war/   
2013-05-09 17:44:10,165 INFO [org.jboss.web.tomcat.service.TomcatDeployer] undeploy, ctxPath=/invoker, warUrl=.../deploy/http-invoker.sar/invoker.war/   
2013-05-09 17:44:10,166 INFO [org.jboss.web.tomcat.service.TomcatDeployer] undeploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/   
2013-05-09 17:44:10,271 INFO [org.yajul.log.JuliToLog4JService] stopped   
2013-05-09 17:44:10,276 INFO [com.arjuna.ats.jbossatx.jta.TransactionManagerService] Stopping recovery manager   
2013-05-09 17:44:10,303 INFO [org.jboss.system.server.Server] Shutdown complete   

At this point, we are stuck without our users able to get into our CMS.

Hey Matt,

To quickly confirm, the command to start the StartServer.sh script is:

nohup ./StartServer.sh &

I noticed the period was missing in your example, so just want to make sure here. The nohup message is expected – it’s a method to unlock the script from your terminal window, so that when you close the window the CM1 script continues to run. You can view the contents of nohup.out to see if any errors are appearing.

The typo was an error on my part in posting the message, but thanks for clarifying.

The nohup doesn’t produce a reboot of the CM1, and when I try to log the file, this is what we get:

sudo tail -f nohup.out   
-su: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   
./StartServer.sh: 67: ./doStart.sh: Permission denied   

I’ve tried tail -f nohup.out too, with the same result.

./StartServer.sh & ./doStart.sh all have the permissions needed.

Matt,

Looks like a simple ownership issue. Do you typically run CM1 as the webmaster user, or as the root user (either logged in as root, or using “sudo”)? If you choose to run CM1 as the root user, simply running sudo nohup ./StartServer.sh & should do the trick here.

Otherwise, you probably ran the upgrade script using sudo, which changed the CM1 file ownership from webmaster to root. You can change ownership for the full Percussion file tree back to the webmaster user by running:

sudo chown -R webmaster.webmaster /home/webmaster/Percussion/

Once you’ve done this, the plain nohup command without sudo should work. If you continue to have any trouble with this, I would be happy to setup a web meeting to help you get back up and running ASAP. Let me know.

Nathaniel,

The sudo chown for the entire folder did the trick–I was doing this for single files.

Thanks for all your help, and sorry that it came down to an ownership issue.

No worries, Matt. The simple hang-ups are always the most frustrating. And again, we certainly need to update our documentation surrounding the upgrade process.