Well, then I have to say I have no idea why this happens.
I've never heard of it, but maybe there's a cron job sending the SIGHUP (kill -s HUP/1 PID) to all processes. If anybody can explain this ...
I'll note this down in BUGS with a link to your post.
Please post your logfiles and output of commands wrapped in code tags:Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.Code:[code]output[/code]
It's the logrotate. In /etc/logrotate.d/ is a file moblock:
Or is it moblock because it did put the file there...Code:/var/log/moblock.log { rotate 12 daily compress delaycompress missingok notifempty postrotate [ ! -f /var/run/moblock.pid ] || kill -s HUP `cat /var/run/moblock.pid` endscript }
Last edited by skipo; October 31st, 2008 at 07:31 PM.
@jre,
moblock is not starting at boot on Intrepid and mobloquer is not working.
If we are talking about bugs, sometimes this line appears in /var/log/moblock.log:
After that, I have to restart moblock to get web working again.Code:Mon Nov 3 11:25:21| NFQUEUE: unbinding from queue 0
I haven't changed the nfqueue number, so it should bind to the default queue, and it does after restart:
Code:Mon Nov 3 11:33:52| NFQUEUE: binding to queue '92'
@skipo, logrotate:
oops, I should have thought of that. Of course, after logrotation a new logfile needs to be opened, therefore the reloading. So everything is ok here. Thanks for figuring that out on your own!
@lovinglinux, intrepid problems:
first time I hear this. What's in the logfiles? Does "moblock-control start" work? What's happening if you start mobloquer from the console?
@skipo: unbinding from NFQUEUE
I changed the default NFQUEUE number to 92 (instead of 0) in moblock-control 1.0 (the current version), to avoid conflicts with other firewalls. So I don't know where the queue 0 stems from - it should always be 92.
Have you any other applications that use NFQUEUE?
Did you have the unbind in previous versions, too?
For the records: Please post "dpkg -l libnetfilter-queue* libnfnetlink*".
It might be a bug in these libraries or in moblock, which occurs only for non-default queue numbers (= not 0).
Please post your logfiles and output of commands wrapped in code tags:Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.Code:[code]output[/code]
Re: unbinding from NFQUEUE
The error message in the code has a queue number of 0 hard coded, so it's misreporting the queue it just unbound from. I've seen the error myself, with moblock the only application using nfqueue.
If i'm understanding the code correctly, then recv() is used to read a message from kernelspace and passed to nfq_handle_packet() for parsing. The unbind error should only ever occur if the recv() returns an error which generally should never happen
After doing some more reading, recv() gets the data from netlink socket, prior to any queuing happening. The code doesn't capture the error code when this fails, but it could be due to a lack of buffer space (especially under high load). The l7 userspace filter code suggest the following;
If you get error messages about running out of buffer space, increase it with something like:
echo 524280 > /proc/sys/net/core/rmem_default
echo 524280 > /proc/sys/net/core/rmem_max
echo 524280 > /proc/sys/net/core/wmem_default
echo 524280 > /proc/sys/net/core/wmem_max
Last edited by noblem; November 4th, 2008 at 10:00 AM.
Here's the dpkg list:
I have no other applications using NFQUEUE.Code:Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===================-==============-====================================== ii libnetfilter-queue1 0.0.13-1 Netfilter netlink-queue library ii libnfnetlink0 0.0.25-1 Netfilter netlink library
I found this article about tuning netfilter performance;
http://www.inliniac.net/blog/2008/01...rformance.html
The article is aimed at snort_inline users, but the majority of it applies to moblock as well. Moblock doesn't currently allow the max queue size to be changed from the default, however I've just submitted a patch that allows this value to be tuned on the moblock developer site. The patch also fixes the misreported queue number in the error message and should hopefully print the error that caused moblock to unbind in the first place
Matt
Bookmarks