Configuring time.FORMAT breaks ssh #653

New Issue

GiteaMirror · 2025-11-02T03:31:55-06:00

GiteaMirror commented

2025-11-02 03:31:55 -06:00

Originally created by @mnsh on GitHub (Apr 20, 2017).

Gitea version (or commit ref): a2d365c8
Git version: 2.11.0
Operating system: CentOS-6.9
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Lately SSH access to a gitea instance of ours tracking the master branch has been broken. Doing a clone or pull over ssh simply hangs, with gitea serv key-X --conf=... blocking on waitid(...) and it's spawned git-upload-pack org/repo.git blocking on read(0, ...).

After a little digging, I tried running the expected gitea serv ... command as the gitea user:

$ SSH_ORIGINAL_COMMAND="git-upload-pack '/org/test.git'" /usr/local/bin/gitea serv key-1 --config=/path/to/conf/app.ini
2017/04/20 03:45:15 [T] Custom TimeFormat: 2006-01-02 15:04:05 CET
00f263b78e06ee70f741ce1360f5c6c2e15a09df4d3e HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2.11.0
003f63b78e06ee70f741ce1360f5c6c2e15a09df4d3e refs/heads/master
0000

The first line in the output is causing the problem - it's written to stdout, which git expects to "own".

Commenting out [time] -> FORMAT in the configuration or commenting out the log.Trace("...")-call in modules/setting/setting.go restores SSH access to gitea.

Originally created by @mnsh on GitHub (Apr 20, 2017). - Gitea version (or commit ref): a2d365c8 - Git version: 2.11.0 - Operating system: CentOS-6.9 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description Lately SSH access to a gitea instance of ours tracking the master branch has been broken. Doing a clone or pull over ssh simply hangs, with `gitea serv key-X --conf=...` blocking on `waitid(...)` and it's spawned `git-upload-pack org/repo.git` blocking on `read(0, ...)`. After a little digging, I tried running the expected `gitea serv ...` command as the gitea user: ``` $ SSH_ORIGINAL_COMMAND="git-upload-pack '/org/test.git'" /usr/local/bin/gitea serv key-1 --config=/path/to/conf/app.ini 2017/04/20 03:45:15 [T] Custom TimeFormat: 2006-01-02 15:04:05 CET 00f263b78e06ee70f741ce1360f5c6c2e15a09df4d3e HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2.11.0 003f63b78e06ee70f741ce1360f5c6c2e15a09df4d3e refs/heads/master 0000 ``` The first line in the output is causing the problem - it's written to stdout, which git expects to "own". Commenting out `[time]` -> `FORMAT` in the configuration or commenting out the `log.Trace("...")`-call in `modules/setting/setting.go` restores SSH access to gitea.

GiteaMirror added the issue/needs-feedback type/bug labels 2025-11-02 03:31:55 -06:00

GiteaMirror closed this issue

2025-11-02 03:31:56 -06:00

GiteaMirror commented

2025-11-02 03:31:56 -06:00

@stale[bot] commented on GitHub (Feb 11, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 11, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:31:57 -06:00

@ptman commented on GitHub (Feb 12, 2019):

this is quite annoying

@ptman commented on GitHub (Feb 12, 2019): this is quite annoying

GiteaMirror commented

2025-11-02 03:31:57 -06:00

@zeripath commented on GitHub (May 26, 2019):

Hi is this still happening in 1.8?

I thought I'd got upload pack et al to be truly quiet in #5887.

If it's still happening I should be able to fix.

@zeripath commented on GitHub (May 26, 2019): Hi is this still happening in 1.8? I thought I'd got upload pack et al to be truly quiet in #5887. If it's still happening I should be able to fix.

GiteaMirror commented

2025-11-02 03:31:57 -06:00

@mnsh commented on GitHub (Jun 25, 2019):

Hi is this still happening in 1.8?

I thought I'd got upload pack et al to be truly quiet in #5887.

If it's still happening I should be able to fix.

For the record: with current master, this is no longer an issue.

@mnsh commented on GitHub (Jun 25, 2019): > Hi is this still happening in 1.8? > > I thought I'd got upload pack et al to be truly quiet in #5887. > > If it's still happening I should be able to fix. For the record: with current master, this is no longer an issue.

GiteaMirror referenced this issue

2025-11-02 08:04:51 -06:00

Add config option to disable auto watch for new user #8398

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#653