Rsyslog disabled after upgrade to VZ7

Discussion in 'General Questions' started by SteveITS, Apr 8, 2017.

  1. SteveITS

    SteveITS Tera Poster

    Messages:
    277
    I noticed /var/log/messages and other logs stopped the day I upgraded this node to Virtuozzo 7 (our first VZ7 node). Is this normal? Or should it have been re-enabled after the upgrade?

    # systemctl status rsyslog.service
    rsyslog.service - System Logging Service
    Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; disabled; vendor preset: enabled)
    Active: inactive (dead)

    # tail -n 1 /var/log/messages
    Apr 5 14:08:41 hn6 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2410" x-info="http://www.rsyslog.com"] exiting on signal 15.
     
  2. Pavel

    Pavel A.I. Auto-Responder Staff Member

    Messages:
    478
    Hello Steve,

    I've just updated my host to test this, and nothing bad happened to rsyslogd. It is still enabled and running happily.
    Could it be that service was disabled some time ago for some reason, and was stopped but not started upon update?
     
  3. SteveITS

    SteveITS Tera Poster

    Messages:
    277
    Thank you for your effort. Rsyslog was logging up until the minute of the upgrade. I have enabled and started it.

    I also see:
    # systemctl --failed
    UNIT LOAD ACTIVE SUB DESCRIPTION
    â systemd-modules-load.service loaded failed failed Load Kernel Modules
    â vz_635096d6-99b6-4092-8fa0-dc2410cd692e.service loaded failed failed Container {635096d6-99b6-4092-8fa0-dc2410cd692e} service
    â vzupgrade.service loaded failed failed VzUpgrade first-run service

    The last line makes me think something didn't finish? Is there a way to see if "VzUpgrade first-run service" actually did run once already?

    Also, there aren't any containers on this particular server, and there were not any containers for at least a long time (1-2 years?) prior to the upgrade, so the message about the container is strange.

    Edit (Apr 09 02:13 is the most recent boot):
    # systemctl status vzupgrade.service
    â vzupgrade.service - VzUpgrade first-run service
    Loaded: loaded (/lib/systemd/system/vzupgrade.service; enabled; vendor preset: disabled)
    Active: failed (Result: exit-code) since Sun 2017-04-09 02:13:35 CDT; 1 day 7h ago
    Main PID: 2014 (code=exited, status=203/EXEC)

    Apr 09 02:13:35 hn6.example.net systemd[1]: Starting VzUpgrade first-run service...
    Apr 09 02:13:35 hn6.example.net systemd[1]: vzupgrade.service: main process exited, code=exited, status=203/EXEC
    Apr 09 02:13:35 hn6.example.net systemd[1]: Failed to start VzUpgrade first-run service.
    Apr 09 02:13:35 hn6.example.net systemd[1]: Unit vzupgrade.service entered failed state.
    Apr 09 02:13:35 hn6.example.net systemd[1]: vzupgrade.service failed.
     
    Last edited: Apr 10, 2017
  4. Pavel

    Pavel A.I. Auto-Responder Staff Member

    Messages:
    478
    Excuse me for misunderstanding. I thought you were speaking of the updates installation.
    However, as I can see you've performed upgrade from vz6 to vz7.
    VzUpgrade appears only on a host which has been in-place upgraded from vz6 to vz7. Is that the case for you?
    When was it performed? I wonder how exactly it correlates with the logs.
     
  5. SteveITS

    SteveITS Tera Poster

    Messages:
    277
    Yes this is our first node upgraded from 6 to 7. I went ahead and tried to start it and got slightly different output from systemctl status:

    Apr 10 12:11:13 hn6.example.net systemd[1]: Starting VzUpgrade first-run service...
    Apr 10 12:11:13 hn6.example.net systemd[155210]: Failed at step EXEC spawning /var/lib/vzupgrade/vzupgrade-post: Permission denied
    Apr 10 12:11:13 hn6.example.net systemd[1]: vzupgrade.service: main process exited, code=exited, status=203/EXEC
    Apr 10 12:11:13 hn6.example.net systemd[1]: Failed to start VzUpgrade first-run service.
    Apr 10 12:11:13 hn6.example.net systemd[1]: Unit vzupgrade.service entered failed state.
    Apr 10 12:11:13 hn6.example.net systemd[1]: vzupgrade.service failed.

    Shouldn't the two vzupgrade-post scripts be executable?

    # ll /var/lib/vzupgrade
    -rw-r----- 1 root root 10398 Apr 5 14:06 dispatcher.xml
    -rw-r--r-- 1 root root 4787 Apr 5 14:06 iflist
    -rw-r--r-- 1 root root 174 Apr 5 14:06 net_list
    -rw-r--r-- 1 root root 2587 Apr 5 14:43 vzupgrade-post
    -rw-r--r-- 1 root root 873 Apr 4 15:36 vzupgrade-post-ves
    -rw-r--r-- 1 root root 304 Apr 4 15:36 vzupgrade.service
     
  6. Pavel

    Pavel A.I. Auto-Responder Staff Member

    Messages:
    478
    Hello Steve,

    They probably should. But I wouldn't recommend just running the scripts blindly.
    Please contact technical support to investigate the issue and find a proper solution for this case.
     
  7. SteveITS

    SteveITS Tera Poster

    Messages:
    277
    Hi, support has already duplicated rsyslog and the failed services so it seems to be a problem with the upgrade. I will pursue further with them.

    Edit: I've been told vzupgrade.service is intentional...the script are disabled and kept for a record. And that systemd-modules-load.service is a Red Hat bug. Rsyslog being disabled is the bug.

    I did have one upgraded server leave shamand disabled after upgrade but support didn't duplicate that.
     
    Last edited: Apr 15, 2017

Share This Page