View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001334 | unreal | ircd | public | 2003-11-02 17:29 | 2003-11-03 01:28 |
| Reporter | cyberCloWn | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | random |
| Status | closed | Resolution | open | ||
| Product Version | 3.2-beta18 | ||||
| Summary | 0001334: Funky lag thing | ||||
| Description | This is an abstract bug report. There is nothing in my logs and no steps that I noticed that produced this. All I can tell you is that people were chatting, but other clients (on one server network) wouldn't recieve the privmsgs. You couldn't interact with the server. When I reconnected I whoised a few people and got weird results, and yes, everything was fine when I reconnected. I could interact again, but the others were still 'frozen'. I'm not sure if this has anything to do with the /stats port bug I posted the other day. The only thing I can think of that caused this, was that I told a guy to setup ntp on the ircd's host and he said he synched the times. When I whoised people I got the following response: Lyle has been idle 1193034hrs 41mins 52secs Which is totally incorrect. | ||||
| 3rd party modules | |||||
|
|
changing the time drastically can indeed f*ck things up. A bit strange then however that you were still able to execute commands like /whois. |
|
|
There's also unfortunately nothing we can do about this. To give you an idea.. if you have even just 100 users there are probably ~400 - 0001052:0003000 timestamps stored in memory, it would be almost impossible to change all these just because of a timechange. Moral of the story is: keep your clock strictly synced. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-11-02 17:29 | cyberCloWn | New Issue | |
| 2003-11-02 20:24 | syzop | Note Added: 0003931 | |
| 2003-11-03 01:28 | syzop | Status | new => closed |
| 2003-11-03 01:28 | syzop | Note Added: 0003942 |
