Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2111578 - Rebooting Sat611 on RHEL8 removes all pulp logs
Summary: Rebooting Sat611 on RHEL8 removes all pulp logs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Packaging
Version: 6.11.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: 6.12.0
Assignee: satellite6-bugs
QA Contact: Lukas Pramuk
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-27 14:16 UTC by Pavel Moravec
Modified: 2022-11-16 13:35 UTC (History)
8 users (show)

Fixed In Version: satellite-6.12.0-3
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-16 13:34:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SAT-12677 0 None None None 2022-09-02 01:01:16 UTC
Red Hat Issue Tracker SAT-13288 0 None None None 2022-10-05 07:32:13 UTC
Red Hat Product Errata RHSA-2022:8506 0 None None None 2022-11-16 13:35:03 UTC

Description Pavel Moravec 2022-07-27 14:16:26 UTC
Description of problem:
pulp(*) logs to rsyslog, which usually means to /var/log/messages and journalctl. BUT on default installation of Sat6.11 on RHEL8:
- there is no /var/log/messages
- journal logs are *transient*, which means a reboot purges all its logs

(*) pulp among others, but this is the most important component, I would say)

Therefore, rebooting such Satellite means loosing *all* pulp logs.

That would limit support engineers from investigating customer issues in scenarios like:
- customer hitting a problem (say swapping)
- they reboot the OS as an immediate intervention
- then they provide sosreport or any other data

TTL;DR: we need default installations of Sat6.11+ on RHEL8 to permanently keep (pulp) logs - either in /var/log/messages or changing journal logs to permanent


Version-Release number of selected component (if applicable):
6.11 on RHEL8


How reproducible:
100%


Steps to Reproduce:
1. Do a bad thing to pulp
2. Check the bad thing in logs (journalctl --since=today)
3. Reboot the OS
4. Check the bad thing in the logs again


Actual results:
4. Logs are gone.


Expected results:
4. Logs are kept (optionally with some logrotation / housekeeping)


Additional info:

Comment 2 Eric Helms 2022-07-27 17:10:15 UTC
I wonder if this is a mileage may vary scenario? For example, I provisioned a clean RHEL 8.6 system and installed 6.11 and I have a /var/log/messages present with the logs pre and post reboot.

Comment 3 Pavel Moravec 2022-07-27 17:28:26 UTC
(In reply to Eric Helms from comment #2)
> I wonder if this is a mileage may vary scenario? For example, I provisioned
> a clean RHEL 8.6 system and installed 6.11 and I have a /var/log/messages
> present with the logs pre and post reboot.

Nice finding.

I am double-checking how I installed my RHEL8.6 . It apparently lacks rsyslog package - while default installation of that package does configure into /etc/rsyslog.conf:

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

Comment 4 Eric Helms 2022-07-27 19:13:36 UTC
If we want to enforce persistent logs from a Satellite perspective versus how the OS is configured, we could make rsyslog a dependency of the satellite and satellite-capsule meta packages.

Comment 5 Pavel Moravec 2022-07-27 19:57:14 UTC
Hmm... I installed 8.6 GA from corporate PXE, once tried "Minimal Install" and once the default "Server" - both times, rsyslog package is missing (and BZ reproduced). Anyway I would appreciate if somebody else can confirm my observation (to prove I am not insane :) ).

Our installer doc mentions just @base package group, not sure if that does contain rsyslog or not - but till the very default installation ends up with no rsyslog, it is easy to hit this problem.

Having rsyslog as dependency of satellite and satellite-capsule sounds a great idea to me (isnt there yet better *one* similar package for both Sat and Caps?).

Comment 7 Pavel Moravec 2022-07-28 15:57:19 UTC
On RHEL7, it seems that even Minimal installation does contain rsyslog package - at least I do see it present on RHEL7.9 minimal install.

Anyway somebody from Anaconda should ideally confirm those findings (rsyslog in RHEL7 minimal but not in RHEL8 Server or Minimal) - or somebody else shall independently on me double-check my findings.

Comment 8 Pablo Mendez Hernandez 2022-07-29 07:28:20 UTC
FWIW, the RHEL 8.6 KVM Guest Image distributed in the Customer Portal has rsyslog installed.

Comment 9 Eric Helms 2022-08-02 13:59:25 UTC
The KCS https://access.redhat.com/solutions/696893 would indicate that the proper way to enable persistent logging is:


# sed -i 's/#Storage=auto/Storage=persistent/' /etc/systemd/journald.conf
# systemctl restart systemd-journald.service


This would appear to be the more direct, proper solution but it has the downside of requiring system configuration versus just installing a package. That being said, if this is something we desire to have as the base configuration for a system running Satellite or a Capsule we could handle this through the installer.

@ekohlvan -- mind sharing your thoughts on solution path?

Comment 10 Ewoud Kohl van Wijngaarden 2022-08-04 10:27:27 UTC
(In reply to Eric Helms from comment #9)
> The KCS https://access.redhat.com/solutions/696893 would indicate that the
> proper way to enable persistent logging is:
> 
> # sed -i 's/#Storage=auto/Storage=persistent/' /etc/systemd/journald.conf
> # systemctl restart systemd-journald.service

Installer route: add this to custom-hiera.yaml

systemd::journald_settings:
  Storage: persistent

See https://forge.puppet.com/modules/puppet/systemd#journald-configuration

> This would appear to be the more direct, proper solution but it has the
> downside of requiring system configuration versus just installing a package.
> That being said, if this is something we desire to have as the base
> configuration for a system running Satellite or a Capsule we could handle
> this through the installer.
> 
> @ekohlvan -- mind sharing your thoughts on solution path?

Until now we've always avoided managing the system in this way. systemd-journald and (r)syslog were always up to the admin. You could make the argument that the application works fine without persistent logging and it gets into the area of monitoring.

A small side step: we have https://access.redhat.com/documentation/en-us/red_hat_satellite/6.11/html/administering_red_hat_satellite/logging_and_reporting_problems_admin#Configuring_Logging_to_Journal_admin today and I recall there was also a KCS about shipping those logs. Back then we also had some debate over whether we should or shouldn't manage the logging stack.

One thing I have found with systemd-journald is that by default it doesn't have any maximum retention and it does get large. On my system with spinning disks this is noticeably slow and I have set up retention. The only question is, what should that retention be?

If a simple dnf install rsyslog is sufficient for persistent logging, I'd say adding rsyslog as a dependency is the safest route and it's what a non-minimal install sets up anyway so the impact is limited for most users.

Comment 11 Lukas Pramuk 2022-10-05 07:22:05 UTC
VERIFIED.

@Satellite 6.12.0 Snap13
satellite-common-6.12.0-3.el8sat.noarch

by this very simple step:

# rpm -qR satellite-common | grep log
rsyslog

>>> rsyslog requirement is correctly expressed as a rpm dependency (for both Satellite and Capsule)

Comment 15 errata-xmlrpc 2022-11-16 13:34:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.12 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8506


Note You need to log in before you can comment on or make changes to this bug.