Issue #11

[Remerd]

Added the ability to save error.log to a file without disrupting the functionality of the rest of the program

It is recommended to save error.log in /var/lib/marznode

[khodedawsh]

Hi. so I don't generally like the idea because it would save whatever comes out of stdout(may include access log) into the error log file.
The main problem with letting xray save its log into a file is that we wouldn't know when it gets up, so why not set a timeout there instead and let xray do the job?

Thanks for the PR regardless.

[Remerd]

Hi. so I don't generally like the idea because it would save whatever comes out of stdout(may include access log) into the error log file. The main problem with letting xray save its log into a file is that we wouldn't know when it gets up, so why not set a timeout there instead and let xray do the job?

Thanks for the PR regardless.

As far as I figured out - there is no problem with saving the access log and xray itself handles it perfectly. There is a small problem with error.log, that it is necessary to send the entire stdout there and there may be some extra information (?)

[Remerd]

There are some problems with writing to the file. In case of crashes it may not be written. We must wait for a fix

Fixed

[Remerd]

save whatever comes out of stdout(may include access log) into the error log file. The main problem with letting xray save its log into a file is that we wouldn't know when it gets up

What do you think about adding a named pipe for error.log?

[khodedawsh]

What do you think about adding a named pipe for error.log?

we already have stdout and stderr.

there is no problem with saving the access log and xray itself handles it perfectly. There is a small problem with error.log

it's not convenient to manipulate xray config and copy stdout into the supposed error log file. Add an environmental variable for saving both stdout and stderr to file instead and let xray handle its log configuration itself.

[Remerd]

it's not convenient to manipulate xray config and copy stdout into the supposed error log file. Add an environmental variable for saving both stdout and stderr to file instead and let xray handle its log configuration itself.

Ok. But shouldn't marznode use logs and send them to marzneshin? Letting xray write everything to a file without going through xray_backend won't break this process?

[Remerd]

I have a solution using FIFO PIPE to output xray logs and redirect them to a file

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[khodedawsh]

it's not convenient to manipulate xray config and copy stdout into the supposed error log file. Add an environmental variable for saving both stdout and stderr to file instead and let xray handle its log configuration itself.

Ok. But shouldn't marznode use logs and send them to marzneshin? Letting xray write everything to a file without going through xray_backend won't break this process?

If the user asks xray to write its log to a file, we shouldn't interrupt the process, we'd print the log from stdout in case there is any.
However if the user configures marznode to write xray logs into a file(in addition to sending to marzneshin), that should be done. makes sense?