Jump to content

Krzysztof L.

Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by Krzysztof L.

  1. I am also suffering from lack of support for ubuntu 22.04 LTS. In my case, efs installs correctly (efs-9.0.174.0.x86_64.deb), but I get segfault during efs startup.

    logs:
     

    May 31 12:48:11 efs. **** kernel: startd [3814]: segfault at 10 ip 00007f8c907519d2 sp 00007fff332d9210 error 4 in libcommon.so [7f8c904eb000 + 350000]
    May 31 12:48:11 efs. **** kernel: Code: 48 8b 04 25 28 00 00 00 48 89 04 24 bb 02 00 00 00 eb 17 0f 1f 44 00 00 49 c7 04 de 00 00 00 00 48 83 c3 01 48 83 fb 38 74 19 <49> 8b 3c de 48 85 ff 74 e5 49 c7 04 de 00 00 00 00 48 8b 07 ff>
    May 31 12:48:11 efs. **** systemd [1]: efs.service: Main process exited, code = dumped, status = 11 / SEGV
    May 31 12:48:13 efs. **** systemd [1]: efs.service: Failed with result 'core-dump'.

     

  2. Hi, I also have this problem, it has occurred since 22/01/2021. Eset mail security crashes once a day (more or less every 24h).

    Nothing in logs... also no bt.esets_daemon.* files in /tmp/ directory.

    Centos 7 3.10.0-1160.11.1.el7.x86_64

    # /opt/eset/esets/sbin/esets_update  --version
    /opt/eset/esets/sbin/esets_update (esets) 4.5.15

     

    # esets_update --verbose
    Update is not necessary - the installed virus signature database is current.
    ESETS Update utility
    +-+--------------------+------------------------+------------------------+
    | | Module             | Available version      | Installed version      |
    +-+--------------------+------------------------+------------------------+
    | | loader             |        1076 (20200313) |        1076 (20200313) |
    | | perseus            |      1568.2 (20201214) |      1568.2 (20201214) |
    | | engine             |       22709 (20210126) |       22709 (20210126) |
    | | archiver           |        1312 (20201223) |        1312 (20201223) |
    | | heuristic          |        1205 (20201209) |        1205 (20201209) |
    | | cleaner            |        1214 (20200921) |        1214 (20200921) |
    | | horus              |        7873 (20210115) |        7873 (20210115) |
    | | dblite             |        1112 (20200928) |        1112 (20200928) |
    +-+--------------------+------------------------+------------------------+

    A workaround is to restart eset daemon:

    systemctl stop esets.service
    /usr/bin/killall -u esets -9
    systemctl start esets.service

     

  3. It looks like the problem is back again. I think Is is happen after todays update at 2PM.

     

    /opt/eset/esets/sbin/esets_daemon --version
    /opt/eset/esets/sbin/esets_daemon (esets) 4.5.15

    There is a lot of /tmp/bt.esets_daemon.* files

    cat bt.esets_daemon.EkR1IE
    signal = 11
    bad addr = 0xcfc00004

     

    /opt/eset/esets/sbin/esets_update  --verbose
    Naruszenie ochrony pamięci 
    (translate: Memory protection violation)

     

    Esets hung in starting loop

    systemctl start esets.service
    Job for esets.service failed because a fatal signal was delivered to the control process. See "systemctl status esets.service" and "journalctl -xe" for details.
    
    "journalctl -xe"
    Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: ESET Security Daemon, Version 4.5.15
    Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: Start Antivirus scanner initialization
    Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: Searching for section dac in configuration
    Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: Using configuration for section dac
    Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: ESET Security Daemon, Version 4.5.15
    Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: Start Antivirus scanner initialization
    Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: Searching for section dac in configuration
    Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: Using configuration for section dac
    Nov 19 15:26:23 eset-mail esets_daemon[3078]: debug[0c060000]: ESET Security Daemon, Version 4.5.15
    Nov 19 15:26:23 eset-mail esets_daemon[3078]: debug[0c060000]: Start Antivirus scanner initialization
    (...)

    Server : centos 7.9.2009 (64), rebooted.

     

  4. I also confirm this problem.  I have now changed the file name em001_32.dat and make update. Now we will wait and watch.

     

    # /opt/eset/esets/sbin/esets_update  --verbose
    Virus signature database has been updated successfully.
    ESETS Update utility
    +-+--------------------+------------------------+------------------------+
    | | Module             | Available version      | Installed version      |
    +-+--------------------+------------------------+------------------------+
    |*| loader             |      1074.1 (20190925) |                        |
    |*| perseus            |        1555 (20190911) |                        |
    |*| engine             |       20238 (20191025) |                        |
    |*| archiver           |        1293 (20191004) |                        |
    |*| heuristic          |        1194 (20190918) |                        |
    |*| cleaner            |        1200 (20190916) |                        |
    | |                    |                        | ▒▒x▒Ƿ`▒▒x▒v▒w▒v▒0▒V▒ |
    | |                    |                        |                        |
    |*| horus              |        7833 (20191016) |                        |
    |*| dblite             |        1110 (20190827) |                        |
    +-+--------------------+------------------------+------------------------+

     

     

  5. Yes i confirm this bug. My system is:

    CentOS Linux release 7.5.1804 (Core)
    (esets) 4.5.11

    But is also happen on esets 4.5.9 (i just updated it to 4.5.11). First occurred of this bug is 25/10/2018 at 4pm. Now its happen about one/two times a day.

    To Eset support team - Please check what are you changed in last week. In my recognition only engine module was changed in this day.

    While esets daemon is freezed then i UNABLE to restart it by command:

    # systemctl restart esets.service

    i need to:

    # /usr/bin/killall -u esets -9

    and then start eset again.

    Some other hints...

    eset.log on freezed daemon (4.5.11)
     

    Oct 28 20:53:41 eset-mail esets_daemon[1850]: debug[07340000]: Sessions processing done
    Oct 28 20:53:41 eset-mail esets_daemon[1850]: debug[07340000]: Waiting for child processes...

    eset.log for version 4.5.9
     

    Oct 25 21:23:35 eset-mail esets_daemon[1081]: error[04390000]: Child process esets_daemon[1332] did not handle signal 6, restart in 0 seconds

    other errors in eset.logs (this happen when i try to restart eset after freeze)
     

    Oct 27 23:33:02 eset-mail esets_daemon[1443]: error[05a30000]: Cannot open file /var/log/esets/threatlog.dat: Connection timed out
    Oct 27 23:34:04 eset-mail esets_daemon[1522]: error[05f20000]: Cannot open file /var/log/esets/threatlog.dat: Connection timed out
    Oct 27 23:34:27 eset-mail esets_daemon[1578]: error[062a0000]: Cannot open file /var/log/esets/threatlog.dat: Connection timed out

    sometimes also in /tmp direcotry Eset create files just like:

    -rw------- 1 esets esets  29 10-27 22:09 bt.esets_daemon.KmBKPG
    
    # cat bt.esets_daemon.KmBKPG
    
    signal = 6
    bad addr = 0x6e7f


    Now (10:53 2018-10-29), as FHolzer said, I launched the updates manually

    +-+--------------------+------------------------+------------------------+
    | | Module             | Available version      | Installed version      |
    +-+--------------------+------------------------+------------------------+
    | | loader             |        1072 (20180813) |        1072 (20180813) |
    | | perseus            |        1543 (20180927) |        1543 (20180927) |
    | | engine             |       18291 (20181029) |       18291 (20181029) |
    | | archiver           |        1278 (20180924) |        1278 (20180924) |
    | | heuristic          |        1190 (20180924) |        1190 (20180924) |
    | | cleaner            |        1170 (20181025) |        1170 (20181025) |
    | | horus              |        7778 (20181017) |        7778 (20181017) |
    | | dblite             |        1103 (20180629) |        1103 (20180629) |
    +-+--------------------+------------------------+------------------------+
    

     

  6. Michal, my mails are scanned only 8 hours a day, then I disable the postfix-eset connection and go home. By these 8 hours a day works well (last 2 days). I think this is a topic for support, but this forum is more for ordinary users and not for real support. I think we need to contact eset support directly.

    Michal please write more about your configuration. Perhaps it will be helpful to someone.
    Our postfix is on another machine than eset mail security. Both machines are virtual (vsphere 6.5). Postfix communicates with eset through the 'content filter' configuration:

    main.cf
    content_filter = smtp: [xxx.xxx.xxx.xxx]: 5555

    Eset is on Centos 7.4, the following eset modules are running:

    esets_smtp
    esets_wwwi

    In the esets_smtp module I also activated:
    * Potentially unsafe apps
    * Potentially unwanted apps

    Configuration from logs (debug) :

    ESETS SMTP filter, Version 4.5.7
    num_proc                                 = 15
    num_thrd                                 = 2
    conns_max                                = 25
    syslog_facility                          = "daemon"
    syslog_class                             = "error:warning:summall:summ:partall:part:info:debug"
    listen_addr                              = "xxx.xxx.xxx.xxx"
    listen_port                              = 5555
    server_addr                              = "yyy.yyy.yyy.yyy"
    server_port                              = 2500
    add_header_xvirus                        = no
    add_header_received                      = no
    lo: 127.0.0.1
    eno16777984: xxx.xxx.xxx.xxx
    Server is listening on xxx.xxx.xxx.xxx:5555

     

    Any support guys here?

     

  7. We have the same problem as Michal wrote. Yesterday, esets_deamon (Eset mail security for linux) entered a strange state. Telnet to eset smtp module works good but all messages goes back to postfix with status:

    "delivery temporarily suspended: conversation with xxx[yyy] timed out while receiving the initial server greeting".

    There is nothing interesting in eset logs.

    As an workaround we also need to restart whole virtual machine (Linux Centos 7.4).

     

     

    update 11:00 2017-10-04

    its happened again, 3 hours after the reboot.  Maybe the reason is any of newests updates (horus,engine)?

    # ./esets_update --verbose
    Update is not necessary - the installed virus signature database is current.
    ESETS Update utility

    loader     1069 (20161122) |        1069 (20161122)
    perseus  1530 (20170920) |        1530 (20170920)
    engine     16184 (20171004) |       16184 (20171004)
    archiver   1269 (20170913) |        1269 (20170913)
    heuristic  1180 (20170914) |        1180 (20170914)
    cleaner    1142 (20170814) |        1142 (20170814)
    horus       6231 (20171003) |        6231 (20171003)
    dblite       1093 (20170725) |        1093 (20170725)

    We use version 4.5.7 of eset mail security. In the list of changes for version 4.5.7 we can read:

    "Fixed: Server with CentOS 7 and ESET File Security for Linux 4.5.6.0 freeze in some cases"

    As we can see, the problem with centos 7 is not new... Maybe it has not been completely fixed?

     

×
×
  • Create New...