Graceful restarts & multiprocess logging #11

New Issue

zeripath · 2019-06-18T05:08:12Z

zeripath commented

2019-06-18 05:08:12 +00:00

When using log in a graceful restarting or multiprocess situation we will potentially suffer log corruption due to multiple processes logging to the same file at the same time.

To ameliorate this we should either:

Provide an option to stick the pid in the filename.
- It is possible to arrange for this to be done automatically - e.g. through a simple lock file.
- Another option is to provide a mechanism to tell the logger to switch to adding a pid - e.g. a hook at the time of graceful restarting adjusts configuration.
Provide a mutex locking mechanism e.g. https://github.com/juju/mutex
- This can lead to slowdowns in logging - and there's no way of ensuring that a log file is definitely monotonic without a monitoring service. However, it does ensure a single log file.
Another option is to provide some switching mechanism whereby logs can be simply forwarded over a pipe but this is complex.

I think sticking a pid in the filename is likely to be easiest - with the simplistic lock and the handoff being good additions.

When using log in a graceful restarting or multiprocess situation we will potentially suffer log corruption due to multiple processes logging to the same file at the same time. To ameliorate this we should either: * Provide an option to stick the pid in the filename. * It is possible to arrange for this to be done automatically - e.g. through a simple lock file. * Another option is to provide a mechanism to tell the logger to switch to adding a pid - e.g. a hook at the time of graceful restarting adjusts configuration. * Provide a mutex locking mechanism e.g. https://github.com/juju/mutex * This can lead to slowdowns in logging - and there's no way of ensuring that a log file is definitely monotonic without a monitoring service. However, it does ensure a single log file. * Another option is to provide some switching mechanism whereby logs can be simply forwarded over a pipe but this is complex. I think sticking a pid in the filename is likely to be easiest - with the simplistic lock and the handoff being good additions.

lunny commented

2019-06-18 05:21:50 +00:00

Another possible method is to post log via http to server to resolve the multiprocess problem.

lunny added the

kind/proposal

label 2019-06-18 05:26:07 +00:00

zeripath commented

2019-06-18 19:47:53 +00:00

I think that's probably a good provider that we should have, but it's just pushing the problem to another place - which then suffers the same problem.

lunny commented

2019-06-19 01:22:50 +00:00

@zeripath I don't think so. After that, we will resolve multiple process write problem. gitea serv and gitea hooks will run when every push or pull request via SSH. But gitea web always runs once for all the requests. It's not the same problem. I would not like gitea serv and gitea hooks to send log to a remote provider directly but send to gitea web via internal http request.

@zeripath I don't think so. After that, we will resolve multiple process write problem. `gitea serv` and `gitea hooks` will run when every push or pull request via SSH. But `gitea web` always runs once for all the requests. It's not the same problem. I would not like `gitea serv` and `gitea hooks` to send log to a remote provider directly but send to `gitea web` via `internal` http request.

This repo is archived. You cannot comment on issues.

No Milestone

No Assignees

2 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/log#11