System grinds to a halt every few days, how do I trouble shoot?

If your description of the problem is the same as Bruce's I'd bet it is some sort of memory leak causing the problem leading to lots of swapping.

If you can leave a console running with "top" updating frequently that should give you a clue.

Has anyone reported this issue to Astaro?

If you need rock solid stability, I'd stay with the V6, it has been pretty stable for us.

im rebooting the system every 2 days at night. i think that asl 7.002 is not ready for production environment.

well, we now have a 220 in production. I'll let you all know how that goes from time to time.

You can download V6 .iso images from Astaro go to http://up2date.astaro.com/ and follow your closest mirror in one of the announcements), and I believe that the V7 license is backwards compatible with V6. If not, they should be able to convert the license for you.

Thanks for all the feed back, unfortunately I started with 7.001 just recently, I don't believe they sell V6.  I haven’t noticed the HD light being stuck on, but the ASL is about 25 miles away in a datacenter. I am now cycling the power remotely. I don’t see anything in the Kernel Logs to lead me in any direction. 

I sent my issue to Astaro Support yesterday and have yet to hear any response back from their team. I have bugged my local distributor, whom I purchased the software from and even had help setup the solution.  But it sounds like they are not experienced enough with V7, they just say how V6 is so wonderful! I think they are in for a rude awaking with accounting/reporting being removed and V7’s lack of stability so far.

I am on the verge of wishing I just kept with Sonicwall. I know ASL die-hards hate them, but at least they run for years without dieing and support most of the options that I was wanting. The only draw back was going to be the cost of the Pro level Sonicwall that I needed for throughput and connections.

What features of the asl are you using?  I may have another solution for you..[:)]

Update on my situation... here's what I just sent to Astaro to start a ticket on the "dead box" issue (it may apply to some of you other guys):

/QUOTE
I've been testing Version 7.0 (now 7.002) on a test system... been having problems with the system becoming totally unresponsive (no pings, no SSH console, No webadmin, no traffic flows)... when this occurs, the hard drive activity light goes solid on (there's a lot of disk activity going on).  Unfortunately, even though this has been happening on this and another test system (I swapped hardware for fun; both systems previously ran Version 6.x without a hitch) since Version 7 was released, I have not started a ticket because I couldn't see what was going on.  This is apparently a common thing with V7, as some others on the UBB are having the same "mystery" occur on their systems.  Well, I left the console up with "top" running all day today, and lo and behold I saw what was happening.  The httpproxy daemon just goes wild randomly, sucking up all the RAM it can (it gets up to about 92% of available memory, before the console dies-but it uses very little CPU when this is happening)... so the kernel starts pounding the swap file, which eats the CPU up.  I theorize that after a while the httpproxy daemon just dies (or the kernel zaps it), then the system busies itself cleaning up the swap.. then the system returns to normal operation.  After the "fun", the total memory usage dips down real low, like to almost 32%.  The system is not under heavy usage... it happened twice today, both times it happened right when I launched my web browser...

Yep, exactly as suspected, and now we know what process is responsible.

The funny thing is, I have a customer that has had ASG for  5 months now. Running V6. And this exact same thing is happening to him now. On V6! On V6 though it is Hyperdyper doing this, and then the kernel kills the processes. Usually every few days it happens now.

An update on my original post in this thread. 

I have worked with the Astaro support crew and shared logs etc with them. The errors are occurring with a process around the hard drive controller. No one is certain that it is a hardware issue or device driver issue. So far the system has been up and running for almost 48 hours, which is about how long I have been experiencing before the next episode. There are some more system level log files the Astaro staff wants to look at to help remedy the issue.

I don’t understand how it can be a device issue if it installs and runs just fine for the most part for a few days with thousands of concurrent connections and gigabytes of data transfer.

Still a little nervous, but at least a quick reboot solves the outage.

The funny thing is, I have a customer that has had ASG for  5 months now. Running V6. And this exact same thing is happening to him now. On V6! On V6 though it is Hyperdyper doing this, and then the kernel kills the processes. Usually every few days it happens now.

Hyperthreading??? I have that was on by default for my processor. Should we not have that one? I can disable it from within the BIOS. -Nick

--hyperdyper is a astaro process, not the same as multithreading.

Had the same happen to me twice before I caught was going on...

The responsible for the crash is the http proxy cache,  for some reason it keeps unneeded files on memory that are later passed to swap partition, this in time causes the sistem swap partition to fill up and after that the RAM fill's up too, then the system crashes....  what I did to work around this issue was to disable http proxy caching and cleaning the cache...  This resulted in lowering the swap space usage form 99% of a 1GB swap partition to 30%

regards

Had the same happen to me twice before I caught was going on...

The responsible for the crash is the http proxy cache,  for some reason it keeps unneeded files on memory that are later passed to swap partition, this in time causes the sistem swap partition to fill up and after that the RAM fill's up too, then the system crashes....  what I did to work around this issue was to disable http proxy caching and cleaning the cache...  This resulted in lowering the swap space usage form 99% of a 1GB swap partition to 30%

regards

Sounds like either a memory leak or the proxy cache is misconfigured.

I have the same problem, but my system crashes every hour! 

As far as I have seen the system is running out of memory. I can see in the Reporting / Hardware of the webadmin that swap usage reaches 100%. 

The system starts 2-4 new processes every minute: 

root      2662  0.0  1.1  37804  5744 ?        Ss   16:29   0:02 confd [master]
root      2710  0.0  0.9  37704  5128 ?        S    16:29   0:00  \_ confd [prpc]
root      2719  0.0  1.1  38652  6048 ?        S    16:29   0:01      \_ prpc [system]
root      2795  0.0  0.9  38628  4832 ?        S    16:29   0:00      \_ prpc [system]
root      3034  0.4  0.9  38764  4800 ?        S    16:29   0:13      \_ prpc [system]
root      3990  0.0  1.1  38632  5972 ?        S    16:30   0:00      \_ prpc [system]
root      4644  0.0  1.1  38636  6012 ?        S    16:30   0:00      \_ prpc [system]

and:

 5826  0.0  0.4   8112  2376 ?        Ss   16:33   0:00 /usr/local/bin/emailpki-sync.plx
root      5972  0.0  0.4   8112  2372 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
root      6016  0.0  0.4   8112  2380 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
root      6077  0.0  0.4   8108  2384 ?        Ss   16:35   0:00 /usr/local/bin/emailpki-sync.plx

Does anyone know what these processes are used for? How to avoid them?

Ernst



It shouldn't be the http proxy because it is disabled.

I have the same problem, but my system crashes every hour! 

As far as I have seen the system is running out of memory. I can see in the Reporting / Hardware of the webadmin that swap usage reaches 100%. 

The system starts 2-4 new processes every minute: 

root      2662  0.0  1.1  37804  5744 ?        Ss   16:29   0:02 confd [master]
root      2710  0.0  0.9  37704  5128 ?        S    16:29   0:00  \_ confd [prpc]
root      2719  0.0  1.1  38652  6048 ?        S    16:29   0:01      \_ prpc [system]
root      2795  0.0  0.9  38628  4832 ?        S    16:29   0:00      \_ prpc [system]
root      3034  0.4  0.9  38764  4800 ?        S    16:29   0:13      \_ prpc [system]
root      3990  0.0  1.1  38632  5972 ?        S    16:30   0:00      \_ prpc [system]
root      4644  0.0  1.1  38636  6012 ?        S    16:30   0:00      \_ prpc [system]

and:

 5826  0.0  0.4   8112  2376 ?        Ss   16:33   0:00 /usr/local/bin/emailpki-sync.plx
root      5972  0.0  0.4   8112  2372 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
root      6016  0.0  0.4   8112  2380 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
root      6077  0.0  0.4   8108  2384 ?        Ss   16:35   0:00 /usr/local/bin/emailpki-sync.plx

Does anyone know what these processes are used for? How to avoid them?

Ernst



It shouldn't be the http proxy because it is disabled.

how much memory do you ahve in the system?  What cpu, mobo, nic as well as hdd.

Hi,

the system has 512 MB ram, a P-III 1000 cpu, a 40GB disk with a 1GB swap and 2 3COM 905C-TX nics.

Some further investigation showed, that the selfmonitoring daemon stated 1 to 2 times a minute, that the dns resolver was not running properly and started a new instance of it.

I found a solution: Just reinstall the box [:D] . 

But it was a pitty, that the 7.002 configuration backup could not be loaded on a fresh installed 7.001 system. I had to do the basic configuration until the up2date brought me the 7.002. Since my configuration is simple I just reentered the rules by hand. 

Till now, the system runs. 

Ernst

I've heard through the grapevine that some Kernel updates may be in the forthcoming up2date package (in a week or so)... perhaps they will address the memory allocation issue---it seems to be happening in all sorts of different processes on different systems... we'll see.

I doubt that a kernel update would affect any memory issues unless there was a memory leak in the kernel itself. Hopefully the other updates they release along with it address the memory leaks.

eha, do you have a full process list from when the system became unresponsive?

When mine does that most of the time the logs go missing, so there is nothing to look at or review.

Once I have found two apps misbehaving, I covered that in another thread.

Ian M

I've heard through the grapevine that some Kernel updates may be in the forthcoming up2date package (in a week or so)... perhaps they will address the memory allocation issue---it seems to be happening in all sorts of different processes on different systems... we'll see.

We have an issue where the box became unresponsive on a production 7.002 220 appliance. It was due to a problem in communication with mysql and the self monitor. That was fixed (from what I can tell) by reloading the box. Not that big a deal. 

Unfortunately, we now have an issue where SSL VPN will stop responding. The rest of the box appears to run fine (it's the main box at the edge), but we have to reboot it to get it back to normal.

I doubt that a kernel update would affect any memory issues unless there was a memory leak in the kernel itself. Hopefully the other updates they release along with it address the memory leaks.

eha, do you have a full process list from when the system became unresponsive?

This issue isn't the kernel per se.  It is astaro has the swappiness set too high so the machine swaps out instead of reclaiming file cache space.  Also Astaro v7 is a pig and 512 megs of ram is not sufficient.  Astaro needs to set vm.swappiness to zero and increase the minimum requirements to 1 gigabyte of ram for the low end and 2 gigs for the midrange.  Higher end customers need 4 gigs(the 32-bit limit w/o PAE) for decent performance.  During my runs of v7 the machine was constantly swapping up to a quarter gigabyte.  Linux will not swap unless either the kernel is mistuned, the software is a memory hog, or both.  In Astaro's case it's both.

So, by working directly with a friendly Astaro support person they helped me to get my machine more stable. Everything they could trace down had to do with IRQs. So we placed the following, “no APIC” in the Kernal boot parameters using the Grub editor.

Thus limiting the IRQs to 15 and I disable a few hardware ports on the server such as the pare and serial ports to allow for less IRQ assignments. So far my system has stayed online with no crashing for 4 days. Much better than the 24 to 48 hours it was hardly working for. There seems to be in my opinion something with the way it uses swapdrive space, because after  a reboot my CPU would be pegged at 90% for about 10 minutes cleaning out the swap.