Bug 1295815 – I can start condor_q as root but not as user though the user is member of condor with selinux=1

Bug 1295815 - I can start condor_q as root but not as user though the user is member of condor with selinux=1

Summary:	I can start condor_q as root but not as user though the user is member of con...

Status:	CLOSED DUPLICATE of bug 1295788

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	condor (Show other bugs)
Sub Component:
Version:	23
Hardware:	x86_64 Linux

Priority	unspecified Severity urgent
Target Milestone:	---
Target Release:	---
Assigned To:	matt
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2016-01-05 09:28 EST by Knut J BJuland
Modified:	2016-01-05 10:06 EST (History)
CC List:	6 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2016-01-05 10:03:53 EST
Type:	Bug
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Knut J BJuland 2016-01-05 09:28:45 EST

Description of problem:


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


How reproducible:
every time

Steps to Reproduce:
1.condor_Q
2.
3.

Actual results:
-- Failed to fetch ads from: <10.0.0.2:9618?addrs=10.0.0.2-9618&noUDP&sock=9226_d8da_4> : uefi_super_knut
SECMAN:2007:Failed to end classad message.


Expected results:
sudo condor_q


-- Schedd: uefi_super_knut : <10.0.0.2:49903>
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD               

0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended


Additional info:

Comment 1 Brian Bockelman 2016-01-05 09:35:59 EST

What version of HTCondor?  Is condor_shared_port enabled on your setup?  Is the shared_port daemon running?

Basically, the address used in the failure case (<10.0.0.2:9618?addrs=10.0.0.2-9618&noUDP&sock=9226_d8da_4>) indicates shared port is in use while the "expected results" case indicates shared port is not used.

Comment 2 Knut J BJuland 2016-01-05 10:03:53 EST


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

Comment 3 Knut J BJuland 2016-01-05 10:06:03 EST

I use default settings.

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