View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000853 | LDMud | Other | public | 2017-12-16 08:24 | 2021-04-16 19:32 |
| Reporter | manuel | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000853: Delayed write to redirected output | ||||
| Description | Output of ldmud to stderr or stdout may be delayed by several minutes if the output is not attached to a terminal but rather redirected to a file. I noticed the problem first when looking up log entries written with the efun debug_message from inside the applied master function privilege_violation. | ||||
| Steps To Reproduce | I tried combinations of ldmud 3.3-versions or 3.5.0 on current archlinux and debian-versions with different bash redirection settings, nohup and tee. The described problem occurs with every combination if the output is detached from the terminal. I may make efforts to provide a minimal setup to reproduce this, if requested. | ||||
| Additional Information | I'm ignorant on why this occurs, but reluctant to spent more time digging deeper, and just hope somebody else can either confirm it or point out my mistake. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
The behaviour is caused by the (standard) buffering of file/block I/O on linux. Once you redirect, the underlying streams are file-backed and the default behaviour is buffered (which is usually reasonable). We may think about configuring an explicit buffering mode, but the disadvantage is, that then every output will cause an IO operation on systems which redirect... However, there is a GNU coreutils tool named stdbuf which allows you to control the buffering mode of stdout, stderr and stdin (see man stdbuf). I believe, this will solve your immediate problem. Of interest may also be the signal SIGUSR2 (see master apply handle_external_signal()) for the debug log. |
|
|
Thanks, Zesstra, for the helpful hints on stdbuf and SIGUSR2. :) Still ... if you run a 32bit ldmud on a 64bit system you'd also need to replace coreutils with a 32bit version because of the libstdbuf.so ld preload. Wouldn't it be possible to check during configure for which system ldmud is built and adjust the output accordingly? |
|
|
Huh, for what characteristics do you want to check? Whether an operator redirects stdout/stderr somewhere (there are even more possibilities thas terminal and files) we can't know at compile-time. |
|
|
The standard input, output and error streams are provided by the caller (shell) and should be configured there. As there are solutions with stdbuf we don't want to add any configuration of those streams in the driver. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-12-16 08:24 | manuel | New Issue | |
| 2017-12-16 21:14 | zesstra | Note Added: 0002284 | |
| 2017-12-19 14:27 | manuel | Note Added: 0002287 | |
| 2017-12-19 22:35 | zesstra | Note Added: 0002288 | |
| 2021-04-16 19:32 | Gnomi | Status | new => closed |
| 2021-04-16 19:32 | Gnomi | Resolution | open => won't fix |
| 2021-04-16 19:32 | Gnomi | Note Added: 0002597 |
