cmkelley
Very Senior Member
Turns out not to be a 384.11 problem only ...
I had been counting on syslogd and klogd only being restarted via the "restart logger" service event. However, I have found that they also restart after a "restart time" service event.
This is further complicated by the fact that a "restart time" service event also generates a "dropbear [xxxx]: Early exit: Terminated by signal" log entry. So I don't know if it's the restart time service event or dropbear being terminated that trips the restart without using logger. I suspect the latter but I wouldn't even know how to look in the source to figure this out, nor fix it, obviously. Or maybe restart time is the only one terminating dropbear "early".
Eric, is this a bug in ASUS' code, or "working as designed", or something that can be fixed?
I had been counting on syslogd and klogd only being restarted via the "restart logger" service event. However, I have found that they also restart after a "restart time" service event.
This is further complicated by the fact that a "restart time" service event also generates a "dropbear [xxxx]: Early exit: Terminated by signal" log entry. So I don't know if it's the restart time service event or dropbear being terminated that trips the restart without using logger. I suspect the latter but I wouldn't even know how to look in the source to figure this out, nor fix it, obviously. Or maybe restart time is the only one terminating dropbear "early".
Eric, is this a bug in ASUS' code, or "working as designed", or something that can be fixed?
Last edited: