Bug 11687 - Qos crashes sometimes (32bit / Core 119)
Summary: Qos crashes sometimes (32bit / Core 119)
Status: CLOSED DEFERRED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: i686 Linux
: - Unknown - Minor Usability
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-23 19:13 UTC by Matthias Fischer
Modified: 2020-04-10 11:34 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Fischer 2018-03-23 19:13:36 UTC
Hi,

Every once in a while - not often, but you can count on it - QoS crashes with the following kernel messages in '/var/log/messages':

...
Feb 24 23:55:34 ipfire guardian[24869]: <info> BlockTime - has expired for 5.188.10.10 
Feb 24 23:57:35 ipfire collectd[21297]: Exiting normally.
Feb 24 23:57:35 ipfire collectd[21297]: collectd: Stopping 1 read threads.
Feb 24 23:57:35 ipfire collectd[21297]: ping plugin: Shutting down thread.
Feb 24 23:57:35 ipfire collectd[21297]: rrdtool plugin: Shutting down the queue thread. This may take a while.
Feb 24 23:57:36 ipfire kernel: grsec: Invalid alignment/Bus error occurred at a9033000 in /usr/local/bin/qosd[qosd:18591] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Feb 24 23:57:36 ipfire kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/local/bin/qosd[qosd:18591] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Feb 24 23:57:37 ipfire collectd[14150]: Initialization complete, entering read-loop.
Feb 24 23:57:49 ipfire kernel: DROP_INPUT IN=red0 OUT= MAC=00:16:01:02:c5:c6:34:31:c4:16:7d:5f:08:00 SRC=46.22.219.244 DST=192.168.99.254 LEN=44 TOS=0x00 PREC=0x00 TTL=248 ID=21677 PROTO=TCP SPT=56462 DPT=3496 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0xd2 
Feb 24 23:59:54 ipfire clamd[7784]: SelfCheck: Database status OK.
...
Mar 21 04:50:34 ipfire collectd[32100]: ping plugin: Shutting down thread.
Mar 21 04:50:34 ipfire collectd[32100]: rrdtool plugin: Shutting down the queue thread. This may take a while.
Mar 21 04:50:35 ipfire kernel: grsec: Invalid alignment/Bus error occurred at b1928000 in /usr/local/bin/qosd[qosd:3695] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Mar 21 04:50:35 ipfire kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/local/bin/qosd[qosd:3695] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Mar 21 04:50:36 ipfire collectd[23898]: Initialization complete, entering read-loop.
Mar 21 04:51:10 ipfire guardian[4211]: <info> Blocking 45.55.9.114 for 259200 seconds... 
Mar 21 04:51:10 ipfire guardian[4211]: <info> SNORT - ET CINS Active Threat Intelligence Poor Reputation IP TCP group 27 
...

I have intentionally added some preceding and some following log lines. It seems to me, as if the 'rrd'-plugin has something to do with this - but that is just guessing. All crashes happened under idle load, no running downloads.

System was still running without problems, but 'imq0'-QoS-graph was empty, only showing "-nan"-rates. 'red0'-graph was ok.

Restarting 'Qos' through GUI fixes this, but its somehow disturbing. Seems to be an old bug.

I will try to add more information as soon as it gets available.

Best,
Matthias
Comment 1 Peter Müller 2019-10-13 10:48:08 UTC
Since this has been opened a while ago: Do you still observer the same behaviour?
Comment 2 Matthias Fischer 2019-10-13 11:26:27 UTC
Can't say because I deactivated QoS and didn't use it since then, sorry.

Besides - as you can see - there was not much feedback.

If no one else can confirm this, bug can be closed.
Comment 3 Peter Müller 2019-10-28 15:23:40 UTC
Are you aware of https://blog.ipfire.org/post/on-quadrupling-throughput-of-our-quality-of-service ? I think that might fix your problem...
Comment 4 Peter Müller 2019-10-28 15:24:02 UTC
Anyway, consider migrating to 64-bit hardware, if possible. :-)
Comment 5 Peter Müller 2020-04-10 11:34:22 UTC
Okay, I am going to close this then. If it is still valid/reproducible, please reopen.