View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004220 | unreal | ircd | public | 2013-06-07 21:57 | 2013-06-08 11:06 |
| Reporter | katsklaw | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 3.2.10.1 | ||||
| Summary | 0004220: Have timesynch disabled by default | ||||
| Description | Having timesync enabled by default is causing more problems than it's solving. I can't even agree that it's a valuable tool. I understand it's purpose and understand the importance of having time synchronized, but it seems that 95% of the time, users install Unreal and services on the same box and the 2 don't work well because they are desynchronized out-of-the-box. What's more frustrating is it's stupid easy to disable by default, change 1 character in src/s_config.c! >:( | ||||
| Steps To Reproduce | Install Unreal and ANY services package on the same box that doesn't use a time sync service then try to connect them together. | ||||
| Additional Information | Personal opinion: I'm really getting sick and tired of supporting this. I lost count long time ago of the number of times Unreal has caused this problem. A problem that wouldn't exist if timesynch was disabled by default or didn't even exist. Every time I install Unreal, I edit src/s_conf.c and disable before I compile ... *poof* problem solved. /opinion | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
No need to get angry ;p. Could you explain the problem you are having with services in more detail? I can only think of a scenario where the system has incorrect time, the IRCd discovers&adjusts to proper time, and services doesn't. |
|
|
I'm frustrated, not angry :) Your scenario is correct and it happens all too often .. sadly. It seems there are too many hosts out there than don't run ntpdate or similar and when Unreal is installed on such hosts, there is usually a large TS difference. I think the fact that it's enabled in the config parser and not the config file it's self plays into this a bit. Granted, it's in the docs, but quietly enabled in the background. I haven't offered up a patch because there is more than one way to disable. I think that we need to disable it in src/s_conf.c and then enable it in the config file with a huge *THIS MIGHT HAPPEN* style note. It's still enabled by default. If you are good with that solution, I'll gladly do the patch :) |
|
|
Ok, thanks for explaining! What surprises me is that you're the first one to mention this issue on the bug tracker ;p. Anyway, if you don't mind I'll continue this discussion in 0004214. While this is not a duplicate bug, it's so related that I feel it's better that way.. I see you already posted there too, so... As for config / defaults / etc: of course it was a conscious decision to do it this way, it's not some kind of 'mistake'. Right now, to disable timesynch you can set set::timesynch::enabled to 'no', there's no need to edit the source. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-06-07 21:57 | katsklaw | New Issue | |
| 2013-06-07 22:20 | syzop | Note Added: 0017705 | |
| 2013-06-08 00:04 | katsklaw | Note Added: 0017706 | |
| 2013-06-08 00:20 | Stealth | Relationship added | related to 0004214 |
| 2013-06-08 11:06 | syzop | Note Added: 0017708 | |
| 2013-06-08 11:06 | syzop | Status | new => closed |
| 2013-06-08 11:06 | syzop | Assigned To | => syzop |
