syslog is filled with error messages from OPAL_DUMP

Bug #1353542 reported by bugproxy
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ppc64-diag (Ubuntu)
Fix Released
Undecided
Unassigned
Trusty
Fix Released
Undecided
Unassigned
Utopic
Won't Fix
Undecided
Unassigned

Bug Description

-- Problem Description --
Steps to recreate the problem

1) Install Ubuntu 14.10 on P8 system - non virtualized mode
2) Install ppc64-diag and related packages.

When I examined /var/log/syslog, I observed it's filled with repeated messages show below.

Jul 22 09:00:37 lep8d OPAL_DUMP[108208]: Error accessing output dir: /var/log/dump (2: No such file or directory)
Jul 22 09:00:38 lep8d OPAL_DUMP[108210]: Error accessing output dir: /var/log/dump (2: No such file or directory)
Jul 22 09:00:39 lep8d OPAL_DUMP[108212]: Error accessing output dir: /var/log/dump (2: No such file or directory)
Jul 22 09:00:40 lep8d OPAL_DUMP[108214]: Error accessing output dir: /var/log/dump (2: No such file or directory)

I have not tried creating /var/log/dump directory to see if these stop. Can these repeated messages be suppressed ? It doesn't make sense to fill the syslog with continuous messages.

From the code in opal_errd/extract_opal_dump.c

#define DEFAULT_OUTPUT_DIR "/var/log/dump"
char *opt_output_dir = DEFAULT_OUTPUT_DIR;
...
 rc = stat(opt_output_dir, &s);
        if (rc != 0) {
                syslog(LOG_ERR, "Error accessing output dir: %s (%d: %s)\n",
                       opt_output_dir, errno, strerror(errno));
                exit(EXIT_FAILURE);
        }

We get the error because the file doesn't exist.

And since in
opal_errd/opal_errd.c:
we don't create file if it doesn't exist, the error will occure.
 dir_fd = open(dirname(opt_output_dir), O_RDONLY|O_DIRECTORY);

Should I suggest to add the O_CREATE flag if it doesn't exist ?

Creating the directory manually gives the following output:
Jul 24 21:20:38 lep8d OPAL_DUMP[64949]: New platform dump available. File: /var/log/dump/SYSDUMP.1084A7T.00000003.20140724081414
Jul 24 21:20:38 lep8d kernel: [26142.017382] create_dump_obj: New platform dump. ID = 0x3a000000 Size 7256717
Jul 24 21:20:38 lep8d OPAL_DUMP[64947]: Failed to read platform dump: /sys/firmware/opal/dump/0x2-0x3/dump (5:Input/output error)
Jul 24 21:20:38 lep8d OPAL_DUMP[64947]: Failed to acknowledge platform dump: /sys/firmware/opal/dump/0x2-0x3/acknowledge (2:No such file or directory)
Jul 24 21:20:38 lep8d kernel: [26142.038146] dump_read_data: Extract dump failed for ID 0x3
Jul 24 21:20:39 lep8d OPAL_DUMP[64954]: Failed to read platform dump: /sys/firmware/opal/dump/0x1-0x3a000000/dump (5:Input/output error)
Jul 24 21:20:39 lep8d OPAL_DUMP[64955]: Failed to read platform dump: /sys/firmware/opal/dump/0x1-0x3a000000/dump (5:Input/output error)
Jul 24 21:20:39 lep8d OPAL_DUMP[64955]: Failed to acknowledge platform dump: /sys/firmware/opal/dump/0x1-0x3a000000/acknowledge (2:No such file or directory)
Jul 24 21:20:39 lep8d kernel: [26143.041011] dump_attr_read: Platform dump partially read.ID = 0x3a000000
Jul 24 21:20:39 lep8d kernel: [26143.041230] dump_read_data: Extract dump failed for ID 0x3a000000

root@lep8d:/tmp/ppc64-diag-2.6.6# ls /sys/firmware/opal/
dump image msglog update_flash
elog manage_flash sysparams validate_flash
root@lep8d:/tmp/ppc64-diag-2.6.6# ls /sys/firmware/opal/dump/
initiate_dump

I think the ubuntu packaging should create this directory rather than relying on server to create it. This would be common with other daemons (which usually error out rather than create directories).

the other log messages around there are a bit of a worry too...

bugproxy (bugproxy)
tags: added: architecture-ppc64le bugnameltc-113639 severity-high targetmilestone-inin1410
Luciano Chavez (lnx1138)
affects: ubuntu → ppc64-diag (Ubuntu)
Changed in ppc64-diag (Ubuntu):
status: New → Confirmed
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2014-10-16 10:42 EDT-------
Looks like issue is not yet fixed in latest ppc64-diag version in Ubuntu 14.10 (v2.6.7)

-Vasant

Revision history for this message
bugproxy (bugproxy) wrote : Scripts to handle /var/log/dump

Default Comment by Bridge

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2014-10-28 06:53 EDT-------
(In reply to comment #24)
> Created attachment 93742 [details]
> Scripts to handle /var/log/dump
>
> These are the preinst and postrm scripts to create and remove
> /var/log/dump
> scripts that is where the logs used by ppc64-diag packages are saved.
>
> These two files solve a problem if the directory doesn't exists, as:
>
> "Error accessing output dir: /var/log/dump (2: No such file or
> directory)"
>
> This could be also found on the following git tree
> https://github.com/leitao/ppc64-diag.git (Commit
> d3074ea82a68bcefc25cbc6cc3e150b10d182f57)

Patch looks good..

-Vasant

bugproxy (bugproxy)
tags: added: targetmilestone-inin1504
removed: targetmilestone-inin1410
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ppc64-diag - 2.6.7-0ubuntu2

---------------
ppc64-diag (2.6.7-0ubuntu2) vivid; urgency=medium

  * Backport some patches from git for little-endian support (LP: #1391331)
    - printk-dump-sections.patch: Add printk log in the list of dump sections
    - extract-platdump-endian.patch: rtas_errd: LE fixes for extract_platdump
    - prrn-event-endian.patch: rtas_errd: Fix PRRN Event handling on LE POWER
  * Ship a /var/log/dump directory which write to at runtime (LP: #1353542)
 -- Adam Conrad <email address hidden> Mon, 02 Feb 2015 01:28:46 -0700

Changed in ppc64-diag (Ubuntu):
status: Confirmed → Fix Released
Adam Conrad (adconrad)
Changed in ppc64-diag (Ubuntu Utopic):
status: New → Won't Fix
Changed in ppc64-diag (Ubuntu Trusty):
milestone: none → ubuntu-14.04.3
Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted ppc64-diag into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ppc64-diag/2.6.9-0ubuntu1~14.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ppc64-diag (Ubuntu Trusty):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Adam Conrad (adconrad) wrote :

Verified that the new version creates /var/log/dump

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ppc64-diag - 2.6.9-0ubuntu1~14.04

---------------
ppc64-diag (2.6.9-0ubuntu1~14.04) trusty; urgency=medium

  * New upstream release. (LP: #1463063)
    - Added Home Run (5887) enclosure diagnostics support
    - Added PHB hotplugging support for PowerKVM guest
    - Fixed LE issue in rtas_errd
    - Fixed memory leak in rtas_errd

ppc64-diag (2.6.8-0ubuntu2) wily; urgency=medium

  * debian/ppc64-diag.*.upstart, debian/ppc64-diag.*.init: Fix platform checks,
    so that opal_errd and rtas_errd only start when supported.
  * debian/no-upstream-init.patch:
    - fix up the systemd services to not make use of the upstream init scripts,
      and instead start the daemon directly.
    - ship an extra small script to handle system registration, to be used from
      the upstart/systemd/sysv scripts.

ppc64-diag (2.6.8-0ubuntu1) wily; urgency=medium

  * New upstream release. (LP: #1459698)
  * Drop debian patches included upstream:
    - printk-dump-sections.patch: Add printk log in the list of dump sections
    - extract-platdump-endian.patch: rtas_errd: LE fixes for extract_platdump
    - prrn-event-endian.patch: rtas_errd: Fix PRRN Event handling on LE POWER

ppc64-diag (2.6.7-0ubuntu2) vivid; urgency=medium

  * Backport some patches from git for little-endian support (LP: #1391331)
    - printk-dump-sections.patch: Add printk log in the list of dump sections
    - extract-platdump-endian.patch: rtas_errd: LE fixes for extract_platdump
    - prrn-event-endian.patch: rtas_errd: Fix PRRN Event handling on LE POWER
  * Ship a /var/log/dump directory which write to at runtime (LP: #1353542)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 05 Aug 2015 14:05:42 -0400

Changed in ppc64-diag (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Adam Conrad (adconrad) wrote : Update Released

The verification of the Stable Release Update for ppc64-diag has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.