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

[Feature Request] Provide easy way to hide output #66

Open
lorensr opened this issue Dec 31, 2022 · 4 comments
Open

[Feature Request] Provide easy way to hide output #66

lorensr opened this issue Dec 31, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@lorensr
Copy link
Contributor

lorensr commented Dec 31, 2022

Is your feature request related to a problem? Please describe.

In order to be able to continue using my terminal, I have to add > /dev/null 2>&1 & like:

temporal server start-dev > /dev/null 2>&1 &

Describe the solution you'd like

temporal server start-dev -d

like docker-compose's -d flag:

  -d, --detach                    Detached mode: Run containers in the background

A Mac-only alternative solution is #10

Additional context

Previous discussion: temporalio/temporalite-archived#139

@lorensr lorensr added the enhancement New feature or request label Dec 31, 2022
@lorensr
Copy link
Contributor Author

lorensr commented Jan 3, 2023

Another option: hide stdout unless they pass -v / --verbose or --debug

@lorensr lorensr changed the title [Feature Request] Provide easy way to send to background and hide output [Feature Request] Provide easy way to send hide output Jan 3, 2023
@lorensr lorensr changed the title [Feature Request] Provide easy way to send hide output [Feature Request] Provide easy way to hide output Jan 3, 2023
@bergundy
Copy link
Member

bergundy commented Jan 4, 2023

I don't think we need a detached mode, users can run the command in the background if they intend on running it the way you do.
For complete daemonization support, we'd need PID files, a way to get the status of the "current" running server, a command to stop the server, etc..
I don't see a huge benefit in this when it's easy enough to run the server with:

temporal server start-dev &> /dev/null & disown

With docker you don't really have a choice but to provide a -d flag but for a standard applications that runs on the developer's machine there's far less value for built-in daemonization.

Another option: hide stdout unless they pass -v / --verbose or --debug

There's already a configurable log level, we should make sure the log levels are tuned and possibly default to warn.

@lorensr
Copy link
Contributor Author

lorensr commented Mar 24, 2023

Roey requested I don't tell people to do:

temporal server start-dev &> /dev/null & disown

So I'm back onto improving the default output experience ☺️

@feedmeapples would it be easy to:

  1. change default log level to warn
  2. hide Starting UI server... and Echo output, including ⇨ http server started on 127.0.0.1:8233
  3. add this output:
> dist/temporal server start-dev
🆙
Temporal Server is running at: localhost:7233
Web UI is running at: http://localhost:8233

(would also be nice if localhost:7233 and http://localhost:8233 were green)

current output

> dist/temporal server start-dev
{"level":"info","ts":"2023-03-24T16:05:53.195-0400","msg":"Successfully saved cluster metadata.","component":"metadata-initializer","cluster-name":"active","logging-call-at":"fx.go:700"}
{"level":"info","ts":"2023-03-24T16:05:53.196-0400","msg":"Use rpc address 127.0.0.1:7233 for cluster active.","component":"metadata-initializer","logging-call-at":"fx.go:840"}
{"level":"info","ts":"2023-03-24T16:05:53.220-0400","msg":"Created gRPC listener","service":"history","address":"127.0.0.1:49609","logging-call-at":"rpc.go:152"}
{"level":"info","ts":"2023-03-24T16:05:53.223-0400","msg":"Created gRPC listener","service":"matching","address":"127.0.0.1:49611","logging-call-at":"rpc.go:152"}
{"level":"info","ts":"2023-03-24T16:05:53.228-0400","msg":"Created gRPC listener","service":"frontend","address":"127.0.0.1:7233","logging-call-at":"rpc.go:152"}
{"level":"info","ts":"2023-03-24T16:05:53.228-0400","msg":"Service is not requested, skipping initialization.","service":"internal-frontend","logging-call-at":"fx.go:473"}
Starting UI server...
{"level":"info","ts":"2023-03-24T16:05:53.232-0400","msg":"Starting server for services","value":{"frontend":{},"history":{},"matching":{},"worker":{}},"logging-call-at":"server_impl.go:97"}
{"level":"info","ts":"2023-03-24T16:05:53.232-0400","msg":"PProf listen on ","port":49607,"logging-call-at":"pprof.go:73"}

   ____    __
  / __/___/ /  ___
 / _// __/ _ \/ _ \
/___/\__/_//_/\___/ v4.9.0
High performance, minimalist Go web framework
https://echo.labstack.com
____________________________________O/_______
                                    O\
⇨ http server started on 127.0.0.1:8233
{"level":"info","ts":"2023-03-24T16:05:53.236-0400","msg":"Membership heartbeat upserted successfully","service":"history","address":"127.0.0.1","port":49610,"hostId":"47c4c31a-ca7f-11ed-9846-fe34e8f69a25","logging-call-at":"rpMonitor.go:255"}
{"level":"info","ts":"2023-03-24T16:05:53.236-0400","msg":"RuntimeMetricsReporter started","service":"matching","logging-call-at":"runtime.go:138"}
{"level":"info","ts":"2023-03-24T16:05:53.237-0400","msg":"RuntimeMetricsReporter started","service":"frontend","logging-call-at":"runtime.go:138"}
{"level":"info","ts":"2023-03-24T16:05:53.236-0400","msg":"RuntimeMetricsReporter started","service":"worker","logging-call-at":"runtime.go:138"}
{"level":"info","ts":"2023-03-24T16:05:53.237-0400","msg":"bootstrap hosts fetched","service":"history","bootstrap-hostports":"127.0.0.1:49610","logging-call-at":"rpMonitor.go:297"}
{"level":"info","ts":"2023-03-24T16:05:53.237-0400","msg":"Membership heartbeat upserted successfully","service":"matching","address":"127.0.0.1","port":49612,"hostId":"47c6f9b4-ca7f-11ed-9846-fe34e8f69a25","logging-call-at":"rpMonitor.go:255"}
...

@dandavison
Copy link
Contributor

My vote is also not to have a -d flag when standard shell techniques can be used instead.

I don't see a huge benefit in this when it's easy enough to run the server with:
temporal server start-dev &> /dev/null & disown

Expert users can probably choose their own preferred style of redirection. For less expert users, I'd recommend simply telling them to run the server in a different terminal window/tab rather than giving them slightly esoteric shell commands.

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

No branches or pull requests

4 participants