Bug 1377027 - sealert -l: failed to connect to server: No such file or directory
Summary: sealert -l: failed to connect to server: No such file or directory
Keywords:
Status: CLOSED DUPLICATE of bug 1348955
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: setroubleshoot
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Petr Lautrbach
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-17 17:37 UTC by Brian J. Murrell
Modified: 2016-09-19 07:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-19 07:24:36 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Brian J. Murrell 2016-09-17 17:37:07 UTC
Description of problem:
# sealert -l b1eecb90-3c8b-4024-9334-024e301c3e3b
failed to connect to server: No such file or directory

Version-Release number of selected component (if applicable):
setroubleshoot-server-3.2.24-4.el7_2.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Locate an AVC message in the journal/messages
2. run "sealert -l $uid" as it suggests

Actual results:
failed to connect to server: No such file or directory

Expected results:
Should work without an error

Additional info:

Comment 2 Petr Lautrbach 2016-09-18 14:49:43 UTC
This issue will be fixed in the next update.

As a workaround you can either 

- install setroubleshoot package

or

- download http://pkgs.fedoraproject.org/cgit/rpms/setroubleshoot.git/tree/setroubleshoot.tmpfiles, save it as /etc/tmpfiles.d/setroubleshoot.conf and run 'systemd-tmpfiles --create'

Comment 3 Brian J. Murrell 2016-09-18 16:25:33 UTC
Installing setroubleshoot does not fix the problem.  Or is there something else I have to do after installing that.  Not that I am fan of installing it given that it pulls in lots of dependencies that shouldn't be necessary on a server

(In reply to Petr Lautrbach from comment #2)
> This issue will be fixed in the next update.

As in RHEL 7.3?  Do you have a specific RPM version number I can look forward to?

> As a workaround you can either 
> 
> - install setroubleshoot package

Installing setroubleshoot does not seem to fix the problem.  Or is there something else I have to do after installing that?  Not that I am fan of installing it given that it pulls in lots of dependencies that shouldn't be necessary on a headless machine/server.

> or
> 
> - download
> http://pkgs.fedoraproject.org/cgit/rpms/setroubleshoot.git/tree/
> setroubleshoot.tmpfiles, save it as /etc/tmpfiles.d/setroubleshoot.conf and
> run 'systemd-tmpfiles --create'

Still no joy.  Is there a service I have to reload or restart after doing that?

Comment 4 Petr Lautrbach 2016-09-18 18:33:15 UTC
(In reply to Brian J. Murrell from comment #3)
> Installing setroubleshoot does not fix the problem.  Or is there something
> else I have to do after installing that.  Not that I am fan of installing it
> given that it pulls in lots of dependencies that shouldn't be necessary on a
> server

I completely understand. 

> (In reply to Petr Lautrbach from comment #2)
> > This issue will be fixed in the next update.
> 
> As in RHEL 7.3?  Do you have a specific RPM version number I can look
> forward to?

It's fixed in setroubleshoot-3.2.26-1.el7

> 
> > As a workaround you can either 
> > 
> > - install setroubleshoot package
> 
> Installing setroubleshoot does not seem to fix the problem.  Or is there
> something else I have to do after installing that?  Not that I am fan of
> installing it given that it pulls in lots of dependencies that shouldn't be
> necessary on a headless machine/server.
> 
> > or
> > 
> > - download
> > http://pkgs.fedoraproject.org/cgit/rpms/setroubleshoot.git/tree/
> > setroubleshoot.tmpfiles, save it as /etc/tmpfiles.d/setroubleshoot.conf and
> > run 'systemd-tmpfiles --create'
> 
> Still no joy.  Is there a service I have to reload or restart after doing
> that?

The important thing is the existence of /run/setroubleshoot directory. It needs to be owned by setroubleshoot:setroubleshoot

When setroubleshootd  starts, it creates an unix socket - /run/setroubleshoot/setroubleshoot_server

So if it's not there, try to restart setroubleshootd and run sealert again.

Comment 5 Petr Lautrbach 2016-09-19 07:24:36 UTC

*** This bug has been marked as a duplicate of bug 1348955 ***


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