Jira errors out on boot

I have a Jira server, installed on a ubuntu 12.04 Virtual image, hosted on Oracle Virtual box.
Oracle virtual box is installed on a mac mini osx mountain lion server 10.8.2

Last night I took a snapshot, then rebooted The entire device.  I had correctly shutdown The ubuntu server prior to rebooting the Mac mini.

Upon restarting I open up Virtual box, and start the virtual image.  I had selected the Fisheye user to autologin upon boot so that the fisheye service would start automatically.  
The virtual image of ubuntu starts, and boots to fisheye automatically.  However when I attempt to navigate via browser to the jira interface I at first received a http status 404 resource unavailable. Apache/Tomcat 6.0.32.  Not to be dismayed having had issues with my Virtualbox before I rolled back to a later snapshot.  I then was able to navigate to my Jira login page but received a curious error, and was unable to log in.  (view attached file)  I googled this error, and pretty much unilaterally received errors from jira 4.- regarding a upgrade error.  I was unable to login to this interface with several users.  I then rolled back to another backup I had some 2 weeks prior and that too resulted in the strange error in the file attached.  I then rebooted the whole device again, restored to the snapshot I took prior to the whole debacle, and now I am at the 404 error once more.

It is worthy to note that I did not setup this install of Jira, and am sadly taking over for someone else who is of course no longer available for comment.  I am not married to this particular install of Jira, but I cannot afford to lose the data.   Furthermore I need to be able to determine if infact the data that Jira is keeping is on the ubuntu virtual image, or somehow on the mac mini server in the database there.

I have checked the disk space, as I know that Jira will freak out if it runs out of disk space.  Currently here is what I have with a df -h

alexey@jiravm:/var/log$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       6.0G  4.8G  899M  85% /
udev           1000M  4.0K 1000M   1% /dev
tmpfs           403M  776K  402M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none           1007M   76K 1007M   1% /run/shm
/dev/sr0         53M   53M     0 100% /media/VBOXADDITIONS_4.2.4_81684

The virtual device has an 8 gig dynamically expanding hard drive, and is currently only using 3 gigs.  

The full partition here belongs to and .iso file that contains the VBOXadditions.
Who is Participating?
IllyankeshConnect With a Mentor Author Commented:
Restored to a snapshot prior to any changes to the resolve.conf file that I had made based on other research.

What had happened was that a database was installed on to the mac mini server that was different than the installed default postgres db.  When I had done some updates for the macosx server, when the server came back up, there were problems, that resetting the profilemanager db did not fix.  Running this reported an error connecting to the database.

My DB engineer was able to confirm that the 'correct' database was running, and good.  He reported that jira was trying to connect to the native DB, and not it's own db.  

We gutted the Server.app and rebooted the server.  When the server came back up, and we started our VM, the problem was gone.  Problem solved.
IllyankeshAuthor Commented:
alexey@jiravm:~$ /etc/init.d/postgresql start
chmod: changing permissions of `/var/run/postgresql': Operation not permitted
alexey@jiravm:~$ sudo su -postgres
sudo: unable to resolve host jiravm
IllyankeshAuthor Commented:       localhost       jiraserver

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
A proven path to a career in data science

At Springboard, we know how to get you a job in data science. With Springboard’s Data Science Career Track, you’ll master data science  with a curriculum built by industry experts. You’ll work on real projects, and get 1-on-1 mentorship from a data scientist.

IllyankeshAuthor Commented:
and here is the content of my /etc/hostname file.

IllyankeshAuthor Commented:
alexey@jiravm:~$ sudo apt-get  lynx
sudo: unable to resolve host jiravm
E: Invalid operation lynx
IllyankeshAuthor Commented:
alexey@jiravm:~$ ping jiravm
ping: unknown host jiravm
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
Clearly you have a problem with your resolv.conf or /etc/hosts file (that's hosts, not hostname)...

Your system is unable to resolve the hostname (itself) to any address... this is a fundamental problem that will make far more than jira not work!

Duncan RoeSoftware DeveloperCommented:
You must only configure as localhost Certainly not jiraserver nor even jiravm. I assume jiravm is your system and jiraserver is something else. But you have it as in your post http:#a38794313
If jiravm gets its IP address from the network, then you  should let dhcpc change /etc/hosts for you. Otherwise configure in /etc/hosts as Dan suggested in http:#a38796914
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
It's not usually such a big deal to assign names other than localhost to -- however, some apps may not like it for a number of reasons... ( I haven't read the link noted by duncan_roe above, but I think it's safe to assume it mentions some example of what I'm talking about).

The alternative is to either make entries in /etc/hosts, or -- especially if you're on a managed network -- point to an up-to-date DNS server on your LAN (possibly your AD server, PROBABLY the same place as your DHCP server)

Fix your name resolution problems, and the rest of your Jira install should be able to go along with whatever "playbook" you're using...

Good Luck!

Duncan RoeSoftware DeveloperCommented:
/etc/hosts as distributed with Slackware has carried this warning for a very long time
# By the way, Arnt Gulbrandsen <agulbra@nvg.unit.no> says that
# should NEVER be named with the name of the machine.  It causes problems
# for some (stupid) programs, irc and reputedly talk. :^)

Open in new window

The affected apps may not be so stupid. Network 127/8 is on the local interface which some apps may choose not to listen to.
IllyankeshAuthor Commented:
I worked, with my Database Engineer, after a call to apple support, and opening a support ticket with atlassian.  Combined with the logs that we pulled from the Server, and some insight given by apple support we were able to determine that the root issue was that there was a  rogue postgres process that we could not kill off.  I suggested removing the Server application from the server, my DB agreed.  So I gutted the Server app, and it's folders, and restarted the server.  Upon reboot the problem was gone.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.