tail: fix issue #6543 (--pid when reading from stdin) #6582
Conversation
…fied to match GNU behavior and fix issue uutils#6543
|
GNU testsuite comparison: |
|
After looking a bit, I don't think there's enough inspection into internal stuff to see if it's saved as a file or stdin, without changing more things in tail. So I can add a TODO in the tail test file to add in a test to check But I removed the comment, because it was just straight-up incorrect (brain fart on my end), and added a test to check tail doesn't exit automatically when |
tests/by-util/test_tail.rs
Outdated
| Command::new("kill") | ||
| .arg("-9") | ||
| .arg(sleep_pid.to_string()) | ||
| .output() | ||
| .expect("failed to kill sleep command"); | ||
|
|
There was a problem hiding this comment.
After killing sleep, we have a perfect opportunity to quickly check that tail really does terminate by itself. Maybe insert something like this?
child.make_assertion_with_delay(1000).is_alive();
There was a problem hiding this comment.
Hey, for checking if it's is_alive, why not is_not_alive. Running the commands manually, I confirm that the tail exits after sleep exits, and after it's killed. But, I changed it to is_not_alive, and it failed on Linux. Although it passed on Windows. I need to switch back over to Windows and confirm it's breaking now
There was a problem hiding this comment.
To answer my previous question, I believe it should be is_not_alive, and the cause for failure was because sleep's parent was the Rust test program, and without exiting, and without reaping, it became a zombie. However, the libc kill function in is_dead saw it as still alive (returning 0), and the reason the program exited before was because of recv_timeout(settings.sleep_sec) in watch.rs (currently line 532 in this commit), which I assume errored out, leading to the program ending, and leading to the appearance that it detected the pid specified dying and following suite, when it wasn't actually the case.
|
Just add those things. Didn't even cross my mind to test it died afterwards, but that's a good idea. And yeah, it was redundant to have a 2nd wait. |
|
Aaand there's a formatting error :D |
|
GNU testsuite comparison: |
tests/by-util/test_tail.rs
Outdated
| .output() | ||
| .expect("failed to kill sleep command"); | ||
|
|
||
| child.make_assertion_with_delay(100).is_alive(); |
There was a problem hiding this comment.
0.1 seconds is a bit very short. Again, some CI runners are really slow, that's why I'm worried that this would result in a flaky test (we already have too many of them). Maybe increase it to 1 second, i.e. 1000 milliseconds?
There was a problem hiding this comment.
Alright. I'll go ahead and do that, then push. I'm usually of the mindset of trying to make sure any one test doesn't take too long, because it begins to add up over a large test suite. But I'd hate to make a weak or flaky test
|
GNU testsuite comparison: |
…fied to match GNU behavior and fix issue uutils#6543
|
some windows jobs are failing :) |
|
Alright. I'll go ahead and set up a dev environment on windows and get it working, even if that's just a conditional compilation. I'll try to push tomorrow |
BenWiederhake
changed the title
…null() to make it more friendly for windows
|
GNU testsuite comparison: |
…therwise sleep process isn't fully dead
|
Why is macos " |
|
My apologies, I missed the notification and didn't see this last week. |
|
GNU testsuite comparison: |
| @@ -4824,3 +4825,61 @@ fn test_obsolete_encoding_windows() { | |||
| .stderr_is("tail: bad argument encoding: '-�b'\n") | |||
| .code_is(1); | |||
| } | |||
|
|
|||
| #[test] | |||
| #[cfg(not(target_vendor = "apple"))] // FIXME: for currently not working platforms | |||
There was a problem hiding this comment.
please add details why it isn't working on other os
There was a problem hiding this comment.
Hey, I'm sorry I didn't answer for over a month. I remember seeing your message shortly after you wrote it, but I don't remember after that, if I got busy or what. I had thought I had written something for it, but I guess not.
I think I had known at one point, but I don't have an Apple device to test on, and so currently I don't actually know.
I'll reach out to a friend with one and see if they can figure it out or not, and try to update this thread or the code accordingly.
|
GNU testsuite comparison: |
Fixed tail to follow stdin when a PID is specified to match GNU behavior
All test pass, and manually confirmed the issues raised in #6543 were fixed