Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1072260

Summary:	HOSTNAME is not defined
Product:	[Retired] Beaker	Reporter:	Jan Stancek <jstancek>
Component:	beah	Assignee:	beaker-dev-list
Status:	CLOSED WORKSFORME	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.15	CC:	aigao, bpeck, dcallagh, ebaak, jburke, jstancek, pbunyan, rjoost, tools-bugs
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-11-09 14:13:25 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 Jan Stancek 2014-03-04 08:55:23 UTC

Description of problem:
All tests started failing with "rhts_task/no_result" after reboot.

This is content of task_output_stdout of task which made reboot:
rhts-compat.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

-- INFO: selinux enabled: trying to switch context...
/var/lib/beah/tortilla/wrappers.d/initgroups groups:  []
/var/lib/beah/tortilla/wrappers.d/initgroups no groups found, defaulting to [0]
8999
/mnt/tests/kernel/RHEL6/drivers/3rd-party /mnt/tests/kernel/RHEL6/drivers/3rd-party
rhts-compat.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

-- INFO: selinux enabled: trying to switch context...
/var/lib/beah/tortilla/wrappers.d/initgroups groups:  []
/var/lib/beah/tortilla/wrappers.d/initgroups no groups found, defaulting to [0]
/mnt/tests/kernel/RHEL6/drivers/3rd-party /mnt/tests/kernel/RHEL6/drivers/3rd-party
rhts-compat.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

-- INFO: selinux enabled: trying to switch context...
/var/lib/beah/tortilla/wrappers.d/initgroups groups:  []
/var/lib/beah/tortilla/wrappers.d/initgroups no groups found, defaulting to [0]
HOSTNAME is not defined

After this point all subsequent tasks failed with rhts_task/no_result and there is "HOSTNAME is not defined" is task_output_stdout.

Version-Release number of selected component (if applicable):
beah                   noarch  0.7.3-1.el7
rhts-test-env          noarch  4.59-1.el7

How reproducible:
rarely

Steps to Reproduce:
unknown at the moment

Actual results:
tasks are failing with rhts_task/no_result, there is "HOSTNAME is not defined" message in task_output_stdout.

Expected results:
all tests run

Additional info:

Comment 3 Dan Callaghan 2014-03-04 22:51:03 UTC

This check is coming from rhts-test-runner.sh:

114 if [ -z "$HOSTNAME" ]; then
115     echo "HOSTNAME is not defined"
116     exit 1
117 fi

$HOSTNAME should be set by bash to the system hostname, I'm not sure why it would not have been set (or perhaps, set to empty string).

$HOSTNAME is also set by rhts-environment.sh, for some reason, but that would be after the check in rhts-test-runner.sh happens.

On the console log for your job I can see that systemd claimed to set the hostname to the correct value on every reboot.

Comment 4 Dan Callaghan 2014-03-05 01:02:03 UTC

HOSTNAME is exported in /etc/profile, which makes this a bit more complicated to test -- HOSTNAME will be set in the environment of login shells, but otherwise not. If HOSTNAME is not set in the environment, bash populates it as an internal shell variable only (not exported).

That means the usual case for rhts-test-runner.sh is HOSTNAME is not set in the environment, it's a shell variable populated by bash on startup. So I think in this case, gethostname(3) in bash was returning empty string. It happened in every invocation of rhts-test-runner.sh after that last reboot, so it was not just some one-off.

For gethostname(3) to return empty string it must mean that either:
1. systemd did not set the hostname as it claimed
2. something else set the hostname to empty string after systemd set it
3. a kernel/glibc bug caused it to return empty string instead of the set hostname

None of these seem particularly likely, so I'm not sure how this could happen.

Jan, have you seen this on any other jobs besides that one?

Comment 6 Jan Stancek 2015-11-09 14:13:25 UTC

I don't recall seeing this in last 6 months. Closing.