Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot start tiflash if TimeZone is not set #2218

Closed
yeya24 opened this issue Apr 16, 2020 · 1 comment · Fixed by #2242
Closed

Cannot start tiflash if TimeZone is not set #2218

yeya24 opened this issue Apr 16, 2020 · 1 comment · Fixed by #2242
Assignees

Comments

@yeya24
Copy link
Contributor

yeya24 commented Apr 16, 2020

Bug Report

What version of Kubernetes are you using?

v1.15.2

What version of TiDB Operator are you using?

The latest release

What storage classes exist in the Kubernetes cluster and what are used for PD/TiKV pods?

What's the status of the TiDB cluster pods?

What did you do?

Deploy a TiDB cluster with TiFlash. However, I didn't set the TimeZone field in TiDBClusterSpec, because I thought the default value is UTC. However, TiFlash cannot start if TimeZone is not set explicitly. The error is

➜  tipocket git:(add-tiflash-crd) ✗ klo yeya24-tiflash-0 -c tiflash
Logging information to /data0/logs/server.log
Logging errors to /data0/logs/error.log
Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Exception: Could not determine time zone from TZ variable value: '': boost::filesystem::file_size: Operation not permitted: "/usr/share/zoneinfo", e.what() = Exception

If I set the TimeZone in the spec manually, then TiFlash can start correctly.

What did you expect to see?

If I didn't set the TimeZone field, TiFlash can still start normally, since it will use the default time zone UTC.

What did you see instead?

The time zone env var in TiFlash is "".
The problem is in the code below, I think we should use tc.TimeZone() instead of using tc.Spec.Timezone

		{
			Name:  "TZ",
			Value: tc.Spec.Timezone,
		},
@DanielZhangQD DanielZhangQD self-assigned this Apr 17, 2020
@DanielZhangQD
Copy link
Contributor

@yeya24 Yes, you're right! Thanks!
Please feel free to try it and feedback any issues to us.
BTW, scaling, upgrading, and failover are working in progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants