cannot initialze avast! engine: invalid agrument

[ba123]

Any ideas?

read the entire thread  

[zilog]

Any ideas?

read the entire thread 

Again:

1) it's not a bug, don't look for newer version - rather the VPS size has grown and reached the 32MB limit in linux kernel. This limit is rather artificial, conservative, ande could be changed using /proc or sysctl to more reasonable value. just change the limit. otherwise, virus database cannot fit into SHM. no way.

2) details here: http://forum.avast.com/index.php?topic=57775.0

regards,
pc

[kingof1981]

Hi folks.

just keep the older version installed... http://www.avast.com/files/linux/avast4workstation_1.2.0-2_i386.deb
extracte the 400.vps file from the current version
paste that file in to your /.avast folder in your home folder.
and the database is up to date.

[chudtrooper]

Hello,

thanks for the reply. I am trying it.

I have no idea if I can manage it to install the new software on my systems in an acceptable period of time. Could you please make available the latest working vps file for the old version of the software resp. let me know where I could get it?

Hallo,
on my side it works OK:
zilog@sinclair:/mnt/storage/t/feb2010build$ ./stestik /etc/passwd
Status: 0 (Success)
VPS info: Structure 2147483659 Version 268642561 UncompressSize 55881907 Compiled 29.03.2010
here-init
STATUSzhandle: 0
I'm 0 running, variable at 0xbf863380, handle 0x85457f8.

/etc/passwd
FILE: /etc/passwd SIZE: 483 OFFSET: 0 SIZE: 483[ OK ]
Thread 0 has found 0 viruses.
Waiting on getchar(); all handles closed, reloading


----
on Mac, works OK, but indeed, avastcmd started to fail. With older 400.vps it works OK, with new one not. BUT, customised engine which doesn't use SHM memory sharing, works still OK (used on Mac machines) - so here would be the cause. Checking the cause right now...

pc

Well, here's the cure:

do as root:  sysctl -w kernel.shmmax=100000000

reason? older kernels have an artificial limitations which dictates the maximum size of one SHM block in bytes. And, one block of our database exceeded this limit. so just, relax them to more reasonable values. that's it.

sinclair:/mnt/storage/t/feb2010build# sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 33554432

---> 0x6de86d68 8880136    zilog     600        33178972   3

just issue those upon system startup in /etc/init.d/rcS or similar system-wide initscript on your distribution (see /etc/inittab, the si:: line).

Which lines of code do I issue in the rcS file?  Is it just sysctl -w kernel.shmmax=100000000?

or is the next lines?
sinclair:/mnt/storage/t/feb2010build# sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 33554432

Thanks

[zilog]

Hello,

thanks for the reply. I am trying it.

I have no idea if I can manage it to install the new software on my systems in an acceptable period of time. Could you please make available the latest working vps file for the old version of the software resp. let me know where I could get it?

Hallo,
on my side it works OK:
zilog@sinclair:/mnt/storage/t/feb2010build$ ./stestik /etc/passwd
Status: 0 (Success)
VPS info: Structure 2147483659 Version 268642561 UncompressSize 55881907 Compiled 29.03.2010
here-init
STATUSzhandle: 0
I'm 0 running, variable at 0xbf863380, handle 0x85457f8.

/etc/passwd
FILE: /etc/passwd SIZE: 483 OFFSET: 0 SIZE: 483[ OK ]
Thread 0 has found 0 viruses.
Waiting on getchar(); all handles closed, reloading


----
on Mac, works OK, but indeed, avastcmd started to fail. With older 400.vps it works OK, with new one not. BUT, customised engine which doesn't use SHM memory sharing, works still OK (used on Mac machines) - so here would be the cause. Checking the cause right now...

pc

Well, here's the cure:

do as root:  sysctl -w kernel.shmmax=100000000

reason? older kernels have an artificial limitations which dictates the maximum size of one SHM block in bytes. And, one block of our database exceeded this limit. so just, relax them to more reasonable values. that's it.

sinclair:/mnt/storage/t/feb2010build# sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 33554432

---> 0x6de86d68 8880136    zilog     600        33178972   3

just issue those upon system startup in /etc/init.d/rcS or similar system-wide initscript on your distribution (see /etc/inittab, the si:: line).

Which lines of code do I issue in the rcS file?  Is it just sysctl -w kernel.shmmax=100000000?

or is the next lines?
sinclair:/mnt/storage/t/feb2010build# sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 33554432

Thanks

Hallo,
grepping - just to get the limits (to check whether your system is affected by this limit-exhaustion).
Then, sysctl -w is a method how to set internal kernel variables without any dependence on the /proc filesystem (so, you can place it anywhere in your rcS script).

regards,
pc

[mica]

Firstly thanks to Zilog for providing the information on how to fix this issue.   

I can confirm that running sysctl -w kernel.shmmax=128000000 from a command prompt works in my installation of Fedora 12.

For all Fedora users experiencing this problem I can suggest that after looking into how the init process works in this distro it would appear that the most appropriate place to add sysctl -w kernel.shmmax=128000000 is in /etc/rc.d/rc.local.

See http://docs.fedoraproject.org/install-guide/f12/en-US/html/s1-boot-init-shutdown-run-boot.html for details.

HTH

Mica

[hbbliss]

A clarification. If you go to a terminal and execute  sudo sysctl -w kernel.shmmax=100000000  and then start up Avast, it will run normally. However, if you reboot, the fix will go away and you must then redo sudo sysctl -w kernel.shmmax=100000000. I admit to being command line impaired, by choice, not lack of understanding. I think the rest of the suggested fix will in effect run when ever you boot and thus Avast will always run properly. Please give a better explanation of this part of the suggested fix. Where should these lines go? Who or what is sinclair? Etc.

hbbliss

[zilog]

A clarification. If you go to a terminal and execute  sudo sysctl -w kernel.shmmax=100000000  and then start up Avast, it will run normally. However, if you reboot, the fix will go away and you must then redo sudo sysctl -w kernel.shmmax=100000000. I admit to being command line impaired, by choice, not lack of understanding. I think the rest of the suggested fix will in effect run when ever you boot and thus Avast will always run properly. Please give a better explanation of this part of the suggested fix. Where should these lines go? Who or what is sinclair? Etc.

hbbliss

The command sysctl -w kernel.shmmax=100000000 should go to the init-script, which is run right after boot. this is DISTRIBUTION DEPENDENT, but /etc/init.d/rcS is good bet for all SysV-like distros, Fedora has etc/rc.d/rc.local, and so on. There are 600 different distros, so this may vary a bit, but misplacing the line would never hurt - at most it won't raise the limit and avast will return the error as before.

sinclair is my local computer (and the most cute brand of 80's home computers ever).

regards,
pc

[butterfly320]

According to may information this is the rare issue occurred with Avast antivirus. If you want avoid this error, for that you first need to uninstall your Avast antivirus. Then restart your computer system, and then reinstall avast antivirus over it. I suggest you to try out this solution, and let me know if you are able to solve this issue or not.

[zilog]

According to may information this is the rare issue occurred with Avast antivirus. If you want avoid this error, for that you first need to uninstall your Avast antivirus. Then restart your computer system, and then reinstall avast antivirus over it. I suggest you to try out this solution, and let me know if you are able to solve this issue or not.

Nope. reinstalling avast has an sideeffect - VPS will return back to the version which is bundled with the installer - which is still under the limit (and that's why it works seemingly again). so it's no solution at all. raise the limit.

regards,
pc

[tuna762]

I use Avast on a Fedora12  32bit on laptop and 64bit on desktop and tested this to work on both machines. Not mine .. found this solution on an Ubuntu forum.

I made the edit in the /etc/sysctl.conf file by adding the following 2 lines at the end of the file:


#avast antivirus bug fix
kernel.shmmax = 67108864

Save the file and reboot the machine

[bradshawd]

Well, here's the cure:

do as root:  sysctl -w kernel.shmmax=100000000

reason? older kernels have an artificial limitations which dictates the maximum size of one SHM block in bytes. And, one block of our database exceeded this limit. so just, relax them to more reasonable values. that's it.

sinclair:/mnt/storage/t/feb2010build# sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 33554432

---> 0x6de86d68 8880136    zilog     600        33178972   3

just issue those upon system startup in /etc/init.d/rcS or similar system-wide initscript on your distribution (see /etc/inittab, the si:: line).

This worked fine...   Will I have to type this command each time I reboot...  Rare as rocking horse droppings

Derek

[jfg10]

According to may information this is the rare issue occurred with Avast antivirus. If you want avoid this error, for that you first need to uninstall your Avast antivirus. Then restart your computer system, and then reinstall avast antivirus over it. I suggest you to try out this solution, and let me know if you are able to solve this issue or not.

Nope. reinstalling avast has an sideeffect - VPS will return back to the version which is bundled with the installer - which is still under the limit (and that's why it works seemingly again). so it's no solution at all. raise the limit.

regards,
pc

This description does not reflect what happened to my fresh Ubuntu 10.04 (in a VirtualBox running in a Mac). I installed avast, and it worked well, initially. Unfortunately, I clicked a couple of times on the avast icon while it was updating the virus database, opreration which failed. Since then, avast does not run, and reports a very similar invalid-argument message. So I uninstalled (with sudo dpkg -r <avast-name>) and reinstalled (sudo dpkg -i <avast-name>.deb), with supposedly the low-size initial database. But avast insists in not running, and giving the same message. So I uninstalled.

I will try to manually increase the limit. But, again, there is something wrong, it seems, with the description, and maybe the origin of the problem that is have just described is different from the share limit.

Thanks. Best regards,

José

[zilog]

According to may information this is the rare issue occurred with Avast antivirus. If you want avoid this error, for that you first need to uninstall your Avast antivirus. Then restart your computer system, and then reinstall avast antivirus over it. I suggest you to try out this solution, and let me know if you are able to solve this issue or not.

Nope. reinstalling avast has an sideeffect - VPS will return back to the version which is bundled with the installer - which is still under the limit (and that's why it works seemingly again). so it's no solution at all. raise the limit.

regards,
pc

This description does not reflect what happened to my fresh Ubuntu 10.04 (in a VirtualBox running in a Mac). I installed avast, and it worked well, initially. Unfortunately, I clicked a couple of times on the avast icon while it was updating the virus database, opreration which failed. Since then, avast does not run, and reports a very similar invalid-argument message. So I uninstalled (with sudo dpkg -r <avast-name>) and reinstalled (sudo dpkg -i <avast-name>.deb), with supposedly the low-size initial database. But avast insists in not running, and giving the same message. So I uninstalled.

I will try to manually increase the limit. But, again, there is something wrong, it seems, with the description, and maybe the origin of the problem that is have just described is different from the share limit.

Thanks. Best regards,

José

Hallo,
just delete the .avast directory in your home directory (corrupted 400.vps is probably there and blocks the loading of the app).

regards,
pc

[gonarin]

I did:

do as root:  sysctl -w kernel.shmmax=100000000

It worked perfect!

Thanks to Zilog.