Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 3 subscribers
  • Views 3327 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Dying Firewall

spid3r
I take it from my last post on the 17th that no one has had any problems with ASL 2.x or that no one cares to respond.  Either way, I'm a little discouraged.

I have a new problem however.  Today I had two processes take full control of ASL to the point of not being able to https, ssh, or even use the console to get in.  After waiting several minutes to ssh in and several reboots later the two processes would continue to show up and kill the machine.  Has anyone had this problem?  The two processes are "./mdw_deamon.pl" and "./aua.bin /etc/wfe/conf/aua_main.config.in".  I have no idea what these processes do and where they came from.  I have finally been able to kill them, but "./mdw_daemon.pl" is restarting and keeps taking up too much memory.  At this point I am going back to ASL 1.8.11 since that is the last good ISO that I have.

Any ideas?

Spid3r


This thread was automatically locked due to age.
Parents
  • 0
    hi spider,

    sorry for the lack of action here, but we can't quite keep up with the load of questions .. I'm trying to wade through the backlog   [:)]

    mdw_deamon.pl is the middleware. It is respawned by the superdaemon. aua.bin is the user authentication daemon.

    how much memory did the mdw take ? it should not take up so much that the machine is bogged down ... if you can still reproduce the situation, please do a "ps axf" to see which children the mdw has launched. I suspect something could be wrong there.

    aua.bin should be fine, there should never be multiple instances of it ..

    /tom

    [ 02 October 2001: Message edited by: tom ]
  • 0 in reply to tom_01
    Tom,

       Please forgive my past comments, I was under a little duress over the situation.  I have since reverted back to v1.8.11 and am a little skeptical about going forward again.  I have having no problems with the current version, in fact I believe my network is running a little faster than it was with v2.005, but it may be my imagination.  But to help troubleshoot I will do Up2date tomorrow morning before I leave for work.  I am curious why the MRTG for v2.0+ stops graphing to the web interface though.  I will keep you all informed of the progress and any future problems.

    Thanks,
    Spid3r
  • 0 in reply to spid3r
    Hey, if you are happy with your current version then stick with it  [:)]

    Never touch a running system ...

    But then, maybe you can run a freshly installed 2.0 in parallel to test it thoroughly ?  

    /tom
  • 0 in reply to tom_01
    Tom,

        I could only be so lucky to have another machine lying around to test.  The one I have running right now is a PII 333MHz, 128MB RAM, 8GB HDD, and two NICs.  I've noticed that v1.8.11 runs with less than 25% CPU usage and v2.0 runs with more than 50%.  Do you think my performance problem is hardware caused?

        I'm going to do a full backup before I go to v2.0+ so that if I have any problems It won't take me long to restore.  There are things I like in the new version, but the little things like no MRTG or my system locking up to the point of no network traffic are stumbling blocks.

    Thanks,
    Spid3r
  • 0 in reply to spid3r
    Tom,

       As in another post I am stuck at the Up2date v1.8.25 going to v1.9.17, but v1.9 isn't on the Up2date server.  I read in the other post that this may be in the process of being fixed?  If so, that's great I'll continue on with the Up2date to see if any of my earlier problems have cleared up.

       If they aren't cleared up, is there any way I can get my hands on a full version of 1.8.25?  That has been the *best* version that has run on my machine and if I can't live with v2.x, then having v1.8.25 will keep me from pulling my hair out or going to another distribution.

    Thanks,
    Spid3r
  • 0 in reply to spid3r
    After upgrading to 2.100 I'm having the same issue.  I would post the out put ps aux, but unfortunatly, as soon as the behavior appears, ssh'ing to the box is impossible.
  • 0 in reply to Michael Osten
    ok we're on the track of this one. seems to be an issue with /etc/wfe/conf/proxyauth.ini getting blown up by a runaway loop.

    If you have a chance to log in, do a

    rm -f /etc/wfe/conf/proxyauth.ini

    and

    /sbin/init.d/mdw restart
    /sbin/init.d/aua restart


    this should fix it temporarily.

    /tom

    [ 11 October 2001: Message edited by: tom ]
Reply
  • 0 in reply to Michael Osten
    ok we're on the track of this one. seems to be an issue with /etc/wfe/conf/proxyauth.ini getting blown up by a runaway loop.

    If you have a chance to log in, do a

    rm -f /etc/wfe/conf/proxyauth.ini

    and

    /sbin/init.d/mdw restart
    /sbin/init.d/aua restart


    this should fix it temporarily.

    /tom

    [ 11 October 2001: Message edited by: tom ]
Children
  • 0 in reply to tom_01
    Tom,

         Is this problem still being worked?  I've re-installed with v2.0 and used up2date to get to 2.016 and my mdw_deamon.pl is eating my memory again.

    ALARM - to much memory for a single process:
    90288 kb for ./mdw_deamon.pl
    root      4767  1.6 22.9 90288 29188 ?       S    15:31   1:32 ./mdw_deamon.pl

    Astaro Security Linux  2.016

        I reboot and it comes back.  I kill the process and it respawns and spawns defucnt processes.  I am at a loss.

    -Spid3r
Unfiltered HTML