CubeSQL 5.0.1 64bit goes down every morning at 2:30

I have a fresh install of a virtual server with Ubuntu 14.04 64bit and a cubeSQLServer 64bit 5.0.1 on it. I have a new, valid company key for unlimited connections installed with it.

Everything seems to run fine and when I restart the server, then CubeSQL is autostarting fine, as expected.

But then, each morning at 2:30, the database server is shutting down. When I connect to it with cubeSQLAdmin, then I see only such message: “… 02:29:48 CubeSQL Server is shutting down”. (The Ubuntu Server is NOT restarted).

I couldn’t find any related messages in other log files, so far. Probably I am missing something…

Does anyone have an idea what might be going wrong here? Have you seen something like this before?

mac or window?? i don’t see any message like that…

Ubuntu is Linux

sorry… i didn’t see that part… i must be blind… i tested on mac and it is ok.

You could look in the kernel log and also the /var/log/messages, for entries right before the shotdown ocurred.
Also check root’s cron entries “sudo crontab -l” and the content of /etc/cron.daily.

Thanks Sascha! I already checked out messages, but could not find anything.

There are a some entries for a daily cron job at 2:16, so when my database goes down just 15 minutes later, then there might be a link to it. However, I am stuck with this - I guess i will need some help from our hosting provider.

I have an other vserver from them, which worked flawlessly for some years now, with cubesql. But now I don’t know whether this shutdown is linked to the new version of cubesql (5.0.1) or to the new version of Ubuntu Server I am using with it…

Daily cron job entries:

[quote]/etc/cron.daily/60sa-update
/etc/cron.daily/passwd.disabled
/etc/cron.daily/mlocate.disabled
/etc/cron.daily/spamassassin
/etc/cron.daily/cracklib-runtime.disabled
/etc/cron.daily/bsdmainutils.disabled
/etc/cron.daily/webalizer
/etc/cron.daily/apt-show-versions
/etc/cron.daily/apt.disabled
/etc/cron.daily/man-db.disabled
/etc/cron.daily/apache2.disabled
/etc/cron.daily/50plesk-daily
/etc/cron.daily/dpkg.disabled
/etc/cron.daily/logrotate
/etc/cron.daily/quota.disabled
/etc/cron.daily/aptitude.disabled
/etc/cron.daily/upstart.disabled[/quote]

I see nothing suspicious in your log.

+1 :slight_smile:

In the syslog it says this:

[quote]Apr 14 02:28:01 lvps92-51-146-94 CRON[6164]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Apr 14 02:30:01 lvps92-51-146-94 CRON[6186]: (root) CMD ([ -x /opt/psa/admin/sbin/backupmng ] && /opt/psa/admin/sbin/backupmng >/dev/null 2>&1)
Apr 14 02:30:47 lvps92-51-146-94 cubesql: Unable to block on epool[/quote]

So there are two commands running just before an error message appears from cubesql, and this exactly at the time where cubesql shuts down.

I’ll go and ask aunty google what run-parts and backupmng are doing, so that cubesql freaks out that way…

Or do you have any idea?

The crontab file looks like this:

# m h dom mon dow user	command
28 * * * * root cd / && run-parts --report /etc/cron.hourly
16 2 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
53 1 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
43 4 18 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

And when I test run-parts, then it lists the following jobs:

root@myserver:~# run-parts -v --test /etc/cron.daily /etc/cron.daily/50plesk-daily /etc/cron.daily/60sa-update /etc/cron.daily/apt-show-versions /etc/cron.daily/logrotate /etc/cron.daily/spamassassin /etc/cron.daily/webalizer

Now I wait for our provider whether they come up with a useful idea. Or maybe one of you guys have an enlightenment moment?

Maybe your Host is limiting the number of connections at this time for some reason?

What I know is, that HostEurope (my provider), did just release these new vServers with Ubuntu 14.04 and Plesk and it is highly likely that they are just now running into issues they did not discover during their beta tests (if ever they did such a thing …)

I see you have plesk panel installed. Seems something related to some backup procedure. Maybe the backup procedure is shutting down the DB to unlock files and proceed. Check the backup management in your plesk panel, if it’s not available, consult your hosting, maybe they are doing this.

My guess is you are running on top of Parallels Virtuozzo. Plesk integrates nicely with this as both are from Parallels. In a typical hypervisor the host would not have access to shut down individual processes. They could send a shutdown to the VM and everything down but not individual processes. However Virtuozzo is really just lightweight containers and the host can see all of your data/processes. So perhaps like Rick said some backup job is seeing open files or something and shutting it down. I would recommend a KVM or Hyper-V based host as they typically do not oversell and you are more in control of your processes.

if it is the backup software that is shutting it down, excluding the cubeSQL files (data files) from the backup software. Have cubeSQL do its backups to another directory that is backed up.

At the moment HostEurope confirmed my issue and moved it to 2nd level support. My closest guess so far is what Phillip Zedalis is writing.

My hackish workaround for the moment is a cron job which restarts cubesql server. But if we can’t solve this in a clean way, I will have to change the provider.

I do have a second vServer with the same provider which is running flawlessly since 4 years, with CubeSQLServer and some Xojo Webapps. It is only with their latest version vServer (the combination of Ubuntu 14.04 and Plex is a very new release), where we experience these problems.

The hoster as well as Marco Bambini advised me to run the cron jobs manually and see what’s happening. I’ve been running all those cron jobs I found in /etc/cron.daily, /etc/cron.hourly, /etc/cron.d/

They did not report any errors, but CubeSQL is still running. So either the cron-jobs are not responsible for the regular shutdown (it happened again last night, at 2:30) - or something changed with todays automatic update of plesk-panel.

I will see tonight, if it happens again.

At the moment I am still stuck with the workaround of a script, which gets invoked by a cronjob every 2nd minute, in order to keep CubeSQL Server alive. For tonight I disabled all other cron jobs and I will see if cubesql is still going down (it was doing it again, last night).

For those interested, the script looks like this:

#!/bin/bash if [[ ! `pidof -s cubesql` ]]; then sudo cubesqlctl start fi

I did stop all cron-jobs for the night and cubeSQL is still going down, once a night, always at the same time.

For my tests with CubeSQL Server, I am using a new vServer of HostEurope.

https://www.hosteurope.de/en/Server/Virtual-Server/

Neither their support, nor their online forum, nor Marco Bambini did have an idea on how to solve this problem.

it is a pity, because I had CubeSQL running very stable for several years when using the older versions of HostEurope, Ubuntu and CubeSQL (Virtual Server Linux MAX 5.0, Ubuntu 10.04 and CubeSQL 4.3). Only Plesk is the same version 12.0.18 on both servers.

So Phillip Zedalis’ guess is probably the closest shot and I am going to withdraw from my contract with HostEurope now.

SQLabs’ Marco Bambini did send me a new beta version of CubeSQL Server (5.0.2) which seems to solve my issue of shutting down once every 24hours, on the latest vServers of hosteurope.com (ubuntu 14.04 with Plesk version 12).

CubeSQL has now survived the last night and I keep the test running another 24 hours, to see if it really works. But for now it looks promising.

[quote=182724:@Oliver Osswald]SQLabs’ Marco Bambini did send me a new beta version of CubeSQL Server (5.0.2) which seems to solve my issue of shutting down once every 24hours, on the latest vServers of hosteurope.com (ubuntu 14.04 with Plesk version 12).

CubeSQL has now survived the last night and I keep the test running another 24 hours, to see if it really works. But for now it looks promising.[/quote]

that is GREAT news.