The asd (ASUS security daemon) process was originally discussed here: https://www.snbforums.com/threads/what-is-asd-process.76242/ That thread was forced closed, so I'm having to post a new thread for this update on the state of things.
Several of us here have disabled the asd daemon, through a variety of methods, including "kill -19" (SUSP), and replacing it with a bind mount that just sleeps in a loop or whatever. Well, as of the most recent 3004.388.9 firmware, or possibly a bit earlier, something has changed under the hood. The asd daemon is regularly relaunched at run-time, every so often (a few minutes at most). For anyone using a "sleep script" replacement for it, the "sleep" commands keep running, especially if given a very long timeout such as 2147483647.
What I noticed on my own router, is it would lose internet connectivity about once every two weeks, requiring a reboot to get things going again. This turns out to be due to memory exhaustion from having thousands of those "sleep 2147483647" commands all running long after each new instance of asd is launched.
One can check for this, by logging in (ssh/telnet), and doing this: ps | grep sleep
So, the solution is to simply use a much shorter sleep timeout. I've gone with 30 seconds now, and all remains well.
Alternatively, one could just let asd run and do its thing. After all, it's never messed up anything before, right? Oh, wait, it has.
Cheers
Several of us here have disabled the asd daemon, through a variety of methods, including "kill -19" (SUSP), and replacing it with a bind mount that just sleeps in a loop or whatever. Well, as of the most recent 3004.388.9 firmware, or possibly a bit earlier, something has changed under the hood. The asd daemon is regularly relaunched at run-time, every so often (a few minutes at most). For anyone using a "sleep script" replacement for it, the "sleep" commands keep running, especially if given a very long timeout such as 2147483647.
What I noticed on my own router, is it would lose internet connectivity about once every two weeks, requiring a reboot to get things going again. This turns out to be due to memory exhaustion from having thousands of those "sleep 2147483647" commands all running long after each new instance of asd is launched.
One can check for this, by logging in (ssh/telnet), and doing this: ps | grep sleep
So, the solution is to simply use a much shorter sleep timeout. I've gone with 30 seconds now, and all remains well.
Alternatively, one could just let asd run and do its thing. After all, it's never messed up anything before, right? Oh, wait, it has.
Cheers
Last edited:
