Ubuntu

有沒有辦法知道為什麼重新啟動服務以及是誰做的？

  • September 3, 2015
  • Ubuntu 14.04
  • 克拉瑪夫 0.98.7

該問題clamav-daemon幾乎每天都會重新啟動：

Sep  1 06:30:00 x-master clamd[6778]: Pid file removed.
clamd[6778]: --- Stopped at Tue Sep  1 06:30:00 2015
clamd[5979]: clamd daemon 0.98.7 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
clamd[5979]: Running as user root (UID 0, GID 0)
clamd[5979]: Log file size limited to 4294967295 bytes.
clamd[5979]: Reading databases from /var/lib/clamav
clamd[5979]: Not loading PUA signatures.
clamd[5979]: Bytecode: Security mode set to "TrustSigned".

如果clamdscan正在執行，則會導致問題：

/etc/cron.daily/clamav_scan:
ERROR: Could not connect to clamd on x.x.x.x: Connection refused

請注意，我在開頭說“幾乎”：

/var/log/syslog:Sep  1 06:30:00 x-master clamd[6778]: Pid file removed.
/var/log/syslog.1:Aug 31 06:27:54 x-master clamd[20128]: Pid file removed.
/var/log/syslog.4.gz:Aug 28 06:28:34 x-master clamd[4475]: Pid file removed.
/var/log/syslog.5.gz:Aug 27 06:27:47 x-master clamd[21466]: Pid file removed.

如你看到的：

  • 它沒有發生在 8 月 29 日和 30 日
  • 它經常在 06:27 左右重新啟動，這cron.daily是執行時間
27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily

的內容/etc/cron.daily/clamav_scan：

find / $exclude_string ! \( -path "/tmp/clamav-*.tmp" -prune \) ! \( -path "/var/lib/elasticsearch" -prune \) ! \( -path "/var/lib/mongodb" -prune \) ! \( -path "/var/lib/graylog-server" -prune \) -mtime -1 -type f -print0 | xargs -0 clamdscan --quiet -l "$status_file" || retval=$?

clamav-daemon 有一個 logrotate 文件：

/var/log/clamav/clamav.log {
    rotate 12
    weekly
    compress
    delaycompress
    create 640  clamav adm
    postrotate
    /etc/init.d/clamav-daemon reload-log > /dev/null
    endscript
    }

但它只是重新載入日誌：

Sep  1 02:30:24 uba-master clamd[6778]: SIGHUP caught: re-opening log file.

我知道我們可以auditd用來監控二進製文件，這是一個範例日誌：

ausearch -f /usr/sbin/clamd                                                                                                        [2/178]
----
time->Tue Sep  1 07:56:44 2015
type=PATH msg=audit(1441094204.559:15): item=1 name=(null) inode=2756458 dev=fc:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1441094204.559:15): item=0 name="/usr/sbin/clamd" inode=3428628 dev=fc:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1441094204.559:15):  cwd="/"
type=EXECVE msg=audit(1441094204.559:15): argc=1 a0="/usr/sbin/clamd"
type=SYSCALL msg=audit(1441094204.559:15): arch=c000003e syscall=59 success=yes exit=0 a0=7ffd277e03dc a1=7ffd277dfa78 a2=7ffd277dfa88 a3=7ffd277df570 items=2
ppid=5708 pid=5946 auid=4294967295 uid=109 gid=114 euid=109 suid=109 fsuid=109 egid=114 sgid=114 fsgid=114 tty=pts1 ses=4294967295 comm="clamd" exe="/usr/sbin/clamd" key=(null)

109 是…clamav使用者的 UID：

getent passwd clamav clamav:x:109:114::/var/lib/clamav:/bin/false

在這種情況下是否有另一種解決方法？

回复@HBrijn：

更新 AV 定義後可能是新鮮蛤蜊？

我想過這個問題。這是日誌：

Sep  1 05:31:04 x-master freshclam[16197]: Received signal: wake up
Sep  1 05:31:04 x-master freshclam[16197]: ClamAV update process started at Tue Sep  1 05:31:04 2015
Sep  1 05:31:04 x-master freshclam[16197]: main.cvd is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Sep  1 05:31:05 x-master freshclam[16197]: Downloading daily-20865.cdiff [100%]
Sep  1 05:31:09 x-master freshclam[16197]: daily.cld updated (version: 20865, sigs: 1555338, f-level: 63, builder: neo)
Sep  1 05:31:10 x-master freshclam[16197]: bytecode.cvd is up to date (version: 268, sigs: 47, f-level: 63, builder: anvilleg)
Sep  1 05:31:13 x-master freshclam[16197]: Database updated (3979610 signatures) from db.local.clamav.net (IP: 168.143.19.95)
Sep  1 05:31:13 x-master freshclam[16197]: Clamd successfully notified about the update.
Sep  1 05:31:13 x-master freshclam[16197]: --------------------------------------
Sep  1 04:34:10 x-master clamd[6778]: SelfCheck: Database status OK.
Sep  1 05:31:13 x-master clamd[6778]: Reading databases from /var/lib/clamav
Sep  1 05:31:22 x-master clamd[6778]: Database correctly reloaded (3974071 signatures)

我不確定這一點，但看起來freshclam 有一個“內部機制”來通知clamd 更新。之後它可以重新載入數據庫，無需重新啟動程序。你確定嗎？

此外，從時間戳中，我看到在freshclam 更新數據庫一小時後clamav-daemon 重新啟動。正常嗎？

更新 9 月 1 日星期二 22:10:49 ICT 2015

但看起來freshclam有一個“內部機制”來通知clamd有關更新。之後它可以重新載入數據庫，無需重新啟動程序。

我可以通過測試來確認這是正確的：

  • 編輯freshclam.conf 文件以將時間間隔更改為一分鐘（Checks 1440）
  • 重啟clamav-freshclam
  • cd /var/lib/clamav
  • rm daily.cvd
  • 等一分鐘
Sep  1 14:49:25 p freshclam[7654]: Downloading daily.cvd [100%]
Sep  1 14:49:28 p freshclam[7654]: daily.cvd updated (version: 19487, sigs: 1191913, f-level: 63, builder: neo)
Sep  1 14:49:28 p freshclam[7654]: Reading CVD header (bytecode.cvd):
Sep  1 14:49:28 p freshclam[7654]: OK
Sep  1 14:49:28 p freshclam[7654]: bytecode.cvd is up to date (version: 245, sigs: 43, f-level: 63, builder: dgoddard)
Sep  1 14:49:31 p freshclam[7654]: Database updated (3616181 signatures) from clamav.local (IP: 10.0.2.2)
Sep  1 14:49:31 p freshclam[7654]: Clamd successfully notified about the update.
Sep  1 14:49:31 p freshclam[7654]: --------------------------------------
Sep  1 14:49:32 p clamd[6693]: Reading databases from /var/lib/clamav
Sep  1 14:49:39 p clamd[6693]: Database correctly reloaded (3610621 signatures)

並且 clamav-daemon 沒有重新啟動。

請檢查您是否正在使用任何配置管理系統，例如 Puppet、Chef、CFEngine 等。它們可能會定期干擾服務。為糾正此問題而採取的具體行動取決於該服務在配置管理系統中的使用方式。

自己注意。

作業記憶體的輸出：

----------
         ID: clamav-daemon
   Function: service.running
     Result: True
    Comment: Service restarted
    Started: 06:27:52.736890
   Duration: 12997.632 ms
    Changes:
             ----------
             clamav-daemon:
                 True

看clamav公式：

 clamav-daemon:
   service:
     - running
     - order: 50
     - require:
       - service: clamav-freshclam
     - watch:
       - pkg: clamav-daemon
       - file: clamav-daemon
       - user: clamav

watched 狀態中的任何內容都沒有改變：

----------
         ID: clamav-daemon
   Function: pkg.latest
     Result: True
    Comment: Package clamav-daemon is already up-to-date.
    Started: 06:27:51.531415
   Duration: 53.224 ms
    Changes:

----------
         ID: clamav-daemon
   Function: file.managed
       Name: /etc/clamav/clamd.conf
     Result: True
    Comment: File /etc/clamav/clamd.conf is in the correct state
    Started: 06:27:51.760019
   Duration: 625.075 ms
    Changes:

----------
         ID: clamav
   Function: user.present
     Result: True
    Comment: User clamav is present and up to date
    Started: 06:27:51.590214
   Duration: 2.455 ms
    Changes:

為什麼服務已重新啟動？

尋找watch_in，我發現管理 pid 文件的狀態，如果 pid 文件發生更改，服務將重新啟動：

{%- macro manage_pid(path, user, group, watch_in_service, mode=644) -%}
   {%- if salt['file.file_exists'](path) %}
{{ path }}:
 file:
   - managed
   - user: {{ user }}
   - group: {{ group }}
   - mode: {{ mode }}
   - replace: False
       {%- if caller is defined -%}
           {%- for line in caller().split("\n") -%}
               {%- if loop.first %}
   - require:
               {%- endif %}
{{ line|trim|indent(6, indentfirst=True) }}
           {%- endfor -%}
       {%- endif %}
   - watch_in:
     - service: {{ watch_in_service }}
   {%- else %}
# {{ path }} does not exist, no need to manage
   {%- endif -%}
{%- endmacro -%}

{%- call manage_pid('/var/run/clamav/clamd.pid', 'clamav', 'clamav', 'clamav-daemon', 664) %}
- pkg: clamav-daemon
{%- endcall %}

在 的輸出中salt-run jobs.lookup_jid <job id number>，我看到了這個：

----------
         ID: /var/run/clamav/clamd.pid
   Function: file.managed
     Result: True
    Comment:
    Started: 06:27:52.392555
   Duration: 2.364 ms
    Changes:
             ----------
             group:
                 clamav
             user:
                 clamav

因此，該 pid 文件的所有者/組已更改為clamav. 最後，我發現原因是 clamav 守護程序是以root使用者身份在網路模式下執行的。因此，pid 文件被創建為root. 因此，管理 pid 文件的狀態必須更改為：

{%- call manage_pid('/var/run/clamav/clamd.pid', 'root', 'root', 'clamav-daemon', 664) %}
- pkg: clamav-daemon
{%- endcall %}

引用自：https://serverfault.com/questions/718239

相關問答

Ubuntu

如何在 Ubuntu 中創建 GPT 分區標籤並使用其標籤掛載分區？

  • March 25, 2022
檢視問答
Ubuntu

無法使用 debmirror 創建 apt 鏡像

  • June 30, 2021
檢視問答
Ubuntu

mysql 轉儲的恢復在 ubuntu 20.04 上看起來不同

  • May 12, 2021
檢視問答
Ubuntu

Mongod 在 Ubuntu 14.04 上陷入停止/等待

  • April 3, 2021
檢視問答
Ubuntu

Ubuntu 14.04 中缺少 Nagios 外掛“check_radius”？

  • February 17, 2021
檢視問答
Ubuntu

將系統從 14.04 升級到 16.04 後，我無法安裝 MySQL

  • April 14, 2020
檢視問答