Change:
return fmt.Errorf("--since must be greater than 0") } <del> if logsOptions.TailLines != nil && *logsOptions.TailLines < 0 { return fmt.Errorf("TailLines must be greater than or equal to 0") </del> <ins> if logsOptions.TailLines != nil && *logsOptions.TailLines < -1 { return fmt.Errorf("--tail must be greater than or equal to -1") </ins> } return nil

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When attempting to get all log lines using only 10 lines of logs are returned What you expected to happen: All log lines should be returned How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This was introduced in in an attempt to fix another issue where selectors would ignore tail values !=-1. I think the problem here is the logic cannot tell if the was set explicitly by the command line or is simply the initial default value. Environment: Kubernetes version (use ): 1.13.3 Cloud provider or hardware configuration: Kubeadm OS (e.g: ): 18.04.2 LTS (Bionic Beaver) Kernel (e.g. ): Linux ubuntu 4.15.0-45-generic -Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
/sig cli
Maybe is not a bug. See the kubectl help. --tail=-1: Lines of recent log file to display. Defaults to -1 with no selector, showing all log lines otherwise 10, if a selector is provided. I think i mean a selector is provided the --tail should not use -1 ?
Thanks for you reply. There are some background in below tickets, --tail=-1 is one of the option. Please check.
The help indicates that the default is 10 if the selector is used. But if someone explicitly asks for -1 it should still work, at least in my opinion.
Encountering similar behaviour to this myself. Is there any chance whatever fixes get applied can also be applied to the branch? Since that also has strange behaviour around logs with label selectors and setting .

See
This ticket has two issues: First, It's said "TailLines must be greater than or equal to 0", however we can specify -1. kubectl logs -l app=test --tail=-3 error: TailLines must be greater than or equal to 0 kubectl logs -l app=test --tail=-1 : Wed Apr 10 06:51:34 UTC 2019 : Wed Apr 10 06:51:35 UTC 2019 : Wed Apr 10 06:51:36 UTC 2019 : Wed Apr 10 06:51:37 UTC 2019 : Wed Apr 10 06:51:38 UTC 2019 : Wed Apr 10 06:51:39 UTC 2019 : Wed Apr 10 06:51:40 UTC 2019 : Wed Apr 10 06:51:41 UTC 2019 : Wed Apr 10 06:51:42 UTC 2019 : Wed Apr 10 06:51:43 UTC 2019 Second, --tail=-1 is the legacy usage which show all lines, here just return 10 lines. kubectl logs -l app=test --tail=-1 The behavior after fix: Test cases ./kubectl logs -l app=test --tail=-3 ./kubectl logs -l app=test --tail=-1 ./kubectl logs -l app=test --tail=2 ./kubectl logs -l app=test --tail=0
Interesting. I think this also causes to fail: ^-- expected record ^-- some later record (there are only 2 pods running, so is not relevant) ^-- adding makes it work
A bit strange that it finds records a few seconds older as well.. but that's not a big concern, and not relevant for this issue. vs. Although that only happens when the workaround is used: :thinking: P.S.