[9.260] Application Control daemon not running

No, but I suggest you post application control and kernel log snippets from the time around the time you get these notifications so the devs can see what's happening (segfaults, etc.)

Yes, as BrucekConvergent already mentioned, please provide afc.log, kernel.log and selfmon.log

OK, I'm back with this.  After re-imaging my UTM120 with the SSI image for 9.270 I'm still getting Application Control daemon restarts fairly often.

For today, my KERNEL log is empty, although I have attached previous days logs which shows, IMO, nothing relevant.

The AFC.LOG has a billion entries in it, specifically as I'm tracking the use of Torrents [;)]

Interestingly, this log is peppered with these type of entries:

2014:10:29-00:39:48 utm ulogd[8991]: id="2017" severity="info" sys="SecureNet" sub="packetfilter" name="AFC Alert" action="log" fwrule="1" outitf="eth0" mark="0x303c" app="60" srcmac="0:1a:8c:13:34:9c" srcip="5.55.9.31" dstip="192.168.1.150" proto="17" length="116" tos="0x00" prec="0x00" ttl="111" srcport="10572" dstport="7881" 

2014:10:29-00:39:48 utm afcd[9236]: libnavl: F: navl_extensions_process_navl_syncevents: got 4129 byte sync message exceeding I/O buffer size (4096)



And only about a dozen lines later...



2014:10:29-00:40:04 utm ulogd[8991]: id="2017" severity="info" sys="SecureNet" sub="packetfilter" name="AFC Alert" action="log" fwrule="1" outitf="eth0" mark="0x303c" app="60" srcmac="0:1a:8c:13:34:9c" srcip="213.112.35.129" dstip="192.168.1.150" proto="6" length="170" tos="0x00" prec="0x00" ttl="49" srcport="58044" dstport="7881" tcpflags="ACK PSH" 

2014:10:29-00:40:04 utm afcd[14208]: libnavl: F: navl_extensions_process_navl_syncevents: got 5141 byte sync message exceeding I/O buffer size (4096)

and then looking at the SELFMON.LOG I can see a corresponding event where the AFC service is restarted...

2014:10:29-00:39:49 utm selfmonng[3844]: I check Failed increment afc_running counter 1 - 3

2014:10:29-00:39:54 utm selfmonng[3844]: I check Failed increment afc_running counter 2 - 3

2014:10:29-00:39:59 utm selfmonng[3844]: W check Failed increment afc_running counter 3 - 3

2014:10:29-00:39:59 utm selfmonng[3844]: W NOTIFYEVENT Name=afc_running Level=INFO Id=149 suppressed

2014:10:29-00:39:59 utm selfmonng[3844]: W triggerAction: 'cmd'

2014:10:29-00:39:59 utm selfmonng[3844]: W actionCmd(+):  '/var/mdw/scripts/afc restart'

2014:10:29-00:40:02 utm selfmonng[3844]: W child returned status: exit='0' signal='0'



AND....



2014:10:29-00:40:07 utm selfmonng[3844]: I check Failed increment afc_running counter 1 - 3

2014:10:29-00:40:12 utm selfmonng[3844]: I check Failed increment afc_running counter 2 - 3

2014:10:29-00:40:17 utm selfmonng[3844]: W check Failed increment afc_running counter 3 - 3

2014:10:29-00:40:17 utm selfmonng[3844]: W NOTIFYEVENT Name=afc_running Level=INFO Id=149 suppressed

2014:10:29-00:40:17 utm selfmonng[3844]: W triggerAction: 'cmd'

2014:10:29-00:40:17 utm selfmonng[3844]: W actionCmd(-):  '/var/mdw/scripts/afc restart'

I've attached the log files.  The bigger ZIP contains the afc and selfmon log files which I think are most relevant here.

The smaller zip file contains previous day kernel log messages which i think are irrelevant.

Anything else if needed please ask.

Cheers

Azz

Thanks for reporting. The provided information was exactly what I was looking for. I will open a Mantis issue for it.

Regards,
mlenk

Thanks for reporting. We are now tracking this as Mantis ID #33569

The Mantis ID #33569 is now under investigation.

We are planning to release a fix for this issue in Version 9.280.

The Mantis ID #33569 is now being worked on.

The Mantis ID #33569 is now fixed.

The Mantis ID #33569 is now closed.