| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
It turns out the boot time being returned to btimec is has not been
correct for quite a while. There was probably a change to HZ which
isn't reflected properly in _SC_CLK_TCK. This needs some more error
checking, but it works for now.
|
| |
|
|
|
|
| |
don't need to round so much.
|
|
|
|
|
|
|
|
| |
qarsh is the primary user of btimed, but it only sends a btime request
when it hasn't received output for 5 seconds. If output is streaming for
more than 30 seconds, btimed would exit. When the output quiets down again
and btimed starts up, it could get a slightly different uptime and round
in the opposite direction.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Two factors forced this change.
1. ports were being re-used so quickly that we could get lingering
packets from past hosts when getting the btime for a new host.
2. We can't control which IP a btime response is sent from if a system
has more than one interface. Adding a cookie allows us to know that
a response came from whom we sent it.
|
| |
|
|
|
|
| |
requests so no need to retry in server
|
|
|
|
|
|
| |
in 30 seconds.
Fix the servce name in the btimed xinetd config file
|
| |
|
|
|