Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Gitea: Internal Server Error #23636

Closed
hiifong opened this issue Mar 22, 2023 · 22 comments
Closed

Gitea: Internal Server Error #23636

hiifong opened this issue Mar 22, 2023 · 22 comments
Labels
type/bug

Comments

@hiifong
Copy link
Contributor

hiifong commented Mar 22, 2023 •
edited

Description

After I start a gitea instance with systemd, and then another gitea instance with the ./gitea web -p 3333 command, Ctrl+C

Gitea Version

v1.20+

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

image
image
image
image

Git Version

No response

Operating System

No response

How are you running Gitea?

./gitea web

Database

None
@lunny
Copy link
Member

lunny commented Mar 22, 2023

We needs more logs

@yp05327 yp05327 mentioned this issue Mar 23, 2023
Open
@hiifong
Copy link
Contributor Author

hiifong commented Mar 23, 2023

We needs more logs

Seems like there are no more error logs

@lunny
Copy link
Member

lunny commented Mar 23, 2023

Or you can change RUN_MODE to dev and try ssh -T again.

@hiifong
Copy link
Contributor Author

hiifong commented Mar 23, 2023 •
edited

Or you can change RUN_MODE to dev and try ssh -T again.

image
not found any error log

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

I can't solve it by replacing the gitea binary file

@wxiaoguang
Copy link
Contributor

Or you can change RUN_MODE to dev and try ssh -T again.

not found any error log: <html>...

You are accessing wrong port. The port you are accessing is a HTTPS server, not SSH server.

@wxiaoguang
Copy link
Contributor

After I start a gitea instance with systemd, and then another gitea instance with the ./gitea web -p 3333 command, Ctrl+C

And I don't see why you should run two different Gitea instances at the same time with the same config.

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

After I start a gitea instance with systemd, and then another gitea instance with the ./gitea web -p 3333 command, Ctrl+C

And I don't see why you should run two different Gitea instances at the same time with the same config.

it was purely a mistake

@wxiaoguang
Copy link
Contributor

I can not understand your problem.

What's your problem?

  • Start Gitea by systemd, then start another manually, then stop the manually started one, then the systemd one doesn't work with SSH clone?
  • Why are you testing the SSH on a HTTPS port?

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

I can not understand your problem.

What's your problem?

  • Start Gitea by systemd, then start another manually, then stop the manually started one, then the systemd one doesn't work with SSH clone?
  • Why are you testing the SSH on a HTTPS port?

step 1：use systemd run a gitea instance
step 2: ./gitea web -p 3333
step 3: Ctrl + C
step 4: can't push code to gitea and git clone

@wxiaoguang
Copy link
Contributor

Restart the systemd service will resolve the problem.

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

Restart the systemd service will resolve the problem.

no

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

image

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

image

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Mar 24, 2023 •
edited

Try to:

  1. Re-sync the git hook on the admin page
  2. Enable Dev mode ,and try to : ssh git-user@your-server git-receive-pack your-org/your-repo.git to see what's the output. Do not use it on the HTTPS port.

Screenshot:

image

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

image

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Mar 24, 2023 •
edited

Isn't it clear enough .........

Your LOCAL_ROOT_URL is wrong.

Fix the port

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

Isn't it clear enough .........

Your LOCAL_ROOT_URL is wrong.

Fix the port

thank you，delete LOCAL_ROOT_URL can resolve the problem.

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023 •
edited

I'm sure I don't have LOCAL_ROOT_URL configured

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Mar 24, 2023 •
edited

If there is an issue, please describe all the details clearly and provide enough clues. And it's always better to share console texts than images.

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

If there is an issue, please describe all the details clearly and provide enough clues. And it's always better to share console texts than images.

get it

@hiifong
Copy link
Contributor Author

hiifong commented Mar 24, 2023

thank you very much

@lunny lunny closed this as completed Mar 24, 2023
@wxiaoguang wxiaoguang mentioned this issue Mar 24, 2023
Merged
lunny pushed a commit that referenced this issue Mar 29, 2023
@wxiaoguang @delvh
Refactor internal API for git commands, use meaningful messages inste…
f453879 
…ad of "Internal Server Error" (#23687)

# Why this PR comes

At first, I'd like to help users like #23636 (there are a lot)

The unclear "Internal Server Error" is quite anonying, scare users,
frustrate contributors, nobody knows what happens.

So, it's always good to provide meaningful messages to end users (of
course, do not leak sensitive information).

When I started working on the "response message to end users", I found
that the related code has a lot of technical debt. A lot of copy&paste
code, unclear fields and usages.

So I think it's good to make everything clear.

# Tech Backgrounds

Gitea has many sub-commands, some are used by admins, some are used by
SSH servers or Git Hooks. Many sub-commands use "internal API" to
communicate with Gitea web server.

Before, Gitea server always use `StatusCode + Json "err" field` to
return messages.

* The CLI sub-commands: they expect to show all error related messages
to site admin
* The Serv/Hook sub-commands (for git clients): they could only show
safe messages to end users, the error log could only be recorded by
"SSHLog" to Gitea web server.

In the old design, it assumes that:

* If the StatusCode is 500 (in some functions), then the "err" field is
error log, shouldn't be exposed to git client.
* If the StatusCode is 40x, then the "err" field could be exposed. And
some functions always read the "err" no matter what the StatusCode is.

The old code is not strict, and it's difficult to distinguish the
messages clearly and then output them correctly.

# This PR

To help to remove duplicate code and make everything clear, this PR
introduces `ResponseExtra` and `requestJSONResp`.

* `ResponseExtra` is a struct which contains "extra" information of a
internal API response, including StatusCode, UserMsg, Error
* `requestJSONResp` is a generic function which can be used for all
cases to help to simplify the calls.
* Remove all `map["err"]`, always use `private.Response{Err}` to
construct error messages.
* User messages and error messages are separated clearly, the `fail` and
`handleCliResponseExtra` will output correct messages.
* Replace all `Internal Server Error` messages with meaningful (still
safe) messages.

This PR saves more than 300 lines, while makes the git client messages
more clear.

Many gitea-serv/git-hook related essential functions are covered by
tests.

---------

Co-authored-by: delvh <dev.lh@web.de>
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type/bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lunny @wxiaoguang @hiifong