Steelskin

Any news on a fix for us Linux users who use Chrome, Chromium etc 😕 I see there is no mention on the Eset website. Is it too much to ask of Eset that they actually 'officially' acknowledge that there is a problem and they have a plan of action. I really do detest companies that don't keep their customers in the loop about progress (if any).

Life would be so much better if Gandalf would wave his wand (actually, I don't think Gandalf needed a wand, different story), .... Would wave his wand at Eset and fix NOD32. All would be right in the world. 😊

Rami, Rami, Rami, You must have a magical laptop sprinkled with Pixie dust. If only I had a source of Pixie dust right now I would feel so much better.

Totally agree, I will be requesting a pro-rata refund based on how long it's taking Eset to resolve this. Currently my feeling is that Eset will not be receiving a renewal. This isn't open source software. We pay you good money for a product and you're not delivering a product that does what it's supposed to do. In fact open source is vastly better because at least users generally get feedback from the developers. Is there any 'official' comment from Eset about this problem and I'm not talking about any moderators comments in this forum.

Sometime in early December 2019. if I remember correctly, I made contact by using the interface in NOD32 for reporting problems. I've no idea where that's reported to, does it even work ? I assumed it was to HQ in Slovakia. I've searched my emails back to 1st December 2019 and have nothing from Eset about a ticket number, just a lot of emails from people reporting the problem on this forum.

Despite contacting Eset officially they have so far not responded. I'm not impressed to say the least. On the plus side, I've noticed my laptop feels faster in terms of how fast programs start having deinstalled NOD32. I don't know whether anybody else has experienced this. It's a fairly subtle improvement in speed but a improvement non the less. But then I guess that's to be expected when Eset is not scanning every file that's opened.

And maybe but only maybe that might be the reason. I'm using Nvidia GTX570M.

OK Rami, please give us a full description of your hardware, what desktop environment your using graphics card, drivers, whether you have hardware acceleration enabled.

It's not necessarily all versions of 79 that have a problem. Early versions of 79 may be fine. What I would like to see is an official response from Eset acknowleging the problem and a resolution, rather than users having to desperately try to figure it out for themselves.

Whoever said it's not an issue with Chromium is wrong. It is an identical issue with Chrome & Chromium from the tests I've done. Just depends on what versions you are using.

Actuall pkill did not work you have to kill -9 pid on each eset daemon

If you run Chrome from the command line while the Eset daemon is running, Chrome produces the following sandbox error. [5012:1:0109/230249.177870:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [5012:1:0109/230249.178539:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. If you kill the Eset daemon 'sudo pkill esets' then you don't get the above error.

Or will we all be requesting refunds and the associated bad press that will produce ? Really ? A bug fix in Q1/2020 and no bug fix planned for the ESET Linux Desktop Home edition ? Seriously ? 😠

If there is no plan for updating ESET NOD32 for Linux Desktop then my plan will be to request ESET to refund the balance of my three year subscription on multiple licences.

It's now the 6th Jan and Chrome is still crashing when the Eset_daemon is running. Does anybody know if anybody is working on this issue ?

As you mentioned above, you were running version 78.xxx of chrome. That's why you don't see a problem. You need to be running the following versions of chrome to see this crash with eset running .. 79.0.3945.88-1 (or earlier versions of 79.xxx) 80.0.3987.16-1 81.0.4000.3-1

Here is the output of chrome when Esset is running, each crash causes a flash from the browser window. As mentioned, if you kill all esset processes chrome does not produce any of these errors. Perhaps eset is restricting access to some of the mentioned files ? ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc child_process_sandbox_support_impl_linux.cc google-chrome ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:48:49-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 3d06fa8f5af5eccd 0K 516K=0s ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:49:23-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 5f55aaeec16904a0 0K 701K=0s [3430:1:1229/164931.173442:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [3430:1:1229/164931.174160:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:49:34-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... [3430:7:1229/164934.169052:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer. 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 5ed3418cc240f454 0K 530K=0s ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:49:46-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 422b1aaff8efaf04 0K 608K=0s 2019-12-29 16:49:47 (608 KB/s) - ‘/dev/fd/4’ saved [16] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:50:03-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ 0K Crash dump id: cb0f23b71c235577 752K=0s 2019-12-29 16:50:04 (752 KB/s) - ‘/dev/fd/4’ saved [16] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:50:30-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. [3548:3548:1229/165030.059220:ERROR:gpu_channel_manager.cc(450)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: f435d6b86734c2ff 0K 525K=0s 2019-12-29 16:50:30 (525 KB/s) - ‘/dev/fd/4’ saved [16] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:50:42-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. [3600:3600:1229/165042.882151:ERROR:gpu_channel_manager.cc(450)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: deb7fb7dd42968c9 0K 390K=0s ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure --2019-12-29 16:50:57-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. [3618:3618:1229/165057.522014:ERROR:gpu_channel_manager.cc(450)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: f0c2365749e2da02 0K ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [3164:3181:1229/165107.283404:FATAL:gpu_data_manager_impl_private.cc(990)] The display compositor is frequently crashing. Goodbye. --2019-12-29 16:51:07-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... --2019-12-29 16:51:07-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 831813565f56f112 0K 1.06M=0s 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 979b0a24e5d28e5c 0K 521K=0s 2019-12-29 16:51:08 (521 KB/s) - ‘/dev/fd/4’ saved [16] --2019-12-29 16:51:08-- https://clients2.google.com/cr/report Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘/dev/fd/4’ Crash dump id: 135d2926c153fe7e 0K 506K=0s 2019-12-29 16:51:09 (506 KB/s) - ‘/dev/fd/4’ saved [16] Illegal instruction (After this Illegal instruction message the entire chrome browser crashes).

Since early December 2019, Chrome and Chromium on Linux crash after a few minutes of use. This problem has been reported in various other forums and it seems that a number of users are experiencing this problem. There appears to be a problem in either Eset or Chrome/Chromium. I'm running eset anti-virus software and have found that if I kill all eset processes then Chrome stops crashing. In other threads I've seen mention of simply disabling 'real time file protection' but that did not work for me. I've no idea if the problem is in Eset or Chrome (or Chromium, which also has the same problem) and I've found the problem in versions of chrome since 79.0.3945.88-1 and the previous version plus later versions 80.0.3987.16-1 and 81.0.4000.3-1. Interestingly one of the symptoms is that you see the webpage flash several times as you move about the webpage and after a few minutes Chrome or Chromium crashes. Looking at the console output each flash corresponds with a crash being reported then sometimes prior to the crash an invalid opcode. As to whether it's a bug in eset or chrome I've no idea at present but killing all running eset processes appears to have stopped Chrome crashing. This is happening to two different systems, one runs Kubuntu Linux 18.04LTS and the other is KDE Neon (Based on Ubuntu 18.04LTS). The problem started after an update on or around 4th December 2019.