View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002986 | unreal | ircd | public | 2006-07-02 01:04 | 2013-05-14 10:52 |
| Reporter | vonitsanet | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Platform | ALL | OS | ALL | OS Version | ALL |
| Product Version | 3.2.5 | ||||
| Summary | 0002986: TSCTL notice | ||||
| Description | I think that these notices should be send to the junk snomask: *** Notice -- TS Control - U:line set time to be 1234567890 (timediff: 0) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Why are they even sent for a 0 adjustment? |
|
|
Probably b/c it means that a U:line did an adjustment ? true that a zero adjustment is meaningless (hell, so is a +/-2sec offset), but it's still an informational message. I just hope that the ntp code fixes all of those problems. Anybody know if it's in CVS yet? as long as it was stable, it'd be something worth upgrading to, at least on some leaves. |
|
|
Nice timestamp ;) . If anything, maybe they should be sent to junk for abs(timediff) < 20 or 30, but anything above that is sent to whatever it's being sent to currently (with a warning (similar to the TS split notice one) that either your server or the svstimer has a really buggered up system clock)). |
|
|
Bump. Still an issue? |
|
|
I think it should be left as is; stuff as critical as a ts change isn't necessarily "junk" imo. And really, how often are your u:line's setting that? Anything more often than once a day is probably overkill really. If your clocks can't stay synced for 24 hours... then those server's should be delinked. And messing with some sort of timediff thing, would be really obnoxious. I would rather see it ALWAYS in the junk notice, than be a junk notice if less than 20 second difference. Also the "timediff" field, if I'm not mistaken is only the difference between the system time() and what the U:Line just set. It has no bearing on what the old tstime was. So maybe timediff: 0; could have been set when before the clock was 60 seconds off (between time() and tstime()) |
|
|
Given that it's possible to remote crash a server using both the offset and svstime variants of tsctl (by specifying a timestamp near the maximum), these messages should be highly visible. |
|
|
Agreed, we will not change this. Falcon, can you look and see if my new eventloop code is still vulnerable to this? I want to solve the underlying problem. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-07-02 01:04 | vonitsanet | New Issue | |
| 2006-07-03 17:58 | w00t | Note Added: 0012038 | |
| 2006-07-04 21:45 | tabrisnet | Note Added: 0012053 | |
| 2006-07-06 22:30 | aquanight | Note Added: 0012058 | |
| 2007-04-27 03:10 |
|
Note Added: 0013767 | |
| 2007-04-27 03:10 |
|
Status | new => feedback |
| 2010-04-15 09:28 | driew | Note Added: 0016069 | |
| 2013-05-14 10:47 | falconkirtaran | Note Added: 0017563 | |
| 2013-05-14 10:52 |
|
Note Added: 0017564 | |
| 2013-05-14 10:52 |
|
Status | feedback => resolved |
| 2013-05-14 10:52 |
|
Resolution | open => no change required |
| 2013-05-14 10:52 |
|
Assigned To | => nenolod |
