Apache goes unresponsive/unreachable during Direct Admin tally update cron run

caisc said:
1st deadlock (Apache unreachable issue) comes after 2 hours mostly, as a remedy I restart the Apache
2nd deadlock (Apache unreachable issue) comes after approx 15 min of 1st deadlock occurence, again as a remedy I restart the Apache
Click to expand...
Humm we it might be some bug. I think you reported it to DA. you might want them to have a look at the debug file while recreating the issue.
 
This appears to be some bug to me.

DA support team is looking to it, if possible I would like to request some admin at DA to look to it.

@smtalk and @zEitEr if you can spare out some time for this issue.

Thanks
 
Well it seems DA support team is not interested in getting this investigated.
They are tagging this as Apache related problem, but ignoring the fact that it only occurs while tally cron is running.
Not happy with their cheeky response.
 
CAISC said:
but ignoring the fact that it only occurs while tally cron is running.
Click to expand...
Which does not automatically mean that this is not caused by an Apache related problem.
And I presume they have looked in to what the tally is calling at that moment.
 
Richard G said:
And I presume they have looked in to what the tally is calling at that moment.
Click to expand...
And post that it was left on hold with a reply that "Sorry for the delay, the cause is not clear yet."
Waiting for some expert to check the root cause since 4+ days

In past few days I have already -
Reported 1 bug, its acknowledged and is fixed in upcoming DA release.
1 feature request that's implemented and applied in Alpha release

DA team shud give some attention to end users/server admins who are actively using the product and report issues so that DA can turn out a better product.
 
I also reported a bug 2 or 3 weeks ago for Letsencrypt, and they took a very good effort to find it, also took a couple of days because it needed some thorough investigation too.

If in the past few days they already fixed a bug reported by you and implemented a feature request, then it seems to me they do pay attention to their customers reporting issues.
It's logical that if you have a seperate issue which nobody else has, is probably something which is not that easy to reproduce and find the cause, so that takes longer.

So it doesn't seem fair to me stating the wouldn't give attention to their customers or making statements that they are giving cheeky responses.
I'm sure they will take you up on it.
 
Well waiting since last 5 days now, lets hope someone gets time for my ticket and the issue I am facing gets thoroughly investigated.
I have already ran several tests and updated ticket with the results.

Will keep you all posted with more details as and when I am updated.
 
Update from Gedas (DA Support team) -

It doesn't seem that a specific command of the tally does that. Likely something matches with something. Maybe some duplicate reloads/remounts happen or something like that. During that issue, logs doesn't say much, it also seem to happen at different times, during the same user. I've kind of managed to find the second when the new processes were stopped being created - nothing in the process list were happening that could influence that. Re tallying the user that was having tally calculated during the outage - all goes fine. With next tests we'll try to collect more statuses to be able to pin point to something.


Issue is still not resolved, Waiting for more information.
 
We had kind of the same (nightly after a cron and yes apache hangs) years ago once a week, SMTALK did solved it but was also a kind of bug , i can't find history, but even if i was not told what the real cause was , only a DA update came out shortly after it.

Not helps you but, i can remember however together with the solution a custom apache was running after it because we wanted HTTP2 and newer TLS version for it. So 2 things in one work the "BUG" and setup custom HTTP2 ( the manual for that was then not working for me, maybe i did it wrong).

It wasn't possible to restart apache then, a reboot was needed , i did found out later wtih htop how and which id to kill manually
 
Thanks @ikkeben Its seems similar sort of solutions is going to work in my case also.

As per last update by DA support team, they have made some customization to Apache and patched that bug.
Currently its under testing, maybe they'll do the same with the official release as well.
 
So it was a bit of a difficult bug. Well fine to see that it's fixed now. Thanks for reporting back.
 
You must log in or register to reply here.
Back
Top