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

tests: Only log warnings or worse by default in smbserver #14950

Closed
wants to merge 2 commits into from

Conversation

dfandrich
Copy link
Contributor

There shouldn't be anything displayed during a normal run, but only if
server debugging is enabled. Also, set log_file to a magic value to disable
it, otherwise impacket installs its own logger that messes with what we
want.

There shouldn't be anything displayed during a normal run, but only if
server debugging is enabled. Also, set log_file to a magic value to
disable it, otherwise impacket installs its own logger that messes with
what we want.

Closes #14950
@dfandrich
Copy link
Contributor Author

Test 1451 (the SMB test) failed in the old-mingw, CM 7.3.0-x86_64 schannel U build, but I don't see how it could be related.

@bagder
Copy link
Member

bagder commented Sep 18, 2024

Several CI jobs end with Error: The action 'run tests' has timed out after 15 minutes.

Hardly related, but rather indicates the timeout is set too strict.

@vszakats
Copy link
Member

vszakats commented Sep 18, 2024

Several CI jobs end with Error: The action 'run tests' has timed out after 15 minutes.

Hardly related, but rather indicates the timeout is set too strict.

It easy to misread it as a too strict timeout, but enabling "show timestamps"
(or downloading the raw logs), makes it apparent that these are jobs that
hung/stalled/crashed and stopped producing log output well before the
job was killed by timeout.

The last log activity is always 5-10 minutes before these jobs get killed by
timeout.

This has been happening with Windows for a long time, and this Sunday it
started happening with some Linux jobs too. There was no commit that
could introduce such effect AFAICT.

(I'm assuming here that no log activity means hung/stalled/crashed job.)

edit: I had to introduces new timeouts for Linux jobs where there weren't
any to avoid them hanging around for 60-90 minutes, and then killed by
GHA itself.

@bagder
Copy link
Member

bagder commented Sep 18, 2024

Highly annoying. It also seems to happen at random places in the series of tests.

@icing
Copy link
Contributor

icing commented Sep 18, 2024

Highly annoying. It also seems to happen at random places in the series of tests.

It seems always to happen at the end. As if GH is not able to drag in the remaining output of the runtest action.

@vszakats
Copy link
Member

Very annoying. I wonder if there is any watchdog or keepalive facility (combined with ps output maybe) to trace what is happening in that interim 5-10 minutes on these machines.

@icing
Copy link
Contributor

icing commented Sep 18, 2024

Very annoying. I wonder if there is any watchdog or keepalive facility (combined with ps output maybe) to trace what is happening in that interim 5-10 minutes on these machines.

In #14944 I now try to give regular log messages when the test runner is waiting on results. See, if that gives something on these hangers.

@icing
Copy link
Contributor

icing commented Sep 18, 2024

And here we see a "hanger": https://github.com/curl/curl/actions/runs/10920448773/job/30310340171?pr=14944

Also, test 477 hangs in https://github.com/curl/curl/actions/runs/10920448773/job/30310327313?pr=14944

@vszakats
Copy link
Member

For debugging, it might sometimes help if we could connect to the runners via SSH or RDP, esp with some of the more consistent stalls that appeared in the last few days on Linux. AppVeyor CI support this, GHA runner do not, but just found that it might be possible via Tailscale: https://github.com/tailscale/github-action

It's not a "one-click" feature to implement. For starters it requires a Tailscale account. Which in turn requires an OAuth account from a 'bigtech' provider (though GitHub might work for this specific use).

@vszakats
Copy link
Member

@vszakats
Copy link
Member

vszakats commented Sep 18, 2024

Test 1451 (the SMB test) failed in the old-mingw, CM 7.3.0-x86_64 schannel U build, but I don't see how it could be related.

@dfandrich: It's unrelated. This test has been failing since enabling impacket (enabling this test). There is a little bit more about it in the PR message: #14859

@bagder
Copy link
Member

bagder commented Sep 18, 2024

The test 477 issue is fixed in master since 6d0a48e

@dfandrich dfandrich closed this in 895008d Sep 19, 2024
@dfandrich dfandrich deleted the dfandrich/smblog branch September 19, 2024 18:18
moritzbuhl pushed a commit to moritzbuhl/curl that referenced this pull request Sep 20, 2024
There shouldn't be anything displayed during a normal run, but only if
server debugging is enabled. Also, set log_file to a magic value to
disable it, otherwise impacket installs its own logger that messes with
what we want.

Closes curl#14950
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants