possible core issue in service start order: c-icap + clamav #276
Comments
|
This may be a glitch in the proverbial matrix... https://github.com/opnsense/core/blob/master/src/etc/rc.freebsd starts services in a more or less fixed random order |
|
@kekek2 Where do you get this error? I can't reproduce it. I'm seeing c_icap starting before clamd but I dont see such errors. |
|
I think it can depend on how the file system returns the file names from the disk ;/ https://github.com/opnsense/core/blob/master/src/etc/rc.freebsd#L68 |
|
/var/log/system.log:
/var/log/c-icap/server.log:
time configctl clamav start
|
|
But it retries and finally works without manual interaction, correct? |
|
Only manual restart c_icap
|
fichtner
changed the title
|
I dunno, maybe we need to delay a bit after c-icap start? |
|
Why isn't there a numbering scheme like on linux with S03clamd where you can easily set a boot order? :/ |
|
well there is but it requires the full rc system of freebsd or better emulation to allow ordering |
|
@mimugmail on current GNU/Linux this does not exist as well (1). What you can do is writing a dependency into the unit file which should also work with with rc. (1) look for "After" in systemd service files |
|
Same issue here. After restarting c-icap, works like a charm:
Thanks! |
|
Is there a way to 're-register' the clamav module without restarting c-icap? I ask cause clamd crashes sometimes unexpectedly - using monit it can be restarted, but then c-icap has still the error |
|
you can also cycle c-icap the same way? |
|
My workaround diff --git a/www/c-icap/src/opnsense/scripts/OPNsense/CICAP/setup.sh b/www/c-icap/src/opnsense/scripts/OPNsense/CICAP/setup.sh
index 9e1e741..e84a7d5 100755
--- a/www/c-icap/src/opnsense/scripts/OPNsense/CICAP/setup.sh
+++ b/www/c-icap/src/opnsense/scripts/OPNsense/CICAP/setup.sh
@@ -7,3 +7,52 @@ chmod 750 /var/run/c-icap
mkdir -p /var/log/c-icap
chown -R c_icap:c_icap /var/log/c-icap
chmod 750 /var/log/c-icap
+
+# check which services to enable
+if [ -f /etc/rc.conf ]; then
+ . /etc/rc.conf
+fi
+if [ -f /etc/rc.conf.local ]; then
+ . /etc/rc.conf.local
+fi
+for RC_CONF in $(find /etc/rc.conf.d -type f); do
+ . ${RC_CONF}
+done
+
+rc_enabled()
+{
+ rc_filename=${1}
+ name=${2}
+
+ # check if service has a name
+ if [ -z "${name}" ]; then
+ echo "Error: no name set in ${rc_filename}"
+ return 1
+ fi
+
+ # check if service has a variable
+ eval "$(grep "^rcvar[[:blank:]]*=" ${rc_filename})"
+ if [ -z "${rcvar}" ]; then
+ # FreeBSD does this, leave here for debugging
+ #echo "Error: no rcvar set in $rc_filename"
+ return 1
+ fi
+
+ # check if service is enabled
+ eval "enabled=\$${rcvar}"
+ if [ "${enabled}" != "YES" ]; then
+ return 1
+ fi
+
+ return 0
+}
+
+rc_filename="/usr/local/etc/rc.d/clamav-clamd"
+eval "$(grep "^name[[:blank:]]*=" ${rc_filename})"
+
+if ! rc_enabled ${rc_filename} ${name}; then
+ return 0
+fi
+
+/usr/local/opnsense/scripts/OPNsense/ClamAV/setup.sh
+${rc_filename} startEdit by Fabian: Correct Syntax highlighting |
|
The formatting was off... |
...You mean me?^^ |
|
@Stephanowicz yes, does this work as expected? |
|
yep, I tried it manually by stopping clamd.... Nevertheless I consider this jut as a workaround - maybe the c-icap guys could implement something that tries to start the av-scanner when detecting that it can't be accessed and then reinits the Connection... |
|
Ok so we know what to do, now we need to figure out a robust way to integrate it. Alex’s suggestion isn’t bad but it should ideally be more portable / avoid code duplication. |
|
Ok, meanwhile I stumbled over the same problem as in OT... Regarding monit and its possibility to also test file contents I made another workaround: In monit add a new test with condition then add a new service test with One 'annoying' thing is, that You have to add a start/stop/restart parameter, though it's not needed... One also needs to enter a stop script, otherwise You'll get a syntax error - I used As test enter the test You created before. I copied the error text manually to the log file for testing and received a
hope this helps! Cheers, Stephan |
|
After having tested it now thoroughly I changed the test condition to It also has been shown that c-icap doesn't restart properly in this condition - but monit will try it again the next cycle and then succeeds... So, this is working, but it feels somehow like a dirty hack... :D |
|
Update: Cheers, Stephan |
|
@mimugmail maybe patching this section may help:
The file is |
|
No this won’t help as we don’t use the full RC system.
… On 1. Oct 2017, at 13:08, Fabian Franz, BSc. ***@***.***> wrote:
@mimugmail maybe patching this section may help:
The file is /usr/local/etc/rc.d/c-icap
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@fichtner This is not even the full issue for your information. If the ICAP server is down, squid will make troubles too (it will say that it cannot reach the ICAP server and blocks the connection (it will mark the server as down)). The advantage here is that squid connects to the ICAP server as soon as it gets an HTTP request so this is a bit dangerous as a race condition too. |
|
Should be simple and effective: https://github.com/opnsense/plugins/blob/79d4a7c79f7652ffbe2cadec397c26acdc6f033d/www/c-icap/src/etc/rc.syshook.d/50-c-icap.start Please share your test results. :) |
|
Hi, thank You - well, anything else that needs to be done - or just copy the file to rc.syshook.d? Cheers, Stephan |
|
Hi @Stephanowicz, Yes, copy file, make sure to chmod to 755. Cheers, |
When system boots, c-icap starts before clamd, and could not open tcp socket:
The text was updated successfully, but these errors were encountered: