fix(cube-master): panic if http server fails to start by yyyang91 · Pull Request #127 · TencentCloud/CubeSandbox

yyyang91 · 2026-04-30T06:36:37Z

Fix the conditional logic for port availability detection.
Add explicit success logs to print the listening address upon startup.
Add detailed error logs when the HTTP server fails to start.
Enhance service observability for better troubleshooting.

chenhengqi · 2026-04-30T07:45:49Z

What's the purpose of this change?

yyyang91 · 2026-04-30T11:50:17Z

What's the purpose of this change?

This modification mainly addresses the following issues.

When the port used by the cubemaster service is occupied, cubemaster does not correctly print error logs. It is difficult to quickly identify the problem based on the logs. Even when it starts successfully, there is no success log similar to that of the cube API.

chenhengqi · 2026-05-06T02:17:26Z

+		addr = ":http"
+	}
+
+	ln, err := net.Listen("tcp", addr)


Does this change work with cubemastercli?

This logic is ported from the Go standard library (net/http/server.go, v1.24.8).

I migrated the original implementation here to gain more granular control over the startup sequence. Specifically, it allows us to inject the startup/failure logs and port check logic directly into the serving loop, which addresses the observability requirements for cube-master.

You did not answer my question.

Yes, it works

chenhengqi · 2026-05-06T02:17:38Z

+
+	actualAddr := ln.Addr().String()
+	CubeLog.Infof("cube-master listening on on %s", actualAddr)
+	stdlog.Printf("cube-master listening on on %s", actualAddr)


Why do we need a stdlog?

This is because:

CubeLog.Infof only writes logs to a specific business log file /data/log/CubeMaster/cubemaster-req.log

start_with_pidfile fucniton just redirect stdout/stderr to /var/log/cube-sandbox-one-click/cubemaster.log, we cannot find errors in /var/log/cube-sandbox-one-click/cubemaster.log

Only the logs under /data/log/CubeMaster/meet the requirements.

But, the installation logs directed me to the /var/log/cube-sandbox-one-click directory to check for errors, You can view the screenshot. #127 (comment)

Do you mean just keep stdlog when the server start error? If the server start successfully, just logs to /data/log/CubeMaster/

How about panic when the requested port is in use?

I also think a panic is more clearer. I didn't use it because I'm not sure about the project's policy on panicking. Additionally, I found out that CubeLog.Fatal doesn't exit the program.

How about panic when the requested port is in use?

I think the root cause of the current issue is likely that CubeLog.Errorf does not trigger a panic or exit the program.😅

@fslongjin PTAL.

- Fix the conditional logic for port availability detection. - Add explicit success logs to print the listening address upon startup. - Add detailed error logs when the HTTP server fails to start. - Enhance service observability for better troubleshooting.

chenhengqi · 2026-05-07T01:53:58Z

+		addr = ":http"
+	}
+
+	ln, err := net.Listen("tcp", addr)


If the real issue is that the requested port is in use, we can simply panic here.

It seems that a panic only terminates the program, while a non-panic means the process is still running. To speed up troubleshooting, it's necessary to have logs indicating whether the service started successfully. Should we write success and error messages to `/var/log/cube-sandbox-one-click/cubemaster.log? This is because when the installation script encounters an error, it prompts us to check the files in the directory.

Panic will log to stderr and should be captured, no?

Panic will log to stderr and can be captured. but it will print the stack. Is it ok to print the stack?

…ilure logs" This reverts commit 9e7ebd3.

yyyang91 · 2026-05-08T08:54:52Z

I revert the preious commit, and add a commit just panic.

fslongjin · 2026-05-08T13:50:48Z

I believe a better solution here would be to introduce a synchronization point before the startup completes. If an issue is detected, trigger a graceful shutdown instead of panicking outright. We should already have a graceful exit mechanism in place. @yyyang91

yyyang91 · 2026-05-09T01:13:22Z

I believe a better solution here would be to introduce a synchronization point before the startup completes. If an issue is detected, trigger a graceful shutdown instead of panicking outright. We should already have a graceful exit mechanism in place. @yyyang91

On the master branch, when serverTmp.Run() occur errors would not triger a graceful exit mechanism.

CubeSandbox/CubeMaster/cmd/cubemaster/app/main.go

Lines 112 to 114 in 09101b2

    
           recov.GoWithRecover(func() { 
        
           	serverTmp.Run() 
        
           })

I revert the commit that can tigger graceful exit yesterday.

yyyang91 · 2026-05-13T13:08:43Z

When the port is already in use, cube-master hangs silently instead of exiting. The graceful shutdown mechanism is not triggered, so the process just sits there. At the same time, no error is written to /var/log/cube-sandbox-one-click/cubemaster.log — the directory the installation script points you to when something goes wrong.
So when the install fails and the ops team follows the script's prompt to check logs, there is no trace of the startup failure anywhere.

What is the project's expected behavior here? CubeLog alone cannot emit errors to the path the installation script expects, so should the process exit immediately, trigger a graceful shutdown, or is there another mechanism to make startup failures visible in the installation script's diagnostic directory?

@chenhengqi @fslongjin
Please confirm the direction and I'll implement accordingly.

chenhengqi

I am OK with this change.

yyyang91 requested review from chenhengqi, fslongjin, ls-ggg, tinklone and up2wing as code owners April 30, 2026 06:36

chenhengqi reviewed May 6, 2026

View reviewed changes

ls-ggg assigned fslongjin May 6, 2026

yyyang91 force-pushed the fix-cubemaster-port-check branch from 83c5952 to 9e7ebd3 Compare May 6, 2026 04:14

chenhengqi requested changes May 7, 2026

View reviewed changes

yyyang91 requested a review from chenhengqi May 7, 2026 03:13

yyyang91 added 2 commits May 7, 2026 12:47

Revert "fix(cube-master): improve port check logic and add startup/fa…

fa84318

…ilure logs" This reverts commit 9e7ebd3.

fix(cube-master): panic if http server fails to start

7e241e0

yyyang91 changed the title ~~fix(cube-master): improve port check logic and add startup/failure logs~~ fix(cube-master): panic if http server fails to start May 8, 2026

chenhengqi approved these changes May 14, 2026

View reviewed changes

Conversation

yyyang91 commented Apr 30, 2026

Uh oh!

chenhengqi commented Apr 30, 2026

Uh oh!

yyyang91 commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yyyang91 May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yyyang91 commented May 8, 2026

Uh oh!

fslongjin commented May 8, 2026

Uh oh!

yyyang91 commented May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yyyang91 commented May 13, 2026

Uh oh!

chenhengqi left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

yyyang91 commented Apr 30, 2026 •

edited

Loading

yyyang91 May 7, 2026 •

edited

Loading

yyyang91 commented May 9, 2026 •

edited

Loading