Error dataskq on cron (sh -c /bin/hostname)

Hello everyone,
I have a big problem on a VPS (xen), distribution and debian DirectAdmin latest version.

When you run the command /usr/local/directadmin/dataskq rom cron (for example, after I made a echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue) remains a freeze which employs many resources and cron does not run the commands after that.
Here is a screenshot of the situation:



I thought it was a problem in the host that was not resolved. I tested both the file and host, both in my main dns for the host and the reverse IP (ptr), the hostname is right (like the ip).
I also checked, perhaps, that there was an error in resolv.conf but nothing.
I do not know where most beat their heads.

Someone can help me?

tnks

No

no answer on the forum, no response via email (from technical support to directadmin), live chat almost always offline, its serious!

No one answers cause nobody knows why its not working right. Your code really doesnt show anything.

Can you run the command from the prompt:

sh -c /bin/hostname

Check /var/log/directadmin/error.log

Check /var/log/messages

Show an output of the top command when it gets stuck.

I have already done many trials, both as user "root" as user "nobody" (user directadmin through "sudo-u nobody ...") and runs (shell) everything correctly.
In the logs is not returned any error (or logs of the system on "/var/log/", or logs on to directadmin on "/var/log/directadmin"), even in "/var/log/directadmin/error.log".


You can find out why the cron run this command?

How often are you trying to run it from cron?

What is the full cron line?

Jeff

The cron is launched automatically by DirectAdmin both during the night whether strong performance through:

First you wrote that you inserted a crontab somewhere:

after I made a echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

Click to expand...

and later you wrote that it's launched automatically by DirectAdmin. Which is correct? Please explain further.

Also, you haven't answered my question. Please see:
and post the entire crontab line as you use it on your server.

Without this information no one is going to be able to even attempt to figure out the problem unless you have an experienced administrator log onto your server and do some forensic work. If we were to do that it would cost a minimum of us$125. So please help us help you through these forums, where it's free if any of us can figure it out.

Thanks.

Jeff

Considering the fact that you have with something like 100 licenses and we can not get a response from technical support via email, I think something should be resolved. But I am not here to make controversy.

The "cron" which launched the process indicted, is to DA:


Exactly the line:



As you may know (and is discussed in the FAQ), with this "echo" in the file /usr/local/directadmin/data/task.queue:


the first launch of CRON, run a check on everything (DA settings, check the disk quotas, etc.etc.).

Do you expect that this is an official DirectAdmi support forum? It's not. DirectAdmin staff tells me they respond to every support requrest; perhaps your email isn't getting through to them.

in case it's not you should probably try to reach them here.

I'm still confused as to where you put the line:

Jeff

Bump, I have exactly the same issue on a VPS Xen new server (centos5)

It is indeed the nightly directadmin cron that is hanging on a sh -c /bin/hostname, it triggers the hostname command and thenj hangs and consumes a lot of cpu..

Really strange because when I run the commande manually, it gracefully returns the hostname in less than one second.

I willl do some tests to investigate..

I renamed /bin/hostname to /bin/hostname.ori and the taskq still hangs on this..
??

I completely replaced the hostname script by a simple shell script doing an echo of the hostname and I still have the cronjob locking on this.

weird..

sshd: root@pts/1
465 pts/1 Ss 0:00 \_ -bash
19730 pts/1 S+ 0:00 \_ ./dataskq
19733 pts/1 R+ 0:23 \_ sh -c /bin/hostname


I give up for today...

I may be experiencing something related to this issue as well.

I'm still trying to figure out what is happening, but it is difficult because there really is no information in any logs that lets me know what's going on (or at least why the system is locking up).

Here is my situation:
I have a server running XenServer Express with 4 virtual machines (all Debian 4). One of those VMs is my webserver with DirectAdmin on it. DirectAdmin and all Custombuild related apps are up to date.

Three times since Jan. 1st I have had the VM running DirectAdmin completely lock up and require a "hard" restart. None of the other three VMs have had any issues. Basically the only clue I have is that the last line in syslog before the system apparently locks up is the DirectAdmin dataskq running.

What is interesting, and something that caught my attention the most recent time this happened (which was today at 4:56pm EST) is that I noticed there was an error message that had been logged right after every time dataskq was run notifying me that the named (bind) log could not be renamed ever since I set up a log for the named service because of a permission error. I fixed this issue, but the real interesting part is that this message was NOT logged in syslog after the dataskq line that occurred at 4:56 today. So apparently the system locked up after starting dataskq but before it got to the point of checking the log rotations.

I don't really know what to do at this point, but I'll contact DirectAdmin support if it happens again. The only thing I'm 99% sure of at this point is that it does have something to do with the dataskq application from DirectAdmin.