Gibt es eine Möglichkeit zu wissen, warum ein Dienst neu gestartet wird und wer es getan hat?

• Ubuntu 14.04
• Clamav 0,98,7

Das Problem wird clamav-daemonfast täglich neu gestartet:

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".

Es wurde ein Problem verursacht, wenn ausgeführt clamdscanwird:

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

Beachten Sie, dass ich am Anfang "fast" gesagt habe:

/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.

Wie du sehen kannst:

• es geschah nicht am 29. und 30. August

• es oft um die 6.27 neu gestartet , die die Zeit cron.dailyist Lauf

  27 6 * * * root nice -n 19 ionice -c3 run-parts --report /etc/cron.daily
  

Der Inhalt von /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=$?

Es gibt eine Logrotate-Datei für clamav-daemon:

/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
     }

aber es lädt nur das Protokoll neu:

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

Ich weiß, dass wir auditddie Binärdatei überwachen können , und hier ist ein Beispielprotokoll:

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 ist die UID von ... clamavBenutzer:

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

Gibt es in diesem Fall eine andere Möglichkeit zur Fehlerbehebung?

Antwort an @HBruijn:

Möglicherweise Freshclam nach dem Aktualisieren der AV-Definitionen?

Ich habe darüber nachgedacht. Hier ist das Protokoll:

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)

Ich bin mir nicht sicher, aber es sieht so aus, als hätte freshclam einen "internen Mechanismus", um clamd über das Update zu informieren. Danach kann die Datenbank einfach neu geladen werden, ohne dass der Prozess neu gestartet werden muss. Kannst du bestätigen?

Außerdem habe ich anhand des Zeitstempels gesehen, dass der Clamav-Daemon eine Stunde nach der Aktualisierung der Freshclam-Datenbank neu gestartet wurde. Es ist normal?

UPDATE Di Sep 1 22:10:49 ICT 2015

Es sieht jedoch so aus, als hätte Freshclam einen "internen Mechanismus", um Clamd über das Update zu informieren. Danach kann die Datenbank einfach neu geladen werden, ohne dass der Prozess neu gestartet werden muss.

Ich kann dies durch einen Test bestätigen:

• Bearbeiten Sie die Datei freshclam.conf, um das Intervall auf Minuten zu ändern ( Checks 1440)
• Starten Sie Clamav-Freshclam neu
• cd / var / lib / clamav
• rm daily.cvd

• warte eine Minute

  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)
  

und der clamav-daemon wird nicht neu gestartet.

Bitte überprüfen Sie, ob Sie ein Konfigurationsmanagementsystem verwenden, z. B. Puppet, Chef, CFEngine usw. Sie können in regelmäßigen Abständen die Dienste beeinträchtigen. Die genauen Maßnahmen zur Behebung dieses Problems hängen davon ab, wie der Dienst im Konfigurationsverwaltungssystem verwendet wird.

Notiz an mich.

Die Ausgabe aus dem Job-Cache:

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

Schauen Sie sich die Clamav-Formel an:

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

Nichts in den watched Staaten wurde geändert:

----------
          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:

Warum wurde der Dienst neu gestartet?

Auf der Suche nach habe watch_inich einen Status gefunden, der die PID-Datei verwaltet, und der Dienst wird neu gestartet, wenn die PID-Datei geändert wurde:

{%- 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 %}

In der Ausgabe von habe salt-run jobs.lookup_jid <job id number>ich Folgendes gesehen:

----------
          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

Daher wurde der Eigentümer / die Gruppe dieser PID-Datei in geändert clamav. Schließlich fand ich den Grund dafür, dass der clamav-Daemon als rootBenutzer im Netzwerkmodus ausgeführt wird . Daher wurde die PID-Datei als erstellt root. Der Status, der die PID-Datei verwaltet, muss also wie folgt geändert werden:

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