| Summary: | gss-cleanup.sh sometimes fails on fast machines | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | David Leonard <David.Leonard> | ||||
| Component: | Miscellaneous | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | CLOSED INVALID | ||||||
| Severity: | normal | CC: | dtucker | ||||
| Priority: | P2 | ||||||
| Version: | 4.7p1 | ||||||
| Hardware: | SPARC | ||||||
| OS: | Solaris | ||||||
| Bug Depends on: | 1242 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Thanks, but our regress tests don't have a gss-cleanup.sh :-) oops!! silly me.. :) well, if you ever need some gss regression tests I have some here at http://rc.quest.com/viewvc/openssh/trunk/openssh/regress/ Close resolved bugs after release. |
Created attachment 1361 [details] slow down gss-cleanup.sh It looks like the gss cred deletion code runs after the client has disconnected. Meaning, there is a race condition in regress/gss-cleanup.sh. When the first client disconnects, the second looks to see if the cleanup has finished. In the mean time, the first server process may not have completed. This appeared on some of my faster boxes, I was getting occasional failures with gss-cleanup.sh, saying that the cred cache was left behind, but I couldn't find it. Adding a 'sleep 1' seems to have helped a lot.