Reload Log Files #609

New Issue

GiteaMirror · 2025-11-02T03:29:51-06:00

GiteaMirror commented

2025-11-02 03:29:51 -06:00

Originally created by @MTecknology on GitHub (Apr 4, 2017).

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.

Originally created by @MTecknology on GitHub (Apr 4, 2017). 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.

GiteaMirror added the type/feature type/proposal labels 2025-11-02 03:29:51 -06:00

GiteaMirror closed this issue

2025-11-02 03:29:51 -06:00

GiteaMirror commented

2025-11-02 03:29:52 -06:00

@mckaygerhard commented on GitHub (Sep 20, 2017):

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

@mckaygerhard commented on GitHub (Sep 20, 2017): 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

GiteaMirror commented

2025-11-02 03:29:52 -06:00

@Perlovka commented on GitHub (Dec 11, 2017):

You can use copytruncate option of logrotate.

@Perlovka commented on GitHub (Dec 11, 2017): You can use **copytruncate** option of logrotate.

GiteaMirror commented

2025-11-02 03:29:52 -06:00

@MTecknology commented on GitHub (Dec 13, 2017):

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.

@MTecknology commented on GitHub (Dec 13, 2017): 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.

GiteaMirror commented

2025-11-02 03:29:52 -06:00

@lonix1 commented on GitHub (May 19, 2020):

@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?

@lonix1 commented on GitHub (May 19, 2020): @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?

GiteaMirror commented

2025-11-02 03:29:52 -06:00

@MTecknology commented on GitHub (May 25, 2020):

Have you found a workaround in the meantime?

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

@MTecknology commented on GitHub (May 25, 2020): > Have you found a workaround in the meantime? No, I have not. In fact, I have dismissed gitea from my personal environment.

GiteaMirror commented

2025-11-02 03:29:53 -06:00

@lonix1 commented on GitHub (May 26, 2020):

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

@lonix1 commented on GitHub (May 26, 2020): @MTecknology What do you use instead? 🤔 Gitea works so well for me.

GiteaMirror commented

2025-11-02 03:29:53 -06:00

@MTecknology commented on GitHub (May 26, 2020):

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.

@MTecknology commented on GitHub (May 26, 2020): 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.

GiteaMirror commented

2025-11-02 03:29:53 -06:00

@lonix1 commented on GitHub (May 26, 2020):

@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.

@lonix1 commented on GitHub (May 26, 2020): @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.

GiteaMirror commented

2025-11-02 03:29:53 -06:00

@MTecknology commented on GitHub (May 30, 2020):

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.

@MTecknology commented on GitHub (May 30, 2020): 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.

GiteaMirror commented

2025-11-02 03:29:53 -06:00

@lonix1 commented on GitHub (May 31, 2020):

Interesting and valid points, thanks.

3 vs. 1

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

@lonix1 commented on GitHub (May 31, 2020): Interesting and valid points, thanks. > 3 vs. 1 ...Sounds like a cage fight! 😆 If you don't mind, I'm betting on Gitea!

GiteaMirror commented

2025-11-02 03:29:54 -06:00

@MTecknology commented on GitHub (May 31, 2020):

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. :)

@MTecknology commented on GitHub (May 31, 2020): 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. :)

GiteaMirror referenced this issue

2025-11-02 11:47:40 -06:00

[PR #609] [MERGED] Add myself to MAINTAINERS #15487

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#609