incoming emails marked with ***UNCHECKED*** after fresh install of ISPConfig3 on debian buster

Discussion in 'Installation/Configuration' started by hwtf@2021, Jan 19, 2021.

  1. hwtf@2021

    hwtf@2021 New Member

    Hi all,

    I´ve been runing ISPConfig for many years, but OS upgrade got absolutely nuts... so had to re-install.

    After install following the guide for Debian Buster, with 2 exceptions : had to use MariaDB 10.4 due incompability bug with kernel (xen vm...), and UFW a bit newer (0.36-7.1) due iptables kernel bug...Kernel due xen cannot be simply upgraded...
    Except that, all done like in the buster install guide.

    Since install, I have all incoming emails marked with ***UNCHECKED***.

    Looking on status of services, I came to this:
    root@server1:~# systemctl status clamav-daemon
    * clamav-daemon.service - Clam AntiVirus userspace daemon
    Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/clamav-daemon.service.d
    `-extend.conf
    Active: failed (Result: signal) since Mon 2021-01-18 14:19:30 CET; 19h ago
    Docs: man:clamd(8)
    man:clamd.conf(5)
    https://www.clamav.net/documents/
    Process: 21530 ExecStartPre=/bin/mkdir /run/clamav (code=exited, status=1/FAILURE)
    Process: 21532 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, status=0/SUCCESS)
    Process: 21534 ExecStart=/usr/sbin/clamd --foreground=true (code=killed, signal=KILL)
    Main PID: 21534 (code=killed, signal=KILL)


    Stopped clamav-freshclam, clamav-daemon, erased /run/clamav directory. After runinng clamav-daemon it starts, and runs as following for some seconds>
    root@server1:/run# /etc/init.d/clamav-daemon status
    * clamav-daemon.service - Clam AntiVirus userspace daemon
    Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/clamav-daemon.service.d
    `-extend.conf
    Active: active (running) since Tue 2021-01-19 10:16:00 CET; 15s ago
    Docs: man:clamd(8)
    man:clamd.conf(5)
    https://www.clamav.net/documents/
    Process: 12917 ExecStartPre=/bin/mkdir /run/clamav (code=exited, status=0/SUCCESS)
    Process: 12919 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, status=0/SUCCESS)
    Main PID: 12921 (clamd)
    CGroup: /system.slice/clamav-daemon.service
    `-12921 /usr/sbin/clamd --foreground=true

    but then, after some time, if fails again:
    root@server1:/run# /etc/init.d/clamav-daemon status
    * clamav-daemon.service - Clam AntiVirus userspace daemon
    Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/clamav-daemon.service.d
    `-extend.conf
    Active: failed (Result: signal) since Tue 2021-01-19 10:16:30 CET; 5s ago
    Docs: man:clamd(8)
    man:clamd.conf(5)
    https://www.clamav.net/documents/
    Process: 12917 ExecStartPre=/bin/mkdir /run/clamav (code=exited, status=0/SUCCESS)
    Process: 12919 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, status=0/SUCCESS)
    Process: 12921 ExecStart=/usr/sbin/clamd --foreground=true (code=killed, signal=KILL)
    Main PID: 12921 (code=killed, signal=KILL)

    root@server1:/run# /etc/init.d/clamav-freshclam status
    * clamav-freshclam.service - ClamAV virus database updater
    Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled)
    Active: inactive (dead) since Tue 2021-01-19 10:15:33 CET; 11min ago
    Docs: man:freshclam(1)
    man:freshclam.conf(5)
    https://www.clamav.net/documents
    Process: 12599 ExecStart=/usr/bin/freshclam -d --foreground=true (code=exited, status=0/SUCCESS)
    Main PID: 12599 (code=exited, status=0/SUCCESS)
    root@server1:/run#


    /var/log/clamav/freshclam.log
    Tue Jan 19 10:03:29 2021 -> ClamAV update process started at Tue Jan 19 10:03:29 2021
    Tue Jan 19 10:03:29 2021 -> daily.cld database is up to date (version: 26053, sigs: 4213966, f-level: 63, builder: raynman)
    Tue Jan 19 10:03:29 2021 -> main.cvd database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
    Tue Jan 19 10:03:29 2021 -> bytecode.cvd database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)
    Tue Jan 19 10:13:58 2021 -> --------------------------------------
    Tue Jan 19 10:13:58 2021 -> freshclam daemon 0.102.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
    Tue Jan 19 10:13:58 2021 -> ClamAV update process started at Tue Jan 19 10:13:58 2021
    Tue Jan 19 10:13:58 2021 -> daily.cld database is up to date (version: 26053, sigs: 4213966, f-level: 63, builder: raynman)
    Tue Jan 19 10:13:58 2021 -> main.cvd database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
    Tue Jan 19 10:13:58 2021 -> bytecode.cvd database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)
    Tue Jan 19 10:13:58 2021 -> --------------------------------------
    Tue Jan 19 10:15:33 2021 -> Update process terminated


    /var/log/clamav/clamav.log
    Tue Jan 19 10:00:43 2021 -> Log file size limited to 4294967295 bytes.
    Tue Jan 19 10:00:43 2021 -> Reading databases from /var/lib/clamav
    Tue Jan 19 10:00:43 2021 -> Not loading PUA signatures.
    Tue Jan 19 10:00:43 2021 -> Bytecode: Security mode set to "TrustSigned".
    Tue Jan 19 10:06:20 2021 -> +++ Started at Tue Jan 19 10:06:20 2021
    Tue Jan 19 10:06:20 2021 -> Received 0 file descriptor(s) from systemd.
    Tue Jan 19 10:06:20 2021 -> clamd daemon 0.102.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
    Tue Jan 19 10:06:20 2021 -> Running as user clamav (UID 111, GID 119)
    Tue Jan 19 10:06:20 2021 -> Log file size limited to 4294967295 bytes.
    Tue Jan 19 10:06:20 2021 -> Reading databases from /var/lib/clamav
    Tue Jan 19 10:06:20 2021 -> Not loading PUA signatures.
    Tue Jan 19 10:06:20 2021 -> Bytecode: Security mode set to "TrustSigned".
    +++ Started at Tue Jan 19 10:09:47 2021
    Received 0 file descriptor(s) from systemd.
    clamd daemon 0.102.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
    Running as user clamav (UID 111, GID 119)
    Log file size limited to 4294967295 bytes.
    Reading databases from /var/lib/clamav
    Not loading PUA signatures.
    Bytecode: Security mode set to "TrustSigned".
    +++ Started at Tue Jan 19 10:13:22 2021
    Received 0 file descriptor(s) from systemd.
    clamd daemon 0.102.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
    Running as user clamav (UID 111, GID 119)
    Log file size limited to 4294967295 bytes.
    Reading databases from /var/lib/clamav
    Not loading PUA signatures.
    Bytecode: Security mode set to "TrustSigned".
    +++ Started at Tue Jan 19 10:13:48 2021
    Received 0 file descriptor(s) from systemd.
    clamd daemon 0.102.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
    Running as user clamav (UID 111, GID 119)
    Log file size limited to 4294967295 bytes.
    Reading databases from /var/lib/clamav
    Not loading PUA signatures.
    Bytecode: Security mode set to "TrustSigned".
    +++ Started at Tue Jan 19 10:16:00 2021
    Received 0 file descriptor(s) from systemd.
    clamd daemon 0.102.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
    Running as user clamav (UID 111, GID 119)
    Log file size limited to 4294967295 bytes.
    Reading databases from /var/lib/clamav
    Not loading PUA signatures.
    Bytecode: Security mode set to "TrustSigned".

    Would be grateful about hints where to search to solve the issue(s).
     
  2. hwtf@2021

    hwtf@2021 New Member

    actually, forgot to mention that mysql beside of the version is listening only on localhost. and I use different ISPconfig port instead of 8080.
     

    Attached Files:

  3. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    You might check other log files, too; a common reason is being out of memory.
     
    hwtf@2021 likes this.
  4. hwtf@2021

    hwtf@2021 New Member

    Hi Jesse,
    thank you for response. Anything actual log file on your mind? right now, the box has 1.5GB RAM, free like 600mb.

    I have run clamconf to export all the settings, just in case somebody finds there something wrong.

    I found one difference between old and new setup, but that been jessie and now buster, so might explain it:
    on old jessie, in /etc/systemd/system/clamav-daemon.socket.d/extend.conf i had:
    [Socket]
    ListenStream=
    SocketUser=clamav
    ListenStream=/var/run/clamav/clamd.ctl
    SocketGroup=clamav
    SocketMode=666

    in buster, same file looks like:
    [Service]
    ExecStartPre=-/bin/mkdir /run/clamav
    ExecStartPre=/bin/chown clamav /run/clamav
     

    Attached Files:

  5. hwtf@2021

    hwtf@2021 New Member

    anyhow, thanks for hint with the memory, checked it during start, and it drops down to 10mb free memory (looking into top), fails, then jumps to 600-700free ...
    However, noticed that my provider rebuilt the box without any swap, so will contact him to add some, and let´s see.
     
  6. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    i don't know what you've got on that server, if it's running as the webserver, as well as the database server and mail server, then 1.5Gb of ram seems low to me.
    obviously depends a lot on how many websites you're going to run on there, how busy they get, how big the databases are, and how much mail you receive/send, but i would consider 2Gb the minimum amount of ram for the server, and ideally, i would prefer 4Gb as the starting point. clamav can use a lot of your total ram on it's own..

    personally, i think swap on a vps is a bit of a waste, writing memory to a file within a server image which is itself a file, just seems too slow to me to be worthwhile, once a vps hits swap it always seems to be game over.. others on here disagree.... but i think everyone can agree that the best option is to have enough physical ram that any swap file, if it exists, never actually gets used.
     
  7. hwtf@2021

    hwtf@2021 New Member

    Jesse been right with memory. After solving swap , the process is running thru and working all fine. Thanks for that hint!
    No idea how I overlooked that completely...:oops:
     

Share This Page