Consider an alterantive solution for logging to file when running as Windows service

[shadowsocks69420]

When running as a Windows service, stdout is generally inaccessible. Currently, file logging relies on log4rs, which warns that it will be deprecated and removed. Please consider providing an alternative solution for file-based logging on Windows or guidance for users running the service on Windows.

It's acceptable to only make the sswinservice binary log to a file.

Side note: The log4rs example in README.md should be removed if log4rs support is going away, to minimize impact from future breakage.

[zonyitoo]

Is it Ok to just redirect outputs to one file?

[shadowsocks69420]

Is it Ok to just redirect outputs to one file?

AFAIK, that is not possible for Windows services. Even if it is possible, it lacks other crucial file logging utilities like log rotation, retention, etc.

[zonyitoo]

https://docs.rs/tracing-appender/0.2.3/tracing_appender/rolling/struct.RollingFileAppender.html

It is nice that tracing have already provided a library to write output to rolling files.

[shadowsocks69420]

https://docs.rs/tracing-appender/0.2.3/tracing_appender/rolling/struct.RollingFileAppender.html

It is nice that tracing have already provided a library to write output to rolling files.

tracing-appender would definitely help. However, it doesn't support configuration from environment variables like tracing_subscriber. What do you think is the best way to let the user configure it?

[zonyitoo]

The appender created from tracing-appender would be set as a Writer of tracing-subscriber.

[shadowsocks69420]

The appender created from tracing-appender would be set as a Writer of tracing-subscriber.

The question was how are we going to expose the configuration options to the end user, e.g.: by changing/breaking the log.* section of the config.json file? As tracing-appender doesn't have runtime external configuring support built-in.

[zonyitoo]

Yes. Users could set options in the log object.

[shadowsocks69420]

Yes. Users could set options in the log object.

Gotcha. I will try to come up with a PR for this.

[zonyitoo]

The log object could be extended with keys like layer, formatter, appender … which could allow us to add more other new configurable features supported by tracing.

[shadowsocks69420]

The log object could be extended with keys like layer, formatter, appender … which could allow us to add more other new configurable features supported by tracing.

I don't see how this can be implemented with reasonable effort due to SubscriberBuilder has very complex generic. Feel free to advise if you have design ideas.

I opened a PR #1992 that adds support for tracing-appender. My focus was to make the configuration reasonable and straightforward to the user while also leave plenty of possibilities for future extension.

[zonyitoo]

Current implementation in #1992 adds a file key for creating a new writer from tracing-appender. But what if users wants multiple different writers, for example, syslog writer, netlog writer, ...

How about this:

{
    "log": {
        "writers": [
            {
                "rolling_file": {
                    // Directory to store log files. If not set, it will not log to file
                    "directory": "/var/log/shadowsocks-rust",
                    // Log rotation frequency, must be one of the following:
                    // - never (default): This will result in log file located at `directory/prefix.suffix`
                    // - daily: A new log file in the format of `directory/prefix.yyyy-MM-dd.suffix` will be created daily
                    // - hourly: A new log file in the format of `directory/prefix.yyyy-MM-dd-HH.suffix` will be created hourly
                    "rotation": "never",
                    // Prefix of log file, default is one of `sslocal`, `ssserver`, `ssmanager` depending on the service being run.
                    "prefix": "shadowsocks-rust",
                    // Suffix of log file, default is `log`
                    "suffix": "log",
                    // Keeps the last N log files. If not set, no limit will be applied.
                    "max_files": 5
                }
            }
        ]
    }
}

[shadowsocks69420]

That's a bit challenging and may take me some time to implement.

I'm thinking maybe we can settle on what we have now and support both in a non-breaking way in the future in case someone asks for it? Just like top-level local vs locals array.

{
    "log": {
        "writers": [
            {
                "level": 1,
                "format": {
                  "without_time": false
                },
                "file": {
                    // Directory to store log files. If not set, it will not log to file
                    "directory": "/var/log/shadowsocks-rust",
                    // Log rotation frequency, must be one of the following:
                    // - never (default): This will result in log file located at `directory/prefix.suffix`
                    // - daily: A new log file in the format of `directory/prefix.yyyy-MM-dd.suffix` will be created daily
                    // - hourly: A new log file in the format of `directory/prefix.yyyy-MM-dd-HH.suffix` will be created hourly
                    "rotation": "never",
                    // Prefix of log file, default is one of `sslocal`, `ssserver`, `ssmanager` depending on the service being run.
                    "prefix": "shadowsocks-rust",
                    // Suffix of log file, default is `log`
                    "suffix": "log",
                    // Keeps the last N log files. If not set, no limit will be applied.
                    "max_files": 5
                }
            }
        ]
    }
}

Let me know if you insist on only supporting the array option.
Opened #1993

[robot-dot-win]

Currently my implementation: log.yaml

[shadowsocks69420]

Closed via #1993