Avast WEBforum
Business Products => Avast Business => Avast Business for Linux => Topic started by: goodmanbeats on January 19, 2009, 11:15:18 PM
-
Hello all,
I sent an email to the support _at_ avast .com address today (mentioned in the README of the Linux version Avast), then later read in the demo license email that this address is unmonitored.
So, my problem is, I would happily use Avast for mail scanning purposes on multiple machines, but the available binaries are compiled on FreeBSD version 4. The current stable version of FreeBSD is 7.1. The libc_r library, which avast is linked to dynamically, has been changed to libpthread years ago. I tried to make avast running by compiling a libc_r for FreeBSD7, but it does not work, if one builds a libc_r.so.7 and links it to libc_r.so.4, the avastd starts listening to sockets, etc, but when the avastcmd or avastlite scanner is invoked, or the avastd socket is used, nothing happens, the applications just hang forever.
Is there any hope for a new binary build soon?
-
Hello all,
I sent an email to the support _at_ avast .com address today (mentioned in the README of the Linux version Avast), then later read in the demo license email that this address is unmonitored.
So, my problem is, I would happily use Avast for mail scanning purposes on multiple machines, but the available binaries are compiled on FreeBSD version 4. The current stable version of FreeBSD is 7.1. The libc_r library, which avast is linked to dynamically, has been changed to libpthread years ago. I tried to make avast running by compiling a libc_r for FreeBSD7, but it does not work, if one builds a libc_r.so.7 and links it to libc_r.so.4, the avastd starts listening to sockets, etc, but when the avastcmd or avastlite scanner is invoked, or the avastd socket is used, nothing happens, the applications just hang forever.
Is there any hope for a new binary build soon?
Hallo,
yes, that's the infamous FreeBSD-threadlibrary hell. There were *MANY* threading library candidates used on FreeBSD in the past few years (libthr, libkse, libc_r, libpthread), all claimed to be interface-compatible, and thus, dependency-issues could be usually solved using /etc/libmap.conf aliases (and in the fact, this approach was usually used/recommended).
Btw. which one of those four libraries is the "recommended one" now, is a question - probably not libpthread, but libthr.
Have a look here: http://roy.marples.name/node/332
Anyway, there are two latest builds, so let's try to run them using /etc/libmap.conf, available here:
http://public.avast.com/~cimbal/BSD4/libavastengine-4.7.5-i586.tar.gz
http://public.avast.com/~cimbal/BSD4/avast4server-3.1.5-i586.tar.gz
http://public.avast.com/~cimbal/BSD5/libavastengine-4.7.5-i586.tar.gz
http://public.avast.com/~cimbal/BSD5/avast4server-3.1.5-i586.tar.gz
In the case of no success, we'll make extra build for FreeBSD7, but ... who knows, which threading model will be the new default in FreeBSD8 :)
regards,
PC
-
Hello,
Thank you for the quick answer. I did not find links to these binaries on the Avast web site.
I tried both versions, starting with the libs and app built for FreeBSD5. No luck.
I ended up always with:
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by
/usr/lib/libavastengine-4.so.7 not found
and i have no libpthread libs on my system, just symlinks to libthr (which needed to be compatible with lpthread, but it is not.)
The version compiled for FreeBSD4 acts particularly like the old version i was trying very first, it simply hangs. the shmprobe in its installer simply starts using 99.7% CPU. I tried overwriting the libavast but the best I could reach is a
root@Merlin# avastcmd
avastcmd: can not initialize avast! engine: Cannot allocate memory
How can we move forward with that?
By the way, FreeBSD developers pretend to use libthr from 6.x... maybe until forever, but who knows.. :)
http://bugs.gentoo.org/192711
-
I tried one more thing, installed the compat5x and compat6x libs, and set up libmap with these.
effect:
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
-
Hello,
Thank you for the quick answer. I did not find links to these binaries on the Avast web site.
I tried both versions, starting with the libs and app built for FreeBSD5. No luck.
I ended up always with:
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by
/usr/lib/libavastengine-4.so.7 not found
and i have no libpthread libs on my system, just symlinks to libthr (which needed to be compatible with lpthread, but it is not.)
The version compiled for FreeBSD4 acts particularly like the old version i was trying very first, it simply hangs. the shmprobe in its installer simply starts using 99.7% CPU. I tried overwriting the libavast but the best I could reach is a
root@Merlin# avastcmd
avastcmd: can not initialize avast! engine: Cannot allocate memory
How can we move forward with that?
By the way, FreeBSD developers pretend to use libthr from 6.x... maybe until forever, but who knows.. :)
http://bugs.gentoo.org/192711
Hallo,
but, have you tried mapping via /etc/libmap.conf (not via pure symlinks) here? It's the right mechanism (not sym-linking, although this was used too).
http://bsdtips.utcorp.net/mediawiki/index.php/Do_not_symlink_missing_shared_libraries
I simply don't believe, that library X was replaced by X+1, with a lack of interface-functionality. But, from the past, there were also FreeBSD releases with totally crippled threading environment, preventing all 3rd party apps from running on them... With 5.3, we decided to link to libpthread, because libc_r was presented as obsolete, have a look here: http://www.freebsd.org/releases/5.3R/errata.html
sigh, four threading libs, one less compatible than another, we'll have to create another cross-compiling chain for the 7.0, as it seems :(.
regards,
pc
-
Hello,
Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.
lrwxr-xr-x 1 root wheel 8 Jun 20 2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x 1 root wheel 9 Jun 20 2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x 1 root wheel 10 Jun 20 2008 /usr/lib/libpthread_p.a -> libthr_p.a
I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.
The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found
error.
If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.
I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.
I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it :)
Thanks,
Daniel
-
Hello,
Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.
lrwxr-xr-x 1 root wheel 8 Jun 20 2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x 1 root wheel 9 Jun 20 2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x 1 root wheel 10 Jun 20 2008 /usr/lib/libpthread_p.a -> libthr_p.a
I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.
The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found
error.
If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.
I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.
I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it :)
Thanks,
Daniel
Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically :(. Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 :).
regards,
pc
-
Hello,
Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.
lrwxr-xr-x 1 root wheel 8 Jun 20 2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x 1 root wheel 9 Jun 20 2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x 1 root wheel 10 Jun 20 2008 /usr/lib/libpthread_p.a -> libthr_p.a
I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.
The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found
error.
If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.
I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.
I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it :)
Thanks,
Daniel
Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically :(. Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 :).
regards,
pc
btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).
also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).
regards,
pc
-
Hello,
Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.
lrwxr-xr-x 1 root wheel 8 Jun 20 2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x 1 root wheel 9 Jun 20 2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x 1 root wheel 10 Jun 20 2008 /usr/lib/libpthread_p.a -> libthr_p.a
I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.
The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found
error.
If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.
I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.
I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it :)
Thanks,
Daniel
Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically :(. Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 :).
regards,
pc
btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).
also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).
regards,
pc
Any update on the FreeBSD7 build?
I mapped libc_r.so and libpthread.so to libthr.so.2 in libmap.conf and I can start the avastd/avastlite without getting the LIBTHREAD_1_0 error. However, both program will exit with "cannot allocate memory"
Here is the log from avastd.log
Feb 27 13:07:19 avastd[2836]: info: Starting avast! daemon
Feb 27 13:07:19 avastd[2836]: info: using this configuration for section 'local'
Feb 27 13:07:19 avastd[2836]: info: daemons count: default=5, maximum=15
Feb 27 13:07:19 avastd[2836]: info: avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Feb 27 13:07:19 avastd[2836]: info: user: root
Feb 27 13:07:19 avastd[2836]: info: datadir: /var/lib/avast4
Feb 27 13:07:19 avastd[2836]: info: tempdir: /var/lib/avast/tmp
Feb 27 13:07:19 avastd[2836]: info: licensefile: /var/lib/avast4/License.dat
Feb 27 13:07:19 avastd[2836]: info: scan subdirectories: yes
Feb 27 13:07:19 avastd[2836]: info: avast! engine flags: testall
Feb 27 13:07:19 avastd[2836]: info: packers: types=A, maxdepth=32, summary archives=no
Feb 27 13:07:19 avastd[2836]: info: packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Feb 27 13:07:19 avastd[2836]: info: maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Feb 27 13:07:19 avastd[2836]: info: log scan results: logclean loginfected logscanerrors
Feb 27 13:07:19 avastd[2836]: info: listenning on unix socket /var/run/avast4/local.sock
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2837)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2838)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2839)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2840)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2841)
Feb 27 13:07:23 avastd[2836]: notice: process exited (pid=2840)
Feb 27 13:08:05 avastd[2836]: error: closing process local[2841]: cannot initialize avast! engine: Cannot allocate memory
Feb 27 13:08:05 avastd[2836]: notice: process exited (pid=2837)
Thanks
-
Hello,
Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.
lrwxr-xr-x 1 root wheel 8 Jun 20 2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x 1 root wheel 9 Jun 20 2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x 1 root wheel 10 Jun 20 2008 /usr/lib/libpthread_p.a -> libthr_p.a
I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.
The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found
error.
If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.
I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.
I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it :)
Thanks,
Daniel
Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically :(. Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 :).
regards,
pc
btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).
also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).
regards,
pc
Any update on the FreeBSD7 build?
I mapped libc_r.so and libpthread.so to libthr.so.2 in libmap.conf and I can start the avastd/avastlite without getting the LIBTHREAD_1_0 error. However, both program will exit with "cannot allocate memory"
Here is the log from avastd.log
Feb 27 13:07:19 avastd[2836]: info: Starting avast! daemon
Feb 27 13:07:19 avastd[2836]: info: using this configuration for section 'local'
Feb 27 13:07:19 avastd[2836]: info: daemons count: default=5, maximum=15
Feb 27 13:07:19 avastd[2836]: info: avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Feb 27 13:07:19 avastd[2836]: info: user: root
Feb 27 13:07:19 avastd[2836]: info: datadir: /var/lib/avast4
Feb 27 13:07:19 avastd[2836]: info: tempdir: /var/lib/avast/tmp
Feb 27 13:07:19 avastd[2836]: info: licensefile: /var/lib/avast4/License.dat
Feb 27 13:07:19 avastd[2836]: info: scan subdirectories: yes
Feb 27 13:07:19 avastd[2836]: info: avast! engine flags: testall
Feb 27 13:07:19 avastd[2836]: info: packers: types=A, maxdepth=32, summary archives=no
Feb 27 13:07:19 avastd[2836]: info: packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Feb 27 13:07:19 avastd[2836]: info: maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Feb 27 13:07:19 avastd[2836]: info: log scan results: logclean loginfected logscanerrors
Feb 27 13:07:19 avastd[2836]: info: listenning on unix socket /var/run/avast4/local.sock
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2837)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2838)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2839)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2840)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2841)
Feb 27 13:07:23 avastd[2836]: notice: process exited (pid=2840)
Feb 27 13:08:05 avastd[2836]: error: closing process local[2841]: cannot initialize avast! engine: Cannot allocate memory
Feb 27 13:08:05 avastd[2836]: notice: process exited (pid=2837)
Thanks
Yes, i'm working on big FreeBSD cleanup, right now (and the whole previous week).
<whining>
Results are quite pesimistic, nearly all dirty hacks in our build tools are here because of ... FreeBSD oddities, and MUST stay here. It's really hard to produce binary app that work on all recent BSDs. We must offer at least 3 different "flavours" of them - libc_r, pthread and libthr ones. Plus, here's the infamous 64k stack-problem, silent threading lockup for libc_r/libc mixing (which occurs even when the library depends on libc_r), repeatedly changed meaning of -pthread linking scenarios, and even horrible tools like libtool that make usage of all workaround 10x more complex and then to "correct" linking back to the bad state.
</whining>
The (slightly reduced) set of resulting workaround works fine, as it seems for now, and so just expect the testing packages, probably tommorow (unless some other nightmare appears).
regards,
pc
PS: for validating, i'm using 12 different distros... uff. big mess, that FreeBSD :(.
-
Hello,
Yes, I made a libmap.conf, without libmap.conf, almost nothing worked..
i did not make any symlinks, the symlinks were installed by freebsd by default.
lrwxr-xr-x 1 root wheel 8 Jun 20 2008 /usr/lib/libpthread.a -> libthr.a
lrwxr-xr-x 1 root wheel 9 Jun 20 2008 /usr/lib/libpthread.so -> libthr.so
lrwxr-xr-x 1 root wheel 10 Jun 20 2008 /usr/lib/libpthread_p.a -> libthr_p.a
I googled that LIBTHREAD_1_0 required error message, but found almost nothing.
I think the problem is that libpthread was changed to libthr silently, and libthr does not include this.
The fun is, if I set up libmap to use the libc_r from the freebsd5 binary-compatibility package, I get the
/usr/libexec/ld-elf.so.1: /usr/lib/libpthread.so: version LIBTHREAD_1_0 required by ./bin/shmprobe not found
error.
If I use the libpthread from the freebsd5 or freebsd56 compatibility libs, I get a
/usr/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.2: Undefined symbol "__malloc_lock"
error.
I spent some hours yesterday trying all variations of all libraries, but no luck yet. Maybe I missed something.
I can set up a jail with a full 7.0 system for you on a public ip (of course with legal copyright background, NDA, etc) if this helps, but I guess you won't have resort of it :)
Thanks,
Daniel
Hmm,
seems that they really produced another version, where threading libs were changed again... and the change was, again, incompatible and preventing 3rd party apps from running. I really don't know about any other system where this hell happens so often and periodically :(. Well, we'll build FreBSD7-dedicated packages, linked against libthr.... sigh, and fear what threading-library mess will come with FreeBSD8 :).
regards,
pc
btw. you can also try to download stock libpthread source package (ftp://ftp.gnu.org/gnu/glibc/, the linuxthreads subpackage, which belongs to your version of glibc). creating/testing dedicated crosscompiler toolchain for freeBSD-7 might take a while (there are more prioritised tasks).
also, it's possible to take libs from freebsd6, and run against them (i wonded why the compatibility packages that you mentioned above, didn't help in this case).
regards,
pc
Any update on the FreeBSD7 build?
I mapped libc_r.so and libpthread.so to libthr.so.2 in libmap.conf and I can start the avastd/avastlite without getting the LIBTHREAD_1_0 error. However, both program will exit with "cannot allocate memory"
Here is the log from avastd.log
Feb 27 13:07:19 avastd[2836]: info: Starting avast! daemon
Feb 27 13:07:19 avastd[2836]: info: using this configuration for section 'local'
Feb 27 13:07:19 avastd[2836]: info: daemons count: default=5, maximum=15
Feb 27 13:07:19 avastd[2836]: info: avast! interface: /var/run/avast4/local.sock (timeout: 300s)
Feb 27 13:07:19 avastd[2836]: info: user: root
Feb 27 13:07:19 avastd[2836]: info: datadir: /var/lib/avast4
Feb 27 13:07:19 avastd[2836]: info: tempdir: /var/lib/avast/tmp
Feb 27 13:07:19 avastd[2836]: info: licensefile: /var/lib/avast4/License.dat
Feb 27 13:07:19 avastd[2836]: info: scan subdirectories: yes
Feb 27 13:07:19 avastd[2836]: info: avast! engine flags: testall
Feb 27 13:07:19 avastd[2836]: info: packers: types=A, maxdepth=32, summary archives=no
Feb 27 13:07:19 avastd[2836]: info: packers bombs: maxfilesize=500000, maxcompressratio=50, compresscheckthreshold=10000
Feb 27 13:07:19 avastd[2836]: info: maxtotalcompressratio=100, totalcompresscheckthreshold=1000
Feb 27 13:07:19 avastd[2836]: info: log scan results: logclean loginfected logscanerrors
Feb 27 13:07:19 avastd[2836]: info: listenning on unix socket /var/run/avast4/local.sock
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2837)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2838)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2839)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2840)
Feb 27 13:07:19 avastd[2836]: info: started new 'local' process (pid=2841)
Feb 27 13:07:23 avastd[2836]: notice: process exited (pid=2840)
Feb 27 13:08:05 avastd[2836]: error: closing process local[2841]: cannot initialize avast! engine: Cannot allocate memory
Feb 27 13:08:05 avastd[2836]: notice: process exited (pid=2837)
Thanks
Yes, i'm working on big FreeBSD cleanup, right now (and the whole previous week).
<whining>
Results are quite pesimistic, nearly all dirty hacks in our build tools are here because of ... FreeBSD oddities, and MUST stay here. It's really hard to produce binary app that work on all recent BSDs. We must offer at least 3 different "flavours" of them - libc_r, pthread and libthr ones. Plus, here's the infamous 64k stack-problem, silent threading lockup for libc_r/libc mixing (which occurs even when the library depends on libc_r), repeatedly changed meaning of -pthread linking scenarios, and even horrible tools like libtool that make usage of all workaround 10x more complex and then to "correct" linking back to the bad state.
</whining>
The (slightly reduced) set of resulting workaround works fine, as it seems for now, and so just expect the testing packages, probably tommorow (unless some other nightmare appears).
regards,
pc
PS: for validating, i'm using 12 different distros... uff. big mess, that FreeBSD :(.
Hi, nice to hear that FreeBSD7 build is coming. I was actually installing a FreeBSD 5.5-R VM when I saw this post ... ;D Frankly, I would suggest that you should start to move to FreeBSD 6.x and 7.x now as 4.x and 5.x are end of life product. Although I believe lots of people are still using 4.x/5.x, they will move to new version eventually. Perhaps you could release new version/function on 6.x/7.x builds, and only maintain security/bug fix for 4.x/5.x. Just my 2 cents.. :D
-
Hallo,
it's rather about library-hell dependencies and workarounds - so, we'll support all of them, because many people changed the libraries to get other 3rd party apps running, so there's a mess in general.
some testing packages would be available tommorow.
regards,
pc
-
Hallo,
it's rather about library-hell dependencies and workarounds - so, we'll support all of them, because many people changed the libraries to get other 3rd party apps running, so there's a mess in general.
some testing packages would be available tommorow.
regards,
pc
Hallo, just to keep you informed,
bad news - one day more necessary (on that $#@!-bsd, gdb is unable to fire hardware watchpoints, and thus, it was necessary to trace manually through all those functions to the problematic place - uff. :(
good news - culprit found, finally - stdcall caller arg-coalescing breaks in this case the switch to auxiliary stack (because there are 64kB only stacks per thread, in general). In debug-build, of course, this optimisation is off and thus everything works :>
466d7: 83 7e 1c 00 cmpl $0x0,0x1c(%esi)
466db: 75 1c jne 466f9 <avscanRepairEx+0xf191>
466dd: c7 45 e8 0c 00 00 00 movl $0xc,0xffffffe8(%ebp)
466e4: ff 75 e8 pushl 0xffffffe8(%ebp)
466e7: 68 bc cb 16 00 push $0x16cbbc
466ec: e8 fc ff ff ff call 466ed <avscanRepairEx+0xf185>
466f1: 8b 45 e8 mov 0xffffffe8(%ebp),%eax
466f4: e9 5b ff ff ff jmp 46654 <avscanRepairEx+0xf0ec>
466f9: 6a 00 push $0x0
466fb: 8d 45 f0 lea 0xfffffff0(%ebp),%eax
466fe: 6a 00 push $0x0
46700: 6a 00 push $0x0
46702: 68 00 00 10 00 push $0x100000
46707: 50 push %eax
46708: 6a 04 push $0x4
4670a: 6a 00 push $0x0
4670c: e8 d5 08 0f 00 call 136fe6 <fsGetAvastOemString+0xaa3a>
46711: 8b 45 f0 mov 0xfffffff0(%ebp),%eax
46714: 05 00 ff 0f 00 add $0xfff00,%eax
46719: 89 65 ec mov %esp,0xffffffec(%ebp)
4671c: 89 c4 mov %eax,%esp
4671e: ff 75 18 pushl 0x18(%ebp)
46721: ff 75 14 pushl 0x14(%ebp)
46724: ff 76 1c pushl 0x1c(%esi)
46727: e8 ba bc ff ff call 423e6 <avscanRepairEx+0xae7e>
4672c: 88 c3 mov %al,%bl
4672e: 8b 65 ec mov 0xffffffec(%ebp),%esp
46731: 83 c4 28 add $0x28,%esp ;root of all evil
46734: ff 75 f0 pushl 0xfffffff0(%ebp)
46737: e8 46 17 0f 00 call 137e82 <fsGetAvastOemString+0xb8d6>
4673c: 84 db test %bl,%bl
4673e: 59 pop %ecx
4673f: 75 09 jne 4674a <avscanRepairEx+0xf1e2>
46741: c7 45 e8 10 a4 00 00 movl $0xa410,0xffffffe8(%ebp)
46748: eb 9a jmp 466e4 <avscanRepairEx+0xf17c>
:).
pc
-
Hallo,
uff, never more :(. but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:
http://public.avast.com/~cimbal/freebsdalpha
NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000 sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.
NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).
regards,
pc
Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near :(
i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).
-
Hallo,
uff, never more :(. but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:
http://public.avast.com/~cimbal/freebsdalpha
NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000 sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.
NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).
regards,
pc
Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near :(
i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).
Hi,
Thank you for your effort. The program seems runs fine...:)... Just one glitch in the installtion.... The installation script will change the permission of /tmp to 0700, which cause many other programs panic, and also have some difficulties setting up the cron job. Please see the error message for cron job below.
Installer will insert call for virus database update to the crontab now.
This task can be done by avastvpsupdate.sh or avastvpsupdate.pl.
Installer will check which way is suitable for you, and also will try
to download the latest database version. This step might take up to few
minutes under some circumstances, but can be interrupted anytime by
pressing Ctrl-C (in this case, add the line to the crontab manually
and probably fix the problem in /etc/avastvpsupdate.conf).
chmod: 3-03-09-15-32-23-77557: No such file or directory
crontab: no crontab for root
-
Hallo,
uff, never more :(. but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:
http://public.avast.com/~cimbal/freebsdalpha
NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000 sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.
NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).
regards,
pc
Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near :(
i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).
Hi,
Thank you for your effort. The program seems runs fine...:)... Just one glitch in the installtion.... The installation script will change the permission of /tmp to 0700, which cause many other programs panic, and also have some difficulties setting up the cron job. Please see the error message for cron job below.
Installer will insert call for virus database update to the crontab now.
This task can be done by avastvpsupdate.sh or avastvpsupdate.pl.
Installer will check which way is suitable for you, and also will try
to download the latest database version. This step might take up to few
minutes under some circumstances, but can be interrupted anytime by
pressing Ctrl-C (in this case, add the line to the crontab manually
and probably fix the problem in /etc/avastvpsupdate.conf).
chmod: 3-03-09-15-32-23-77557: No such file or directory
crontab: no crontab for root
Thanks for report, William XP, we'll fix those "minor" problems too.
btw. NOTE 3 - "freebsd4" and "freebsd5" have "auxiliary stack" feature built-in (yes, default spacing between threads is 128kB for libc_r and even 64kB/69kB for 5.3's threading libraries), but "freebsd6" doesn't use this (it seems that the spacing is reasonable enough for freebsd6.x and 7.x - 1MB).
regards,
pc
-
Hallo,
uff, never more :(. but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:
http://public.avast.com/~cimbal/freebsdalpha
NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000 sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.
NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).
regards,
pc
Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near :(
i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).
Hi,
Thank you for your effort. The program seems runs fine...:)... Just one glitch in the installtion.... The installation script will change the permission of /tmp to 0700, which cause many other programs panic, and also have some difficulties setting up the cron job. Please see the error message for cron job below.
Installer will insert call for virus database update to the crontab now.
This task can be done by avastvpsupdate.sh or avastvpsupdate.pl.
Installer will check which way is suitable for you, and also will try
to download the latest database version. This step might take up to few
minutes under some circumstances, but can be interrupted anytime by
pressing Ctrl-C (in this case, add the line to the crontab manually
and probably fix the problem in /etc/avastvpsupdate.conf).
chmod: 3-03-09-15-32-23-77557: No such file or directory
crontab: no crontab for root
Thanks for report, William XP, we'll fix those "minor" problems too.
btw. NOTE 3 - "freebsd4" and "freebsd5" have "auxiliary stack" feature built-in (yes, default spacing between threads is 128kB for libc_r and even 64kB/69kB for 5.3's threading libraries), but "freebsd6" doesn't use this (it seems that the spacing is reasonable enough for freebsd6.x and 7.x - 1MB).
regards,
pc
Hi zilog,
some more report...
I can't get the program running in amavisd.. it will complain...
Mar 6 15:53:32 ns amavis[78761]: (78761-01) (!!)run_av (avast! Antivirus) FAILED - unexpected exit 22, output="avastcmd: can not initialize avast! engine: VPS file was destroyed"
Mar 6 15:53:32 ns amavis[78761]: (78761-01) (!!)avast! Antivirus av-scanner FAILED: /usr/local/bin/avastcmd unexpected exit 22, output="avastcmd: can not initialize avast! engine: VPS file was destroyed" at (eval 117) line 527.
my av setting is amavisd.conf is (i install Avast with --prefix=/usr/local )
### http://www.avast.com/
['avast! Antivirus', ['/usr/local/bin/avastcmd','avastcmd'],
'-a -i -n -t=A {}', [0], [1], qr/\binfected by:\s+([^ \t\n\[\]]+)/ ],
However, I can manually run avastcmd to scan (but the scan speed is slow)
for example, this scan took about 4 seconds before I can see the statistic report.
#avastcmd License.dat
/var/lib/avast4/License.dat [OK]
#
# Statistics:
#
# scanned files: 1
# scanned directories: 0
# infected files: 0
# total file size: 1.3 kB
# virus database: 090305-1 05.03.2009
# test elapsed: 0s 2ms
Any ideas?
-
hmhm,
the "tmp chmod-ded to 700" problem isn't reproducible here - could you give us more details? (version of your system, installation log)...
hint - spawn sh, and run install this way:
./mkinstall.sh 2>&1 | tee inst.log
... and copy/paste the log here, thanks in advance.
regards,
pc
-
hmhm,
the "tmp chmod-ded to 700" problem isn't reproducible here - could you give us more details? (version of your system, installation log)...
hint - spawn sh, and run install this way:
./mkinstall.sh 2>&1 | tee inst.log
... and copy/paste the log here, thanks in advance.
regards,
pc
Hi zilog,
I believe this variable was the root cause -- "PSH_UNIQUE=`date +%h-%m-%y-%H-%M-%S`-$$"
It generated a filename with a space in front of it, which cause the following command (ie. chmod, md5) to fail. After I changed it to "`date +%d-%m-%y-%H-%M-%S`-$$" , the problem went away.
As for the amavisd problem, I figured out that my amavisd didn't have appropriate permission to access /var/lib. After I change the permission, it runs fine now. (although it is still slow to manually run avastcmd)
Thanks.
-
Hallo,
please note that the (present) runtime vps takes ~50MB. because it is (and must be - security reasons) user-separated, this amount is taken for each user. And, sections in avastd allow defining "users". Thus, more user sections -> more memory needed.
avastcmd is a standalone app, and creates the runtime once (or takes it from SHM, when it founds it's already up and usable), but again, it's per-uid thing.
Thus, sysctl -w kern.ipc.shmmax=256000000; sysctl -w kern.ipc.shmall=65536 - and avast would load the runtime VPS fine (hopefully).
regards,
pc
-
Hallo,
please note that the (present) runtime vps takes ~50MB. because it is (and must be - security reasons) user-separated, this amount is taken for each user. And, sections in avastd allow defining "users". Thus, more user sections -> more memory needed.
avastcmd is a standalone app, and creates the runtime once (or takes it from SHM, when it founds it's already up and usable), but again, it's per-uid thing.
Thus, sysctl -w kern.ipc.shmmax=256000000; sysctl -w kern.ipc.shmall=65536 - and avast would load the runtime VPS fine (hopefully).
regards,
pc
Another problem... this time it is avastd...
The daemon could start successfully, however, when I try to run avastlite, it will hang forever. In addition, when I issued a shutdown flag (kill -TERM) to the daemon process, its child processes won't die. I have to use kill -9 to remove them. The /var/log/avast4/avastd.log did not report any errors.
here is my configuration...
avastd.rc
# Copyright(C) 2005-2007 ALWIL Software
# Config file for /etc/init.d/avastd
#
# Note: this is NOT the main avastd configuration file. That is in
# /etc/avastd.conf file. This merely sets startup options for the
# avastd initscript.
# Command to be executed before the daemon is started
#AVASTD_PRECOMMAND=""
# Command to be executed after the daemon is stopped
#AVASTD_POSTCOMMAND=""
# For information on avastd options, see "avastd -h"
AVASTDCONF="/usr/local/etc/avastd.conf"
#AVASTDOPTS="$AVASTDOPTS -c ${AVASTDCONF}"
avastd.conf
#There are two types of sections - the special [global] section and up
#to five user-defined scanner sections.
#Global section:
[global]
# use system logger to log messages instead of logging into a file
# disabled by default
usesyslog = no
# specify syslog facility when syslog logging is enabled
# please refer to syslog(3) manual page (part with facility
# argument parameters) to list all possible values
# default is LOG_DAEMON
syslogfacility = LOG_DAEMON
# specify location of a logging file
# default log file is /var/log/avast4/avastd.log
# NOTE: if you want to log to file, disable 'usesyslog' option
logfile = /var/log/avast4/avastd.log
# controls the maximum size (in bytes) of each log file before it's
# rotated. It's functional only if the file logging is enabled
# set to 0 to disable log rotating (default).
maxlogfile=200000000
#200MB
# don't log informational messages (LOG_INFO priority)
# this option allows to disable logging of informational messages
# when a new connection is established/closed
# disabled by default
ignoreloginfo=0
#Scanner sections:
#The section name is the name of scanning service and the parameters
#within the section defines its attributes. The name is user-defined
#and can also be used as a base for the socket file name of the daemon
#located in /var/run/avast4 directory, when there's no interface value
#set.
[local]
# defult number of pre-forked daemons to be launched at start
# a value of 0 disables the daemon (default is 3, maximum is 25)
daemoncount = 5
# this option defines maximum count of forked avastd daemons
# new avastd daemon is forked to accept a new connection, when the
# others are occupied and it will be automatically killed after
# 3 minutes of inactivity
# (default is 25)
maxdaemoncount = 15
# bind daemons to specific local (Unix) file socket or IP address
# NOTE: please use firewall to restrict connections when binding
# to public IP address
#listen = 127.0.0.1:5036
#listen = /var/run/avast4/mailscanner.sock
#listen = 127.0.0.1:5037
#listen = /var/run/avast4/filescanner.sock
listen = /var/run/avast4/local.sock
# connection timeout in seconds
# idle connection will be automatically closed after elapsing the
# period (default is infinite)
timeout = 300
# environment of forked daemons :
# user name used at runtime
# the value sets the user and user's permissions of the local
# (Unix) socket file if enabled (see 'listen' option)
# the value can be a username or a numeric UID
user = root
# group name used at runtime
# the value sets the group and group's permissions of the local
# (Unix) socket file if enabled (see 'listen' option)
# the value can be a groupname or a numeric GID
;group = root
# setting this option enables to chroot forked daemon into
# specific directory - jail (disabled by default).
# NOTE: the directory tree must also include daemons's 400.vps file
;rootdir = /var
# general settings of the virus scan engine:
# avast! antivirus engine paths :
# NOTE: these options modify values in /etc/avastengine.conf file
# data directory of the avast! engine, the directory must include
# the virus signature file (400.vps)
# the directory must be located in 'rootdir' tree (if specified)
datadir = /var/lib/avast4
# avast! engine temporary directory, the directory is used to
# temporary unpack archived files (must be writeable)
# the directory must be located in 'rootdir' tree (if specified)
tempdir = /var/lib/avast/tmp
# full path to avast! engine license file
# the file must be located in 'rootdir' tree (if specified)
licensefile = /var/lib/avast4/License.dat
# scanner working area:
# working directory of the daemon, files outside of the directory
# will be excluded from scanning
# the directory must be located in 'rootdir' tree (if specified)
;workdir = /var
# enable scanning in subdirectories (default is false)
subdirs = true
# directory in the working tree which will be excluded from
# scanning
# you can set multiple directories as a colon separated list or
# each directory in a separate line (maximum is 30 paths)
# directories must be located in 'rootdir' tree (if specified)
# empty list by default
;excludedir = /var/excludedir1:/var/exludedir2
# scanner flags :
# test all files (default is 1)
# tells avast whether you want to test all files (1) or just some
# of them, it is recommended always set this flag to 1 for
# Linux/Unix environment
testall = 1
# scan entire files (default is 0)
# if 0, only parts of the files will be scanned, setting 1 can be
# very slow for huge files
testfull = 0
# ignore virus sets (default is 0)
# setting to 1 means that all types of viruses will be scanned in
# all objects (and not selectively, which is the case if this
# option is set to 0).
ignoretype = 0
# scanner packers :
# scan inside compressed files, avast! antivirus kernel enables
# scanning of these compression formats:
# Z = ZIP(default), G = GZIP(default), B = BZIP2(default),
# T = TAR(default), I = MIME, J = ARJ, R = RAR, X = Exec(default),
# O = ZOO, Q = ARC, H = LHA, F = TNEF, V = CPIO, K = CHM, P = RPM,
# Y = ISO, D = DBX, 6 = SIS, U = OLE(default), 1 = INSTALL(default),
# W = WINEXEC(default), A = All, N = None
;archivetype = ZGBTXU1W
archivetype = A
# don't list all archived files and summary all to one scan result
# this reports, whether an archive is infected, contains encrypted
# files or files that cannot be scanned or all files are clean
# disabled by default
summaryarchive = 0
# maximum recurse level in packed files
# 0 means default value of 32 (maximum is 128)
maxpackerdepth = 0
# determine packer bomb :
# If you do not declare variables, default values will be used.
# Using 0 values, decompression bomb checking will be disabled.
#
# The maximum size of the file extracted from an archive. If the
# file in the archive exceeds the value it will be skipped.
# Note: a message with such a file will be treated as a mail bomb.
# Default is 500MB.
maxfilesizetoextract = 500000
# Maximum compression ratio, i.e., the ratio of the unpacked file
# length to the length of the packed file in the archive. If the
# ratio exceeds the value, the file will not be extracted and
# therefore will not be checked.
# Default is 1:50.
maxcompressionratio = 50
# Maximum file size inside archive, beginning from which the
# maximum compression ratio will be checked (if enabled by
# maxcompressionratio parameter).
# Default is 10MB.
compressioncheckthreshold = 10000
# Maximum "total" compression ratio of the real archive
# Default is 1:100
maxtotalcompressionratio = 100
# Number of files inside of an archive (from all packed depths),
# beginning from which the maximum total compression ratio will
# be checked.
# Default is 1000.
totalcompressioncheckthreshold = 1000
# log scan results level :
# Default is logging infected files and error scan results.
loginfected = 1
logerrors = 1
logclean = 1
-
Hallo,
please, check whether there are the SHM blocks when avastd runs (ipcs -a). The kern.ipc.XXX stuff must somehow reflect the capabilities (phys. mem. amount) of your machine, thus thus you must put in reasonable values.
With improper values, the SHM layer might get into unusable state (and that's also why we don't set this in installer, even when we know that the limits aren't suficient - it's peril). There's a small utility "shmprobe", in the install-tree, useful for quick checking.
btw. avastcmd is faster, when the SHM blocks are already there. Try to spawn one (avastcmd /usr), ctrl-z it, and then spawn another one. The initial delay won't happen.
regards,
pc
-
Hallo,
please, check whether there are the SHM blocks when avastd runs (ipcs -a). The kern.ipc.XXX stuff must somehow reflect the capabilities (phys. mem. amount) of your machine, thus thus you must put in reasonable values.
With improper values, the SHM layer might get into unusable state (and that's also why we don't set this in installer, even when we know that the limits aren't suficient - it's peril). There's a small utility "shmprobe", in the install-tree, useful for quick checking.
btw. avastcmd is faster, when the SHM blocks are already there. Try to spawn one (avastcmd /usr), ctrl-z it, and then spawn another one. The initial delay won't happen.
regards,
pc
... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.
regards,
pc
-
... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.
regards,
pc
It does not work ..:(.... However, it seems that 'avastcmd' runs pretty well for the past few days. We will just keep it running this way for now..:)... Thanks a lot.
-
... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.
regards,
pc
It does not work ..:(.... However, it seems that 'avastcmd' runs pretty well for the past few days. We will just keep it running this way for now..:)... Thanks a lot.
i'll have to analyse the avastd's lock-up anyway, on Monday.
regards,
pc
-
... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.
regards,
pc
It does not work ..:(.... However, it seems that 'avastcmd' runs pretty well for the past few days. We will just keep it running this way for now..:)... Thanks a lot.
i'll have to analyse the avastd's lock-up anyway, on Monday.
regards,
pc
Hmmm.... some, let's say, "progress" or "conclusion".
After _many_ hours with testing, the conclusion is, that for some obscure reason, after setting the SIGINT sigaction handler, the underlying threading layer in libthr gets somehow harmed, and later, any pthread_condvar operation will be in the first step fully nonsensually refused with -EPERM (although the lock is brand new, just initialised, and for sure belongs to the thread who's requesting the op). In turn, re-acquiring the variable will succeed, but the lock acqired this way will be never dropped as it ought to be, inside the waiting function, with a deadlock as consequence.
Even more interesting - in a bare testing app, the sigint hooking _doesn't_ trigger this suspicious behavior. Strange enough. Similar nightmare was solved some months ago on Solaris, where their threading library deliberately used the same SIGALRM timing source, as the system's sleep()- causing spurious unvanted signaling to occur.
So, I decided, at least for now, to emulate these lame pthread_conditionals with busy waiting with reasonable poll-delay.
Let's test the packages: http://public.avast.com/~cimbal/BSD6/
regards,
pc
-
Btw. the ill-famed FreeBSD threading-library ping-pong really rulez - unbelievable.
s threa/76690 threads fork hang in child for -lc_r
1 problem total.
Serious problems
S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL
s bin/32295 threads pthread dont dequeue signals
s threa/34536 threads accept() blocks other threads
s threa/39922 threads [threads] [patch] Threaded applications executed with
s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under
s threa/49087 threads Signals lost in programs linked with libc_r
o threa/70975 threads unexpected and unreliable behaviour when using SYSV se
o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
o threa/75273 threads FBSD 5.3 libpthread (KSE) bug
o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag
s threa/76694 threads fork cause hang in dup()/close() function in child (-l
o threa/79683 threads svctcp_create() fails if multiple threads call at the
o threa/80435 threads panic on high loads
o threa/83914 threads [libc] popen() doesn't work in static threaded program
s threa/84483 threads problems with devel/nspr and -lc_r on 4.x
s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc
s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r
o threa/101323 threads fork(2) in threaded programs broken.
o threa/103975 threads Implicit loading/unloading of libpthread.so may crash
o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat
o threa/118715 threads kse problem
o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7
o threa/121343 threads pthread_cond_wait hanging in libthr
24 problems total.
Non-critical problems
S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/30464 threads pthread mutex attributes -- pshared
s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
s threa/40671 threads pthread_cancel doesn't remove thread from condition qu
s threa/69020 threads pthreads library leaks _gc_mutex
o threa/79887 threads [patch] freopen() isn't thread-safe
o threa/80992 threads abort() sometimes not caught by gdb depending on threa
o threa/110306 threads apache 2.0 segmentation violation when calling gethost
o threa/115211 threads pthread_atfork misbehaves in initial thread
o threa/116181 threads /dev/io-related io access permissions are not propagat
o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP
10 problems total.
-
Hello again,
Had time now to look around Avast again... Now on a FreeBSD 6.2 box. The latest packages You linked are installed, avastcmd runs fine, but avastd does not start... it simply exits no matter what options are given to it. shm sysctls set to higher values than default. Any idea?
Update: my demo license expired... well, this was only written in the /var/log/avast4/avastd.log, tho there was a /var/lib/avast4/log folder and I was looking there, or at least expecting a message on command line like "License expired". I'll test with another demo license for some days, if we are running fine, we'll purchase :)
Daniel
-
Btw. the ill-famed FreeBSD threading-library ping-pong really rulez - unbelievable.
s threa/76690 threads fork hang in child for -lc_r
1 problem total.
Serious problems
S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL
s bin/32295 threads pthread dont dequeue signals
s threa/34536 threads accept() blocks other threads
s threa/39922 threads [threads] [patch] Threaded applications executed with
s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under
s threa/49087 threads Signals lost in programs linked with libc_r
o threa/70975 threads unexpected and unreliable behaviour when using SYSV se
o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
o threa/75273 threads FBSD 5.3 libpthread (KSE) bug
o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag
s threa/76694 threads fork cause hang in dup()/close() function in child (-l
o threa/79683 threads svctcp_create() fails if multiple threads call at the
o threa/80435 threads panic on high loads
o threa/83914 threads [libc] popen() doesn't work in static threaded program
s threa/84483 threads problems with devel/nspr and -lc_r on 4.x
s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc
s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r
o threa/101323 threads fork(2) in threaded programs broken.
o threa/103975 threads Implicit loading/unloading of libpthread.so may crash
o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat
o threa/118715 threads kse problem
o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7
o threa/121343 threads pthread_cond_wait hanging in libthr
24 problems total.
Non-critical problems
S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/30464 threads pthread mutex attributes -- pshared
s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
s threa/40671 threads pthread_cancel doesn't remove thread from condition qu
s threa/69020 threads pthreads library leaks _gc_mutex
o threa/79887 threads [patch] freopen() isn't thread-safe
o threa/80992 threads abort() sometimes not caught by gdb depending on threa
o threa/110306 threads apache 2.0 segmentation violation when calling gethost
o threa/115211 threads pthread_atfork misbehaves in initial thread
o threa/116181 threads /dev/io-related io access permissions are not propagat
o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP
10 problems total.
Hi,
I just want to suggest that you post some more technical details to the FreeBSD mailing list. Perhaps somebody there will know a better way to get around these problem. We have purchased Avast for our company, and it has stopped lots of malicious emails (much better than ClamAV ..:)...). Thanks for your work.
-
> Hi,
> I just want to suggest that you post some more technical details to the FreeBSD mailing list. Perhaps somebody there will know
Hallo, it was taken from the developer forum (i was verifying whether someone else faced the same behavior). There are only 2 ways, what to do - waiting for newer, hopefully less crippled release, or using some independent workaround...
regards,
pc
-
Any updates on FreeBSD version? I'm trying to configure a separate server only for av mail scaning with FreeBSD 7.
-
Any updates on FreeBSD version? I'm trying to configure a separate server only for av mail scaning with FreeBSD 7.
Hallo,
no updates, those packages (see above) should work for you. Each of them is built with one particular BSD's flaw on mind (caused by the infamous never-endin annoying madness with FreeeBSD threading model).
regards,
pc