Bug 1669833

Summary: In RHEL 8, "/dev/null" has been included in the sosreport.
Product: Red Hat Enterprise Linux 8 Reporter: Ishan Kulkarni <ikulkarn>
Component: sosAssignee: Pavel Moravec <pmoravec>
Status: CLOSED NOTABUG QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: agk, bmr, gavin, ikulkarn, plambri, sbradley
Target Milestone: rc   
Target Release: 8.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-28 06:40:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ishan Kulkarni 2019-01-27 12:34:27 UTC
Description of problem:

In RHEL 8, "/dev/null" has been included in the sosreport. Is it an intended inclusion in RHEL 8 and if yes, what is the significance of it in the sos. The directory "/dev" itself was not available in RHEL 7 sosreports.

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

Observed on RHEL 8 Beta. Further details are :

#> uname -r
4.18.0-32.el8.x86_64

#> rpm -qa | grep -i sos
sos-3.6-7.el8.noarch


How reproducible:

100%


Steps to Reproduce:
1. Install RHEL 8 Beta
2. Run command "sosreport"
3. After capture gets over, extract and check in it.

Actual results:

"/dev/null" gets captured in the sosreport.

#> cd sosreport-rhel-2019-01-27-msufcfd/

#> tree dev/
dev/
└── null

0 directories, 1 file

#> cd dev/

#> ll
total 0
crw-rw-rw-. 1 root root 1, 3 Jan 27 20:45 null


Expected results:

"/dev/null" need not be there.


Additional info:

I am not quite sure if this an intended inclusion. If yes, can someone please give a justification for it?

Comment 1 Pavel Moravec 2019-01-27 15:53:27 UTC
It is not dedicately required to collect the file, on the other hand: what problem it causes when we collect it? What is the bug here? :)

Why sosreport collects it:

sosreport -vvv --batch --build 2>&1 | grep /dev/null
..
[plugin:systemd] made link target '/dev/null' relative as '../../../dev/null'
[plugin:systemd] copying link '/etc/systemd/system/systemd-timedated.service' pointing to '/dev/null' with isdir=False
[plugin:systemd] normalized link target '/dev/null' as '/dev/null'
[plugin:systemd] creating character device node at archive:'/dev/null'
..

So systemd plugin collecting /etc/systemd/ attempts to collect /etc/systemd/system/systemd-timedated.service that is a symlink to /dev/null. Some character special file (where some of them are useful to collect).

Yes, we can blacklist /dev/null as there is nothing usefull in the file. The question is why? What will be the feature or additional value or fix of some flaw?

(moreover, we really should persist the information "systemd-timedated.service points to '/dev/null'" that can help troubleshooting systemd issues - if we won't capture /dev/null, how else to collect/keep this information? symlink with broken target? that might suggest the system does not have /dev/null ..?)


Please specify what is the flaw or what would be the feature in not collecting /dev/null (a character special file of trivial size).

Comment 2 Ishan Kulkarni 2019-01-28 01:55:01 UTC
Hi Pavel,

Agree with the comment. This is not really a bug but while comparing sosreports captured on RHEL 7 and 8 I observed this. I did not know that there is a symlink between systemd-timedated.service and /dev/null, as I rarely deal with systemd issues, so thanks for the info. Please feel free to close this bug.

BR,
Ishan

Comment 3 Bryn M. Reeves 2019-01-28 10:43:17 UTC
It is collected (like any special file, including device special nodes and sockets/fifos) so that the user can diagnose problems involving incorrect permissions, inode type, and other problems that could cause users of /dev/null to fail.

Any time that a path collected by sos ultimately resolves to a file of this type we collect it - on the extraction host you may see errors if the user unpacking the archive does not have sufficient permissions to create these file types, but this is a non-fatal error and other content will be extracted correctly.

Comment 4 Bryn M. Reeves 2019-01-28 10:43:59 UTC
> The directory "/dev" itself was not available in RHEL 7 sosreports.

This is dependent on system configuration and the enabled plugin set.