Well, firstly it should respond to Ctrl+C and terminate. If it doesn't, that's a separate bug and worth filing.

LogDog also has a "-timeout" flag (run `logdog -help`) that allows you to specify the maximum amount of time to wait for a new log entry before self-termination. The command would look something like:

$ logdog -timeout 5s cat <flags...>

The deeper problem is that the tool, by design, accommodates ingest latency, so there's no real distinction between:

- There are no more logs in the stream, ever.
- There are more logs, but LogDog is slow / backed up / etc. and you can't view them yet, but if you try a bit longer you will be able to.
- There will be more logs, but the producer hasn't produced them yet, and you have to wait for them.

If you want to check if the log stream exists at all, you can use the "query" command first to fetch its state. This will return a distinctive "does not exist" if the stream hasn't been registered, as well as let you know if the stream is still streaming or has terminated. "query" has a "-json" flag that emits stream status in an application-friendly JSON format.

I totally failed to see the -timeout option - that helps greatly.

I'll file a bug for Ctrl+C not working.

if Ctrl-C is a separate bug, what's left here?

Cool! FYI here's the code that's *supposed* to terminate when Ctrl+C is hit:

https://chromium.googlesource.com/infra/luci/luci-go/+/master/logdog/client/cli/main.go#200

Well let's just rename the bug then. Done.

Note that the failure to respond to Ctrl+C is seen with the windows-amd64 build. I have not tested it with any other versions. It fails to respond to Ctrl+C both when run from python and when run standalone.

BTW, I figured out why I didn't see the -timeout command' I was running "logdog help". This claims to list all of the commands, including itself, but it doesn't list the -help command. That is why I never saw -timeout. I filed bug 786176 for this. If help listed all of the commands and options then I would have found -timeout on my own.

I don't know how that code is supposed to handle Ctrl+C so I can't guess as to why it might not be working.

Explicit handling of Ctrl+C is demonstrated here:

https://cs.chromium.org/chromium/src/tools/win/IdleWakeups/idle_wakeups.cpp?l=269

In this case it was used to do an orderly shutdown with time to print summary information, but the handler could also just call TerminateProcess. I haven't written any Go code so if there's somebody else who knows how to interop from Go to Win32 that would be ideal.

This is explicit Ctrl+C handling. Ctrl+C manifests as an OS signal, and the code section that I linked in #4 installs a signal handler for those signals and responds by beginning a termination process.

C++ handles signals differently than Go, for sure.

I went pretty deep into the Go standard library until I got to this:
https://go.googlesource.com/go/+/go1.9.2/src/runtime/signal_windows.go#192
¯\_(ツ)_/¯

I'm sure this is fixable, it may be more "work".

"// Following are not implemented."

Sigh...

The Go runtime and I really don't get along well. It's a good thing the -timeout option is available (although it would still be good to have it easier to find - see bug 786176) since that makes Ctrl+C support less critical.

This thread: https://github.com/golang/go/issues/6720

says ctrl-C should still work correctly on windows.

After more looking the docs say we should be using a buffered channel to receive the signals or could miss one. It's a 3 character change but I'd need to get my dev environment set up on my home windows box to test it out, so it might take some time before I get to it.

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/luci/luci-go.git/+/24fefb7f5dc6ae4811bc0fa027a4c9e928fea40d

commit 24fefb7f5dc6ae4811bc0fa027a4c9e928fea40d
Author: Nodir Turakulov <nodir@google.com>
Date: Fri Dec 15 06:29:37 2017

[logdog] use buffered channel for signals

Bug: 786142
Change-Id: Ib5342dd4bac640c6df8294c77074e446c0787bd0
Reviewed-on: https://chromium-review.googlesource.com/826320
Reviewed-by: Erik Staab <estaab@chromium.org>
Commit-Queue: Nodir Turakulov <nodir@chromium.org>

[modify] https://crrev.com/24fefb7f5dc6ae4811bc0fa027a4c9e928fea40d/logdog/client/cli/main.go

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/infra/+/d546a30c7365c7b1838832d9a9c750a91d1d395f

commit d546a30c7365c7b1838832d9a9c750a91d1d395f
Author: Nodir Turakulov <nodir@google.com>
Date: Sat Dec 16 01:05:20 2017

Roll infra/go/src/go.chromium.org/luci/ 79172f5b4..94f3a61cb (5 commits)

https://chromium.googlesource.com/infra/luci/luci-go/+log/79172f5b4ee3..94f3a61cb309

$ git log 79172f5b4..94f3a61cb --date=short --no-merges --format='%ad %ae %s'
2017-12-14 nodir [bqschemaupdater] allow python projects to pass -proto-path flag
2017-12-14 nodir [logdog] use buffered channel for signals
2017-12-14 tandrii milo: link to the right Gerrit patch in tryjobs.
2017-12-13 smut [Machine Database] Create client which can retrieve datacenters
2017-12-12 smut [Machine Database] Ensure switches match the config

Created with:
  roll-dep infra/go/src/go.chromium.org/luci

Bug: 786142
Change-Id: I0d588606fdc51eea8e0b6e7bc7f5bf08cf86c386
Reviewed-on: https://chromium-review.googlesource.com/828502
Reviewed-by: Erik Staab <estaab@chromium.org>
Commit-Queue: Nodir Turakulov <nodir@chromium.org>

[modify] https://crrev.com/d546a30c7365c7b1838832d9a9c750a91d1d395f/DEPS

latest version of logdog uses a buffered channel for signals. I don't see how it may help for this problem, but please give it a try. Where is your logdog binary is coming from? Did you compile it yourself?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot