• Icon: Story Story
    • Resolution: Unresolved
    • Icon: Normal Normal
    • rhel-9.6
    • rhel-9.4
    • dnf
    • dnf-4.14.0-22.el9
    • Low
    • rhel-sst-cs-software-management
    • ssg_core_services
    • 17
    • 20
    • 0
    • False
    • Hide

      None

      Show
      None
    • Yes
    • None
    • Hide

      Backport https://github.com/rpm-software-management/dnf/pull/2005.

      Test that "dnf-automatic" with "apply_updates = yes" and "send_error_messages = yes" set actuates an emitter with en error message if applying updates fail.

      Be ware that dnf-4.14.0-17 already prints the error on a standard error output.
      Be ware that some error conditions (e.g. a disk so full that DNF even does not initialize) might still be unable to emit the error.

      An automated test will be written.

      Show
      Backport https://github.com/rpm-software-management/dnf/pull/2005 . Test that "dnf-automatic" with "apply_updates = yes" and "send_error_messages = yes" set actuates an emitter with en error message if applying updates fail. Be ware that dnf-4.14.0-17 already prints the error on a standard error output. Be ware that some error conditions (e.g. a disk so full that DNF even does not initialize) might still be unable to emit the error. An automated test will be written.
    • Pass
    • None
    • Enhancement
    • Hide
      .DNF Automatic can now notify users about a failed update

      With this update, a new `send_error_messages` boolean option has been added to the `[emitters]` section of the `/etc/dnf/automatic.conf` configuration file. As a result, if you set `send_error_messages` to `yes`, the DNF Automatic tool notifies you about failed automatic updates by using an emitter configured in the `emit_via` option.

      NOTE: This feature is disabled by default.
      Show
      .DNF Automatic can now notify users about a failed update With this update, a new `send_error_messages` boolean option has been added to the `[emitters]` section of the `/etc/dnf/automatic.conf` configuration file. As a result, if you set `send_error_messages` to `yes`, the DNF Automatic tool notifies you about failed automatic updates by using an emitter configured in the `emit_via` option. NOTE: This feature is disabled by default.
    • Done
    • None

      What were you trying to do that didn't work?

      When /usr is full, dnf-automatic does not run properly (as dnf exits prematurely), and no email is sent notifying the user about what happened.

      What is the impact of this issue to you?

      The user has no notification about what why dnf-automatic did not run.

      Please provide the package NVR for which the bug is seen:

      dnf-automatic-4.14.0-9.el9.noarch (the component list in Jira does not list a "dnf-automatic" component).

      How reproducible is this bug?:

      Every time

      Steps to reproduce

      1. Set up a RHEL system where /usr is a separate partition
      2. Ensure there is something for dnf to upgrade
      3. Ensure dnf-automatic is configured to send email, e.g.:
        # cat /etc/dnf/automatic.conf
        [commands]
        upgrade_type = default
        random_sleep = 0
        network_online_timeout = 60
        download_updates = yes
        apply_updates = yes
        [emitters]
        emit_via = stdio
        [email]
        email_from = root@localhost
        email_to = root@localhost
        email_host = localhost
        [command]
        [command_email]
        command_format = "mail -Ssendwait -s {subject} -r {email_from} {email_to}"
        stdin_format = "{body}"email_from = root@localhost
        email_to = root@localhost
        [base]
        debuglevel = 1
         
      1. Fill up /usr, e.g.:
        dd if=/dev/random of=/usr/filler
      1. systemctl start dnf-automatic

      Expected results

      An email (or the configured notification method) should be sent, detailing why dnf did not run.

      Actual results

      No notification about the problem is sent. The only relevant system logs in the journal are:

      Oct 09 10:13:04 r94-dnfauto systemd[1]: Starting dnf automatic...
      Oct 09 10:13:05 r94-dnfauto dnf-automatic[3762]: Updating Subscription Management repositories.
      Oct 09 10:13:09 r94-dnfauto dnf-automatic[3762]: Last metadata expiration check: 0:16:02 ago on Wed 09 Oct 2024 09:57:07 AM CEST.
      Oct 09 10:13:10 r94-dnfauto dnf-automatic[3762]: Running transaction check
      Oct 09 10:13:10 r94-dnfauto dnf-automatic[3762]: Transaction check succeeded.
      Oct 09 10:13:10 r94-dnfauto dnf-automatic[3762]: Running transaction test
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]: The downloaded packages were saved in cache until the next successful transaction.
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]: You can remove cached packages by executing 'dnf clean packages'.
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]: Error: Transaction test error:
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]:   installing package bash-5.1.8-9.el9.x86_64 needs 6MB more space on the /usr filesystem
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]: Error Summary
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]: -------------
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]: Disk Requirements:
      Oct 09 10:13:11 r94-dnfauto dnf-automatic[3762]:    At least 6MB more space needed on the /usr filesystem.
      Oct 09 10:13:11 r94-dnfauto systemd[1]: dnf-automatic.service: Main process exited, code=exited, status=1/FAILURE
      Oct 09 10:13:11 r94-dnfauto systemd[1]: dnf-automatic.service: Failed with result 'exit-code'.
      Oct 09 10:13:11 r94-dnfauto systemd[1]: Failed to start dnf automatic.

            [RHEL-61882] dnf-automatic does not send email when /usr is full

            Marek Blaha added a comment -

            If the /usr is full, the error can be raised even before the transaction execution, during the `fill_sack()` call. To report also this error, another upstream patch needs to be backported on top of already mentioned PR#2005 - https://github.com/rpm-software-management/dnf/pull/2169

            Marek Blaha added a comment - If the /usr is full, the error can be raised even before the transaction execution, during the `fill_sack()` call. To report also this error, another upstream patch needs to be backported on top of already mentioned PR#2005 - https://github.com/rpm-software-management/dnf/pull/2169

            Marek Blaha added a comment -

            Marek Blaha added a comment - Now there is a test upstream for https://github.com/rpm-software-management/dnf/pull/2005 that can be used for the bug verification: https://github.com/rpm-software-management/ci-dnf-stack/pull/1603

            Petr Pisar added a comment -

            I confirm this behavior.

            Reporting errors was added as an opt-in feature in upstream dnf-4.18.2. See https://github.com/rpm-software-management/dnf/pull/2005. Upstream explicitly made the error reporting optional because until then a notification was sent only in case of a successfully applied update. No update or failed update did not produce any notification.

            As such this request would be addressed in RHEL in the same opt-in manner (user would have to configure dnf-automatic with "send_error_messages=true").

            As such this request would qualify as a new feature.

            DNF team will decide soon when this feature will be applied to RHEL 9.

            Petr Pisar added a comment - I confirm this behavior. Reporting errors was added as an opt-in feature in upstream dnf-4.18.2. See https://github.com/rpm-software-management/dnf/pull/2005 . Upstream explicitly made the error reporting optional because until then a notification was sent only in case of a successfully applied update. No update or failed update did not produce any notification. As such this request would be addressed in RHEL in the same opt-in manner (user would have to configure dnf-automatic with "send_error_messages=true"). As such this request would qualify as a new feature. DNF team will decide soon when this feature will be applied to RHEL 9.

              mblaha@redhat.com Marek Blaha
              rhn-support-jsantos Juan Santos
              packaging-team-maint packaging-team-maint
              Martin Banas Martin Banas
              Mariya Pershina Mariya Pershina
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: