-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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.
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
embedded subcommand not working in Linux #12082
Comments
|
Yeah, this is wrong in the help:
|
I'm confused by this response. |
If the command is not understood it should error. |
Lines 98 to 101 in 838fef2
We are setting the default command to be the same we As for why the command isn't working for you, you need to specify the config file with the e.g. |
I'm getting empty file listings in docker exec, while the paths are being detected without flags:
I've however tried adding the flag, and no files were listed still.
|
This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions. |
bump |
I can't replicate your problem. This works on gitea/gitea:latest: docker pull gitea/gitea:latest
docker run gitea/gitea:latest &
docker exec $(docker ps | grep gitea | cut -f1 -d\ ) gitea embedded list "**" This works on gitea/gitea:1.12: docker pull gitea/gitea:1.12
docker run gitea/gitea:1.12 &
docker exec $(docker ps | grep gitea | cut -f1 -d\ ) gitea embedded list "**"
|
Too many docker users are caught out by the default location for the app.ini file being environment dependent so that when they docker exec into the container the `gitea` commands do not work properly and require additional `-c` arguments to correctly pick up the configuration. This PR simply builds the default locations into the build. Fix go-gitea#14468 Reference go-gitea#17497 Reference go-gitea#12082 Reference go-gitea#8941 ... amongst others ... Signed-off-by: Andrew Thornton <[email protected]>
This issue still seems to be present. I can get a result from (1) With invalid config file - works
(2) With correct path to config file - No Result
(3) With no path specified (presumably using /data/gitea/conf/app.ini) - No Result
stat showing the config file exists at the location used for (2) (3)
So a workaround seems to be to specify an incorrect config file. I'm using gitea docker 1.15.6 |
I meet the similar problem on my side: If I do But if I do |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Some thoughts (maybe conclusions):
ps: I haven't investigated this problem carefully, these information is just FYI, correct me if I was wrong. |
Too many docker users are caught out by the default location for the app.ini file being environment dependent so that when they docker exec into the container the gitea commands do not work properly and require additional -c arguments to correctly pick up the configuration. This PR simply shadows the gitea binary using variants of the FHS compatible script to make the command gitea have the default locations by default. Fix go-gitea#14468 Reference go-gitea#17497 Reference go-gitea#12082 Reference go-gitea#8941 ... amongst others ... Replace go-gitea#17501 Signed-off-by: Andrew Thornton <[email protected]>
Too many docker users are caught out by the default location for the app.ini file being environment dependent so that when they docker exec into the container the gitea commands do not work properly and require additional -c arguments to correctly pick up the configuration. This PR simply shadows the gitea binary using variants of the FHS compatible script to make the command gitea have the default locations by default. Fix #14468 Reference #17497 Reference #12082 Reference #8941 ... amongst others ... Replace #17501 Signed-off-by: Andrew Thornton <[email protected]>
@lunny I think this is a bug, not related to docker. See my comments above. So maybe we should keep this open. |
I found the root case of this bug.
Then bad thing happens: Gitea |
Too many docker users are caught out by the default location for the app.ini file being environment dependent so that when they docker exec into the container the gitea commands do not work properly and require additional -c arguments to correctly pick up the configuration. This PR simply shadows the gitea binary using variants of the FHS compatible script to make the command gitea have the default locations by default. Fix go-gitea#14468 Reference go-gitea#17497 Reference go-gitea#12082 Reference go-gitea#8941 ... amongst others ... Replace go-gitea#17501 Signed-off-by: Andrew Thornton <[email protected]>
working that way:
|
##⚠️ Breaking The `log.<mode>.<logger>` style config has been dropped. If you used it, please check the new config manual & app.example.ini to make your instance output logs as expected. Although many legacy options still work, it's encouraged to upgrade to the new options. The SMTP logger is deleted because SMTP is not suitable to collect logs. If you have manually configured Gitea log options, please confirm the logger system works as expected after upgrading. ## Description Close #12082 and maybe more log-related issues, resolve some related FIXMEs in old code (which seems unfixable before) Just like rewriting queue #24505 : make code maintainable, clear legacy bugs, and add the ability to support more writers (eg: JSON, structured log) There is a new document (with examples): `logging-config.en-us.md` This PR is safer than the queue rewriting, because it's just for logging, it won't break other logic. ## The old problems The logging system is quite old and difficult to maintain: * Unclear concepts: Logger, NamedLogger, MultiChannelledLogger, SubLogger, EventLogger, WriterLogger etc * Some code is diffuclt to konw whether it is right: `log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs `log.DelLogger("console")` * The old system heavily depends on ini config system, it's difficult to create new logger for different purpose, and it's very fragile. * The "color" trick is difficult to use and read, many colors are unnecessary, and in the future structured log could help * It's difficult to add other log formats, eg: JSON format * The log outputer doesn't have full control of its goroutine, it's difficult to make outputer have advanced behaviors * The logs could be lost in some cases: eg: no Fatal error when using CLI. * Config options are passed by JSON, which is quite fragile. * INI package makes the KEY in `[log]` section visible in `[log.sub1]` and `[log.sub1.subA]`, this behavior is quite fragile and would cause more unclear problems, and there is no strong requirement to support `log.<mode>.<logger>` syntax. ## The new design See `logger.go` for documents. ## Screenshot <details> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </details> ## TODO * [x] add some new tests * [x] fix some tests * [x] test some sub-commands (manually ....) --------- Co-authored-by: Jason Song <[email protected]> Co-authored-by: delvh <[email protected]> Co-authored-by: Giteabot <[email protected]>
Description
The embedded subcommand does not work list or extract any files.
Screenshots
Reason
Gitea
embedded
can not run with mismatched Linux user in an installed config, there will be no output at all.Workaround
Run gitea with the correct Linux user (as in the
app.ini
), usingsu
orsudo
The text was updated successfully, but these errors were encountered: