Reload Log Files

[MTecknology]

If it's not currently possible, could gitea re-open log files on SIGHUP? If it is possible, could somebody tell me what I'm doing wrong? At the moment, I have logrotate restarting the gitea service.

[mckaygerhard]

i have this problem too, seems gitea manages by own the log files and the OS vendor distribution cannot take care of to manage it as must be

[Perlovka]

You can use copytruncate option of logrotate.

[MTecknology]

I would consider copytruncate to be a workable hack, but the better solution would be to support re-opening log files.

@lunny This is a feature request, not a question.

[lonix1]

@MTecknology I'm also handling log rotation myself, using logrotate. (Must do so, so can feed logs into log management stack.)

The gitea container already runs s6, so log rotation would be very easy.

With s6 I would typically do:

s6-svc -1 /etc/s6/gitea/      # or -2 for SIGUSR2

Which would make s6 send signal SIGUSR1 to the app, which should force the app to release and reopen the log file (which has just been rotated).

But of course gitea doesn't currently support reopening of its log file.

Have you found a workaround in the meantime?

[MTecknology]

Have you found a workaround in the meantime?

No, I have not. In fact, I have dismissed gitea from my personal environment.

[lonix1]

@MTecknology What do you use instead? 🤔 Gitea works so well for me.

[MTecknology]

Based on my packaging efforts, the number of modules I found with various forks with security patches, etc., I decided gitea is not secure enough to be production ready. It's a project that is more about cool new features than reliability or security.

I switched to gitolite3 + cgit, which is software that cares a lot about performance, stability, and security. I also wrote a custom nginx module that uses gitolite3 ACLs for cgit access.

[lonix1]

@MTecknology Hmmm interesting points, thanks. However you know that gitolite3 has 1 major maintainer (😱), whereas here at gitea we have over 20 (🚀). Something to think about. I acknowledge though that every person's needs are unique.

Please leave the issue open if you don't mind, we still need to deal with it.

[MTecknology]

It's true that gitolite3 has one gate keeper, but he works well with others [1] and has a very solid grasp on the software. Further, gitolite has been reviewed by many security auditing firms, been given a stamp of approval, and deployed internally. If you want a true comparison to Gitea gate keepers, then you're really just talking about 3 vs. 1.

My experience with Gitea [2] is many features crammed in for the sake of cool new features with very little (or no) care to stability, license compliance, maintainability, security, or anything else I consider important. In fact... one of the "gitea owners" is where I was told that security problems get resolved when you update the software. There was absolutely no concern at all for auditing source and understanding security implications of design decisions.

[1] See other my Gitea PRs from me for why that matters...
[2] Note that I /did/ become one of those maintainers and chose to leave.

You're correct- we all have our own needs. I enjoy cool new features, but I prioritize every thing else.

I also agree this is worth leaving open because it's a legitimate problem. Since it's not a "cool new feature," I'm relatively certain it will never get resolved.

[lonix1]

Interesting and valid points, thanks.

3 vs. 1

...Sounds like a cage fight! 😆 If you don't mind, I'm betting on Gitea!

[MTecknology]

One person that accepts feedback and criticism vs. three people that prevent improvement, allow features, and communicate poorly.... You're free to pick your bet, but one of us will be paying the other. :)