Gitea: 推送到空存储库未反映在 Web UI 中

创建于 2020-01-15  ·  84评论  ·  资料来源: go-gitea/gitea
  • Gitea 版本（或提交参考）：1.10.2
  • Git 版本：2.25.0
  • 操作系统：ArchLinuxARM
  • 数据库（使用[x] ）：

    • [] PostgreSQL

    • [] MySQL

    • [ ] MSSQL

    • [x] SQLite

  • 您能否在https://try.gitea.io重现该错误：

    • [ ] 是（提供示例 URL）

    • [x] 否： https :

    • [ ] 不相关

  • 日志要点： https :

描述

与#9365 中的完全相同，但文件系统是用exec挂载的。 我认为 localhost API 调用是钩子，但我不确定。 当通过终端手动执行时，repo 中的钩子可以正常运行。

（从前面提到的问题复制的描述）

我创建了一个新的存储库并推送了一个本地存储库。 我尝试使用 --all （它有两个分支）和不使用（仅推送 master）。 无论哪种方式，存储库都不会更改为非空。 我在数据库中手动将 is_empty 列设置为 0，从而解决了问题。

picture kauron

所有84条评论

我看不到任何对预接收或后接收的调用，因此它们显然没有运行。

我怀疑您的 Gitea 存储库挂钩丢失了它们的可执行位。 这意味着例如不仅是 pre-receive.d 中的文件，还有 pre-receive 本身

另一种可能是它们已经过时了。

你说他们在从终端执行时运行 find 是什么意思？ 您是否设法正确地欺骗了预接收命令？

经过很长时间和大量的挠头后，似乎可能的解决方案是：

https://github.com/go-gitea/gitea/issues/9792#issuecomment -691291999

zeripath picture zeripath 于 2020-01-16

我怀疑您的 Gitea 存储库挂钩丢失了它们的可执行位。 这意味着例如不仅是 pre-receive.d 中的文件，还有 pre-receive 本身

这是 gitea 存储库之一中ls -lh hooks/的输出：

total 76K
-rwxr-xr-x 1 gitea gitea  478 Jan 15 22:44 applypatch-msg.sample
-rwxr-xr-x 1 gitea gitea  896 Jan 15 22:44 commit-msg.sample
-rwxr-xr-x 1 gitea gitea 3.1K Jan 15 22:44 fsmonitor-watchman.sample
-rwxr-xr-x 1 gitea gitea  303 Jan 15 22:44 post-receive
drwxr-xr-x 2 gitea gitea 4.0K Jan 15 22:44 post-receive.d
-rwxr-xr-x 1 gitea gitea  189 Jan 15 22:44 post-update.sample
-rwxr-xr-x 1 gitea gitea  424 Jan 15 22:44 pre-applypatch.sample
-rwxr-xr-x 1 gitea gitea 1.6K Jan 15 22:44 pre-commit.sample
-rwxr-xr-x 1 gitea gitea  416 Jan 15 22:44 pre-merge-commit.sample
-rwxr-xr-x 1 gitea gitea 1.5K Jan 15 22:44 prepare-commit-msg.sample
-rwxr-xr-x 1 gitea gitea 1.4K Jan 15 22:44 pre-push.sample
-rwxr-xr-x 1 gitea gitea 4.8K Jan 15 22:44 pre-rebase.sample
-rwxr-xr-x 1 gitea gitea  303 Jan 15 22:44 pre-receive
drwxr-xr-x 2 gitea gitea 4.0K Jan 15 22:44 pre-receive.d
-rwxr-xr-x 1 gitea gitea  544 Jan 15 22:44 pre-receive.sample
-rwxr-xr-x 1 gitea gitea  283 Jan 15 22:44 update
drwxr-xr-x 2 gitea gitea 4.0K Jan 15 22:44 update.d
-rwxr-xr-x 1 gitea gitea 3.6K Jan 15 22:44 update.sample

另一种可能是它们已经过时了。

我怎么能检查/更新它们？

你说他们在从终端执行时运行 find 是什么意思？ 您是否设法正确地欺骗了预接收命令？

在另一个问题中，服务器用户执行挂钩的能力被禁用，因此我以gitea用户身份登录并手动执行其中一个挂钩（成功）。 我已经检查过它们是可执行的，但想确保我正确读取了权限。

kauron picture kauron 于 2020-01-16

好的，所有这些都是适当的可执行文件，接下来您可以检查pre-receive.d/gitea的内容和模式

要更新/更正这些，您需要使用管理员任务“更新和重新同步挂钩”

zeripath picture zeripath 于 2020-01-16
👍1

内容及方式：

[gitea<strong i="6">@host</strong> pre-receive.d]$ ls -lh
total 4.0K
-rwxr-xr-x 1 gitea gitea 84 ene 15 22:44 gitea
[gitea<strong i="7">@host</strong> pre-receive.d]$ cat gitea
#!/usr/bin/env bash
"/usr/bin/gitea" hook --config='/etc/gitea/app.ini' pre-receive

运行相应的管理员任务后，唯一改变的是文件的时间属性。

pre-receive钩子似乎是默认的：

#!/usr/bin/env bash
data=$(cat)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}

for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done

for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
done
kauron picture kauron 于 2020-01-16

此问题已自动标记为过时，因为它最近没有活动。 我在这里帮助清除问题，即使解决或等待更多见解。 如果在接下来的 2 周内没有发生进一步的活动，此问题将被关闭。 如果问题仍然有效，只需添加评论以使其保持活力。 感谢你的贡献。

stale[bot] picture stale[bot] 于 2020-03-16

这个问题仍然有效。

kauron picture kauron 于 2020-03-17

此问题已自动标记为过时，因为它最近没有活动。 我在这里帮助清除问题，即使解决或等待更多见解。 如果在接下来的 2 周内没有发生进一步的活动，此问题将被关闭。 如果问题仍然有效，只需添加评论以使其保持活力。 感谢你的贡献。

stale[bot] picture stale[bot] 于 2020-05-16

这个问题仍然有效。 @zeripath ，我可以提供哪些附加信息来帮助调试？

kauron picture kauron 于 2020-05-16

嗯...我有点难住，但是，我在其他地方注意到的一件事：确保您的LFS_CONTENT_PATH是绝对路径。 （我想知道你是否受到#11362 修复的东西的影响）

zeripath picture zeripath 于 2020-05-16

这是一条相对路径。 我已经改成绝对路径了，重启gitea再试，问题依旧。

kauron picture kauron 于 2020-05-16

你用的是什么版本的gitea？ - 是否可以更新到 master（最好）或 1.11.5？

zeripath picture zeripath 于 2020-05-16

我使用的是 1.11.5，但我会尝试启动并运行master分支。

kauron picture kauron 于 2020-05-20

我曾尝试在 x86_64 PC 中执行 v1.11.5。 然后我在失败的同一台 ARM 机器上尝试，在一个不同的用户下运行一个单独的实例，一个空白的 db 和现有的 db。 在任何一种情况下，我都无法重现该问题。

在检查日志时，我发现了以下内容：

may 26 16:31:08 HOSTNAME gitea[10611]: 2020/05/26 16:31:08 ...eue/queue_wrapped.go:68:setInternal() [W] [Attempt: 7] Failed to create queue: level for  cfg: [123 34 65 100 100 114 101 115 115 101 115 34 58 34 49 50 55 46 48 46 48 46 49 58 54 51 55 57 34 44 34 66 97 116 99 104 76 101 110 103 116 104 34 58 50 48 44 34 66 108 111 99 107 84 105 109 101 111 117 116 34 58 49 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 84 105 109 101 111 117 116 34 58 51 48 48 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 87 111 114 107 101 114 115 34 58 53 44 34 68 66 73 110 100 101 120 34 58 48 44 34 68 97 116 97 68 105 114 34 58 34 100 97 116 97 47 100 97 116 97 47 113 117 101 117 101 115 47 116 97 115 107 34 44 34 77 97 120 87 111 114 107 101 114 115 34 58 49 48 44 34 78 97 109 101 34 58 34 116 97 115 107 34 44 34 78 101 116 119 111 114 107 34 58 34 34 44 34 80 97 115 115 119 111 114 100 34 58 34 34 44 34 81 117 101 117 101 76 101 110 103 116 104 34 58 50 48 44 34 81 117 101 117 101 78 97 109 101 34 58 34 116 97 115 107 95 113 117 101 117 101 34 44 34 87 111 114 107 101 114 115 34 58 49 125] error: leveldb: manifest corrupted (field 'comparer'): missing [file=MANIFEST-708535]
may 26 16:31:08 HOSTNAME gitea[10611]: 2020/05/26 16:31:08 ...eue/queue_wrapped.go:68:setInternal() [W] [Attempt: 7] Failed to create queue: level for  cfg: [123 34 65 100 100 114 101 115 115 101 115 34 58 34 49 50 55 46 48 46 48 46 49 58 54 51 55 57 34 44 34 66 97 116 99 104 76 101 110 103 116 104 34 58 50 48 44 34 66 108 111 99 107 84 105 109 101 111 117 116 34 58 49 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 84 105 109 101 111 117 116 34 58 51 48 48 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 87 111 114 107 101 114 115 34 58 53 44 34 68 66 73 110 100 101 120 34 58 48 44 34 68 97 116 97 68 105 114 34 58 34 100 97 116 97 47 100 97 116 97 47 113 117 101 117 101 115 47 105 115 115 117 101 95 105 110 100 101 120 101 114 34 44 34 77 97 120 87 111 114 107 101 114 115 34 58 49 48 44 34 78 97 109 101 34 58 34 105 115 115 117 101 95 105 110 100 101 120 101 114 34 44 34 78 101 116 119 111 114 107 34 58 34 34 44 34 80 97 115 115 119 111 114 100 34 58 34 34 44 34 81 117 101 117 101 76 101 110 103 116 104 34 58 50 48 44 34 81 117 101 117 101 78 97 109 101 34 58 34 105 115 115 117 101 95 105 110 100 101 120 101 114 95 113 117 101 117 101 34 44 34 87 111 114 107 101 114 115 34 58 49 125] error: leveldb: manifest corrupted (field 'comparer'): missing [file=MANIFEST-708536]

此消息会定期重复，大约每 90 秒一次。

我不确定是否相关的另一条消息是推送 repo 时的以下行：

remote: Processed 0 references in total

在正常工作的情况下会出现类似的行，但不是 0 个引用，而是 1 个引用，或者根本没有出现。

kauron picture kauron 于 2020-05-26

好的，这是队列的问题 - 它们在某些时候因崩溃或 kill -9 而损坏。 您将需要删除它们。

zeripath picture zeripath 于 2020-05-26

那么，我需要删除的两个文件夹名为task和issue_indexer的$GITEA_HOME/data/data/queues/ ？

我这样做了，日志消息停止出现，但问题仍然存在。

kauron picture kauron 于 2020-05-26

除了https://github.com/go-gitea/gitea/issues/9792#issuecomment -634064659 的队列问题之外，我已经解决了这个问题，并且处于完全相同的状态（并且已经几个月了） .

我提供了一些额外的信息，可能不相关，但可能会弹出一些信息。

  • 树莓派 4
  • 用于 ARM 的 Arch Linux
  • 基特 1.11.5
  • 只在我的本地网络中使用它，所以我还没有（还）设置 SSL 证书，即通信是未加密的，直接连接到 Pi 的 IP。
  • SSD 上的系统根目录，repos 单独安装：
[repository]
ROOT = /srv/git

（其中 /srv 不是目录而是挂载的分区）

/etc/systemd/system/gitea.service.d/override.conf ：

[Service]
ReadWritePaths=/etc/gitea/app.ini /srv/git
ltGuillaume picture ltGuillaume 于 2020-05-29

此问题已自动标记为过时，因为它最近没有活动。 我在这里帮助清除问题，即使解决或等待更多见解。 如果在接下来的 2 周内没有发生进一步的活动，此问题将被关闭。 如果问题仍然有效，只需添加评论以使其保持活力。 感谢你的贡献。

stale[bot] picture stale[bot] 于 2020-07-29

这个问题仍然没有得到解决，基本上意味着我每次创建一个新的 repo 时都必须进行手动 SQL 查询。

ltGuillaume picture ltGuillaume 于 2020-07-29
👍1

这个问题总是由于用户没有使用由 Gitea 管理的密钥推送。

Gitea 了解提交的唯一方法是在接收后期间告知提交 - 为此，存储库中有一个接收后挂钩，这需要由 Gitea serv 或 Web 服务器设置的环境。

我不会介绍如何正确设置环境，因为这是不受支持的 - 但不难找到应该是什么环境。 仅使用 Gitea 托管密钥或通过 http 推送到 Gitea 的存储库。

zeripath picture zeripath 于 2020-08-01

@ltGuillaume好的，让我们看看你的情况。 你肯定是在推 gitea 的 http url？ 您是否存在接收后挂钩且可执行？ 它们是最新的吗？

zeripath picture zeripath 于 2020-08-02

我总是使用http://myserver:3000/ltGuillaume/Repo-Name.git ，是的，但我可能应该做更多的事情。 我不确定我应该创建什么接收后挂钩。 在从 Gitea 网络界面创建一个空的 repo 后，我通常会执行以下操作：

git init
git add .
git commit
git remote add origin http://myserver:3000/ltGuillaume/Repo-Name.git
git push -u origin master
ltGuillaume picture ltGuillaume 于 2020-08-02

在您的 app.ini 中有一个[repository]部分。 它有一个设置ROOT ，它说明了 Gitea 使用的原始 git 存储库的保存位置。

您的存储库存储在名为owner/reponame.git ROOT 下的目录中

在每个目录中，都有一个hooks/目录。 特别是在这些pre-receive 、 pre-receive.d/gitea 、 post-receive 、 post-receive.d/gitea有 4 个特殊脚本。

这些需要是可执行的，并在每次推送时运行。

Gitea 将为您创建这些“委托”挂钩。 http://localhost:3000/admin页面上有一个功能：重新同步所有存储库的预接收、更新和接收后挂钩 - 这将更新这些内容。 但是，如果您的存储库位于会导致问题的不可执行分区上。

值得检查这些文件的值。

zeripath picture zeripath 于 2020-08-02

包含我的 repos 的分区是使用defaults,noatime,nodiratime,discard挂载的，所以那里没有noexec 。

pre-receive.d 钩子文件夹和其中的 gitea 文件存在并且具有权限 (d)rwxr-xr-x。

我刚刚通过 web 界面创建了一个新的 repo 而不初始化它并进入它的post-receive.d和pre-receive.d文件夹：两者都有一个gitea文件：

#!/usr/bin/env bash
"/usr/bin/gitea" hook --config='/etc/gitea/app.ini' [pre/post]-receive

文件pre-receive和post-receive也存在，这里是其中一个的内容：

#!/usr/bin/env bash
data=$(cat)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}

for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" && test -f "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done

for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
done
ltGuillaume picture ltGuillaume 于 2020-08-02

好的，我快速浏览一下这些文件。

你用的是什么版本？

zeripath picture zeripath 于 2020-08-02

Arch ARM 上的 1.11.6（1.12.3 尚不可用）。

ltGuillaume picture ltGuillaume 于 2020-08-02

嗯......我不确定 Arch ARM 如何打包他们的构建，因为他们似乎有 1.12.3 https://github.com/archlinuxarm/PKGBUILDs/tree/master/community/gitea

techknowlogick picture techknowlogick 于 2020-08-03

所以我认为在 1.11 中，至少有一个用户存在一个问题，需要设置 --work-path 命令行选项可能值得手动调整挂钩以查看是否是问题所在？

我修复了 1.12

zeripath picture zeripath 于 2020-08-03

我会尝试将--work-path='/var/lib/gitea/'到钩子中。

__Edit:__ 在使用更改后的pre-/post-receive.d/gitea推送新提交后，Gitea 的 Web 界面仍将 repo 视为空。

有点奇怪： https ://archlinuxarm.org/packages 显示 v1.11.6 目前是 Raspberry Pi 4 的最新版本，因为 aarch64 尚未（正式）支持，但如果有原因，我找不到任何地方为什么还没有更新。

ltGuillaume picture ltGuillaume 于 2020-08-07

向这些钩子添加回声以检查它们是否实际正在运行会很有帮助。

zeripath picture zeripath 于 2020-08-07

我必须首先了解回声文本会出现在哪里。

如果有帮助，我可以停止 gitea 作为服务并再次从用户 gitea 下的 bash 运行它，但看起来这些钩子无论如何都会运行另一个进程，所以我不确定它们的输出是否会出现在控制台中。 它们是否会在/var/log/gitea/gitea.log没有任何更改（或者我是否需要更改为调试日志记录）？

ltGuillaume picture ltGuillaume 于 2020-08-07

在您的 git 流中不会出现 pre-receive 或 post-receive 钩子中的回声。

如果挂钩有效，当您在用户下运行 Gitea 时，我不会感到惊讶。

zeripath picture zeripath 于 2020-08-08

我今天更新到 Gitea 1.12.3并创建了一个新的空仓库。 在多次提交之后，Gitea 仍然没有意识到它不再是空的。

在您的 git 流中不会出现 pre-receive 或 post-receive 钩子中的回声。
如果挂钩有效，当您在用户下运行 Gitea 时，我不会感到惊讶。

你能不能改写一下？

我是否将echo The pre-receive hook was run到pre-receive.d/gitea脚本中（以及在帖子中），然后推送提交，然后应该能够在何处找到它？

ltGuillaume picture ltGuillaume 于 2020-08-13

我还看到我所有本地存储库的大小都显示为 0B（其他是镜像），并且这些本地存储库中的任何活动都没有显示在我的仪表板上。

image

ltGuillaume picture ltGuillaume 于 2020-09-06

是的，这会一直发生，直到你修复了钩子发生的任何事情。

除非钩子运行正常，否则 Gitea 不会被告知其存储库发生的变化。

您是否在接收前或接收后挂钩中放置了回声？

zeripath picture zeripath 于 2020-09-06

嗨，我终于有时间通过​​向钩子（ update 、 pre-receive和post-receive ）添加 echo 语句来更深入地测试这个问题。 看起来post-receive没有收到数据，因为它表示处理了 0 个引用。
我正在使用版本：1.12.4，从此 [package][1] 安装。

git push的完整输出如下：

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 870 bytes | 870.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Start pre-receive
remote: End pre-receive
remote: Start update
remote: End update
remote: Start post-receive
remote: Processed 0 references in total
remote: End post-receive
To ssh://****:22/user/test.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
kauron picture kauron 于 2020-09-07

这是我的输出。 我从/*.d/gitea复制命令并将echo放在前面，以便查看正在或应该运行的实际命令：

E:\Projects\Websites\MyProject>git push
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 669 bytes | 669.00 KiB/s, done.
Total 6 (delta 4), reused 0 (delta 0), pack-reused 0
remote: /usr/bin/gitea hook --config=/etc/gitea/app.ini pre-receive
remote: /usr/bin/gitea hook --config=/etc/gitea/app.ini update refs/heads/master bfd503996671dd9b4546fcb1e4ee6ee2409dfeed 0eca4bdb74e4df71788292effba14aa58c47813f
remote: /usr/bin/gitea hook --config=/etc/gitea/app.ini post-receive
remote: Processed 0 references in total
To http://address:3000/ltGuillaume/MyProject.git
   bfd5039..0eca4bd  master -> master
ltGuillaume picture ltGuillaume 于 2020-09-07

Processed 0 references in total ...

这太有趣了

zeripath picture zeripath 于 2020-09-07

钩子可以声明没有引用的唯一方法是：

https://github.com/go-gitea/gitea/blob/d257485bc0026c9717fe7bf4c9953ad1b7a1a9ae/cmd/hook.go#L344 -L346

即它是数据库中的 wiki 或 GITEA_REPO_IS_WIKI 已在环境中设置 - 请检查！

或者：

https://github.com/go-gitea/gitea/blob/d257485bc0026c9717fe7bf4c9953ad1b7a1a9ae/cmd/hook.go#L348 -L352

它正在传递一个虚假的额外空间。 在这种情况下，查看钩子进程接收到的内容会很有帮助，但我现在太累了，无法编写 bash。 基本的方法是在调用 Gitea serv 钩子之前加上 cat - | tee 但最好通过 xxd 来证明那里是否有偷偷摸摸的回车。

git post 接收文档非常清楚，stdin 上的一行不能超过 2 个空格用于接收脚本，因此如果添加了某些内容，那就是问题所在。

所以有两个选择：
A）不知何故，环境标志被设置为维基。 可以为环境变量添加一个 echo 以查看它是否已设置。
B）某些东西正在与接收挂钩的标准输入拧紧，并在不应该存在的地方添加空间。 那可能是您的 Windows git 客户端在每一行的末尾发送了一个 \r ，这与它自己的文档背道而驰。

如果您可以证明它不是环境变量 - 那么很可能是这样，调整代码以应对它应该很容易。

zeripath picture zeripath 于 2020-09-07

感谢您查看代码。

A) 我不知道我通过 Gitea 的网络创建的 _every_ 新存储库为什么以及如何（自动）发生这种情况。 我向pre-receive.d/gitea添加了一个回声，结果是： remote: GITEA_REPO_IS_WIKI = false （完整输出见下文）。

B）我不确定这是否是您的意思，但我确实在我的 Windows git 客户端上将core.autocrlf设置为false中的.gitconfig ，但将其明确更改为true并推送另一个提交并没有改变任何东西。 输出：

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 299 bytes | 299.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: GITEA_REPO_IS_WIKI = false
remote: /usr/bin/gitea hook --config=/etc/gitea/app.ini pre-receive
remote: /usr/bin/gitea hook --config=/etc/gitea/app.ini update refs/heads/master c300b3e004ab5f9edcec153eb13bbcb5c5f5bbe4 41cf8dc7ed0e8198be29c34e623384861d84386f
remote: /usr/bin/gitea hook --config=/etc/gitea/app.ini post-receive
remote: Processed 0 references in total
To http://address:3000/ltGuillaume/MyProject.git
   c300b3e..41cf8dc  master -> master

我还创建了一个新的存储库，将此选项设置为true ，但得到的结果与将选项设置为false 。

ltGuillaume picture ltGuillaume 于 2020-09-08

好的，你能编译gitea吗？

zeripath picture zeripath 于 2020-09-08

另一件事 - 你总是从 Windows 推送吗？

zeripath picture zeripath 于 2020-09-08

如果您可以将 #12772 中的补丁应用于 gitea 并构建它，我想知道这是否最终可以解决您和其他一些问题。

zeripath picture zeripath 于 2020-09-08

好的，你能编译gitea吗？

这有点超出我的范围，我只是在 Pi 4 上运行 Arch 默认存储库中的包。

另一件事 - 你总是从 Windows 推送吗？

目前，是的。

ltGuillaume picture ltGuillaume 于 2020-09-09

我刚刚用 Manjaro 打开了一台 VirtualBox 机器，并在我的 Gitea 实例上创建了一个新的存储库。 然后我再次按照 Gitea 所示的确切说明进行操作，但这次在 Manjaro Linux 上使用 git。 结果是一样的：

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 223 bytes | 223.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Processed 0 references in total
To http://address:3000/ltGuillaume/MyProject.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
ltGuillaume picture ltGuillaume 于 2020-09-09

编译 gitea 并不是特别困难 - 但很好。

我采用了最新的 origin/release/v1.12 并按照 Arch 的 pkgbuild (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gitea-git) 编译它，如下所示补丁。

该文件将一直存在到今天英国夏令时 19:00，届时我将删除。


补丁

From b26a160de7cfef480d7edea697e39c016f84747d Mon Sep 17 00:00:00 2001
From: Andrew Thornton <[email protected]>
Date: Tue, 8 Sep 2020 22:11:40 +0100
Subject: [PATCH 1/2] Tolerate a terminal CR on a pre/post-receive line

My suspicion is that occasionally windows users will send a terminal
CRLF on the post-receive lines in violation of the git spec. Currently
gitea enforces that there have to be only 3 fields - but the terminal CR
will form an additional field.

This PR will allow a 4th field iff it is simply a carriage return.

It will also log when it is not allowing lines.

Fix #9792

Signed-off-by: Andrew Thornton <[email protected]>
---
 cmd/hook.go | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/cmd/hook.go b/cmd/hook.go
index fa932087f..b345800bf 100644
--- a/cmd/hook.go
+++ b/cmd/hook.go
@@ -17,6 +17,7 @@ import (

    "code.gitea.io/gitea/models"
    "code.gitea.io/gitea/modules/git"
+   "code.gitea.io/gitea/modules/log"
    "code.gitea.io/gitea/modules/private"
    "code.gitea.io/gitea/modules/setting"
    "code.gitea.io/gitea/modules/util"
@@ -195,8 +196,15 @@ Gitea or set your environment appropriately.`, "")
        }

        fields := bytes.Fields(scanner.Bytes())
-       if len(fields) != 3 {
+       if len(fields) < 3 {
+           fmt.Fprintf(out, "Ignoring bad pre-receive line with less than 3 fields: %s", scanner.Text())
            continue
+       } else if len(fields) > 3 {
+           if string(fields[4]) != "\r" && len(fields) == 4 {
+               fmt.Fprintf(out, "Ignoring bad post-receive line with greater than 4 fields: %s", scanner.Text())
+               continue
+           }
+           log.Debug("Tolerating terminal CR in violation of specification")
        }

        oldCommitID := string(fields[0])
@@ -329,8 +337,15 @@ Gitea or set your environment appropriately.`, "")
        }

        fields := bytes.Fields(scanner.Bytes())
-       if len(fields) != 3 {
+       if len(fields) < 3 {
+           fmt.Fprintf(out, "Ignoring bad post-receive line with less than 3 fields: %s", scanner.Text())
            continue
+       } else if len(fields) > 3 {
+           if string(fields[4]) != "\r" && len(fields) == 4 {
+               fmt.Fprintf(out, "Ignoring bad post-receive line with greater than 4 fields: %s", scanner.Text())
+               continue
+           }
+           log.Debug("Tolerating a final CR on pre-receive lines in violation of spec")
        }

        fmt.Fprintf(out, ".")
-- 
2.25.1


From fc277c73033cdf7f27005064a2da4da75505bbfa Mon Sep 17 00:00:00 2001
From: Andrew Thornton <[email protected]>
Date: Wed, 9 Sep 2020 14:54:07 +0100
Subject: [PATCH 2/2] forcibly debug

Signed-off-by: Andrew Thornton <[email protected]>
---
 cmd/hook.go | 4 ++--
 cmd/serv.go | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/cmd/hook.go b/cmd/hook.go
index b345800bf..781e15199 100644
--- a/cmd/hook.go
+++ b/cmd/hook.go
@@ -139,7 +139,7 @@ func runHookPreReceive(c *cli.Context) error {
        return nil
    }

-   setup("hooks/pre-receive.log", false)
+   setup("hooks/pre-receive.log", true)

    if len(os.Getenv("SSH_ORIGINAL_COMMAND")) == 0 {
        if setting.OnlyAllowPushIfGiteaEnvironmentSet {
@@ -281,7 +281,7 @@ func runHookPostReceive(c *cli.Context) error {
        return nil
    }

-   setup("hooks/post-receive.log", false)
+   setup("hooks/post-receive.log", true)

    if len(os.Getenv("SSH_ORIGINAL_COMMAND")) == 0 {
        if setting.OnlyAllowPushIfGiteaEnvironmentSet {
diff --git a/cmd/serv.go b/cmd/serv.go
index 7c2be5157..5ba257d07 100644
--- a/cmd/serv.go
+++ b/cmd/serv.go
@@ -50,8 +50,9 @@ var CmdServ = cli.Command{
 }

 func setup(logPath string, debug bool) {
-   if !debug {
-       _ = log.DelLogger("console")
+   _ = log.DelLogger("console")
+   if debug {
+       _ = log.NewLogger(1000, "console", "console", `{"level":"trace","stacktracelevel":"NONE","stderr":true}`)
    }
    setting.NewContext()
    if debug {
-- 
2.25.1

zeripath picture zeripath 于 2020-09-09

谢谢你经历了这一切。 不幸的是，这似乎是 x64 版本，而 ArchLinux for ARM（在 Raspberry Pi 上）仍然是 x86。

编辑：这最近已更改，但为了稳定性起见，我仍在使用 ARMv7 x86 版本。

考虑到我只从 Linux 发行版使用 git 时得到https://github.com/go-gitea/gitea/issues/9792#issuecomment -689196515。

ltGuillaume picture ltGuillaume 于 2020-09-09

补丁不仅仅是建议的 PR。

zeripath picture zeripath 于 2020-09-09

在非 x86 架构上复制 Arch 用于构建 gitea 的确切版本将非常困难。

例如，我无法使用“pam”进行构建。

该补丁所做的不仅仅是提议的更改。 应提供额外的日志信息。

zeripath picture zeripath 于 2020-09-09

编辑：我猜丢失的文件捆绑在gitea构建中？ https://archlinuxarm.org/packages/armv7h/gitea/files/PKGBUILD
locale_en-US.ini不在我的系统上。

ARM-6：

Sep 09 18:24:10 pi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:24:10 pi kernel: audit: type=1130 audit(1599668650.876:477): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:24:10 pi kernel: audit: type=1131 audit(1599668650.876:478): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:24:10 pi kernel: audit: type=1130 audit(1599668650.886:479): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:24:10 pi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 cmd/web.go:107:runWeb() [I] Starting Gitea on PID: 24634
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 ...dules/setting/git.go:93:newGit() [I] Git Version: 2.28.0, Wire Protocol Version 2 Enabled
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 ...es/setting/markup.go:61:newMarkupSanitizer() [W] Skipping empty section: markup.sanitizer.1.
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 routers/init.go:118:GlobalInit() [T] AppPath: /usr/bin/gitea
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 routers/init.go:119:GlobalInit() [T] AppWorkPath: /var/lib/gitea
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 routers/init.go:120:GlobalInit() [T] Custom path: /var/lib/gitea/custom
Sep 09 18:24:11 pi gitea[24634]: 2020/09/09 18:24:11 routers/init.go:121:GlobalInit() [T] Log path: /var/log/gitea/
Sep 09 18:24:11 pi gitea[24634]: panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory
Sep 09 18:24:11 pi gitea[24634]: goroutine 1 [running]:
Sep 09 18:24:11 pi gitea[24634]: gitea.com/macaron/i18n.initLocales(0x5bafbee, 0x0, 0x192368b, 0xb, 0x5219560, 0x199231a, 0x12, 0x563e000, 0x17, 0x20, ...)
Sep 09 18:24:11 pi gitea[24634]:         /source/vendor/gitea.com/macaron/i18n/i18n.go:57 +0x4e8
Sep 09 18:24:11 pi gitea[24634]: gitea.com/macaron/i18n.I18n(0x5f1fa48, 0x1, 0x1, 0x0, 0x0)
Sep 09 18:24:11 pi gitea[24634]:         /source/vendor/gitea.com/macaron/i18n/i18n.go:160 +0x4c
Sep 09 18:24:11 pi gitea[24634]: code.gitea.io/gitea/routers.InitLocales()
Sep 09 18:24:11 pi gitea[24634]:         /source/routers/init.go:100 +0x314
Sep 09 18:24:11 pi gitea[24634]: code.gitea.io/gitea/routers.GlobalInit(0x1e377e8, 0x56135d0)
Sep 09 18:24:11 pi gitea[24634]:         /source/routers/init.go:124 +0x2b4
Sep 09 18:24:11 pi gitea[24634]: code.gitea.io/gitea/cmd.runWeb(0x5f7c580, 0x0, 0x0)
Sep 09 18:24:11 pi gitea[24634]:         /source/cmd/web.go:116 +0x25c
Sep 09 18:24:11 pi gitea[24634]: github.com/urfave/cli.HandleAction(0x1622290, 0x1a7467c, 0x5f7c580, 0x560d800, 0x0)
Sep 09 18:24:11 pi gitea[24634]:         /source/vendor/github.com/urfave/cli/app.go:490 +0xac
Sep 09 18:24:11 pi gitea[24634]: github.com/urfave/cli.Command.Run(0x18a9367, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x19bc8d0, 0x16, 0x0, ...)
Sep 09 18:24:11 pi gitea[24634]:         /source/vendor/github.com/urfave/cli/command.go:210 +0x7a4
Sep 09 18:24:11 pi gitea[24634]: github.com/urfave/cli.(*App).Run(0x5082460, 0x500c140, 0x4, 0x4, 0x0, 0x0)
Sep 09 18:24:11 pi gitea[24634]:         /source/vendor/github.com/urfave/cli/app.go:255 +0x514
Sep 09 18:24:11 pi gitea[24634]: main.main()
Sep 09 18:24:11 pi gitea[24634]:         /source/main.go:109 +0x59c
Sep 09 18:24:11 pi systemd[1]: gitea.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

ARM-5：

Sep 09 18:27:24 pi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:27:24 pi kernel: audit: type=1130 audit(1599668844.373:789): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:27:24 pi kernel: audit: type=1131 audit(1599668844.373:790): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:27:24 pi kernel: audit: type=1130 audit(1599668844.383:791): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:27:24 pi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=gitea comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 cmd/web.go:107:runWeb() [I] Starting Gitea on PID: 25952
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 ...dules/setting/git.go:93:newGit() [I] Git Version: 2.28.0, Wire Protocol Version 2 Enabled
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 ...es/setting/markup.go:61:newMarkupSanitizer() [W] Skipping empty section: markup.sanitizer.1.
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 routers/init.go:118:GlobalInit() [T] AppPath: /usr/bin/gitea
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 routers/init.go:119:GlobalInit() [T] AppWorkPath: /var/lib/gitea
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 routers/init.go:120:GlobalInit() [T] Custom path: /var/lib/gitea/custom
Sep 09 18:27:24 pi gitea[25952]: 2020/09/09 18:27:24 routers/init.go:121:GlobalInit() [T] Log path: /var/log/gitea/
Sep 09 18:27:24 pi gitea[25952]: panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory
Sep 09 18:27:24 pi gitea[25952]: goroutine 1 [running]:
Sep 09 18:27:24 pi gitea[25952]: gitea.com/macaron/i18n.initLocales(0x47f786e, 0x0, 0x194657f, 0xb, 0x47000e0, 0x19b522f, 0x12, 0x458ee00, 0x17, 0x20, ...)
Sep 09 18:27:24 pi gitea[25952]:         /source/vendor/gitea.com/macaron/i18n/i18n.go:57 +0x4e8
Sep 09 18:27:24 pi gitea[25952]: gitea.com/macaron/i18n.I18n(0x4a1fa48, 0x1, 0x1, 0x0, 0x0)
Sep 09 18:27:24 pi gitea[25952]:         /source/vendor/gitea.com/macaron/i18n/i18n.go:160 +0x4c
Sep 09 18:27:24 pi gitea[25952]: code.gitea.io/gitea/routers.InitLocales()
Sep 09 18:27:24 pi gitea[25952]:         /source/routers/init.go:100 +0x314
Sep 09 18:27:24 pi gitea[25952]: code.gitea.io/gitea/routers.GlobalInit(0x1e58a90, 0x47f2190)
Sep 09 18:27:24 pi gitea[25952]:         /source/routers/init.go:124 +0x2b4
Sep 09 18:27:24 pi gitea[25952]: code.gitea.io/gitea/cmd.runWeb(0x3d30d10, 0x0, 0x0)
Sep 09 18:27:24 pi gitea[25952]:         /source/cmd/web.go:116 +0x25c
Sep 09 18:27:24 pi gitea[25952]: github.com/urfave/cli.HandleAction(0x1645170, 0x1a97590, 0x3d30d10, 0x3e6e800, 0x0)
Sep 09 18:27:24 pi gitea[25952]:         /source/vendor/github.com/urfave/cli/app.go:490 +0xac
Sep 09 18:27:24 pi gitea[25952]: github.com/urfave/cli.Command.Run(0x18cc247, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x19df7e5, 0x16, 0x0, ...)
Sep 09 18:27:24 pi gitea[25952]:         /source/vendor/github.com/urfave/cli/command.go:210 +0x7a4
Sep 09 18:27:24 pi gitea[25952]: github.com/urfave/cli.(*App).Run(0x3edd420, 0x3c0c140, 0x4, 0x4, 0x0, 0x0)
Sep 09 18:27:24 pi gitea[25952]:         /source/vendor/github.com/urfave/cli/app.go:255 +0x514
Sep 09 18:27:24 pi gitea[25952]: main.main()
Sep 09 18:27:24 pi gitea[25952]:         /source/main.go:109 +0x59c
Sep 09 18:27:24 pi systemd[1]: gitea.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
ltGuillaume picture ltGuillaume 于 2020-09-09

所以你需要 bindata 构建？

zeripath picture zeripath 于 2020-09-09

我知道我问了很多，真的很抱歉 😟 Arch 存储库中的默认 ARMv7 版本确实是 bindata 版本，是的。

ltGuillaume picture ltGuillaume 于 2020-09-09

重新上传

zeripath picture zeripath 于 2020-09-09

另一个 lang 文件现在失败了： Sep 09 20:35:54 pi gitea[10272]: panic: fail to set message file(pt-PT): open conf/locale/locale_pt-PT.ini: no such file or directory

ltGuillaume picture ltGuillaume 于 2020-09-09

只需编辑您的 app.ini 并坚持

[i18n]
LANGS = en-US
NAMES = English
zeripath picture zeripath 于 2020-09-09

.gitconfig: autocrlf = false

touch README.md
git init
git add README.md
git commit -m "First commit"
git remote add origin http://address:3000/ltGuillaume/MyProject.git
git push -u origin master

输出：

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 302 bytes | 302.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Pre-Receive hook echo...
remote: Update hook echo...
remote: Post-Receive hook echo...
remote: Ignoring bad post-receive line with less than 3 fields: Processed 0 references in total
To http://address:3000/ltGuillaume/MyProject.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
ltGuillaume picture ltGuillaume 于 2020-09-09

非常有趣的是，帖子接收脚本没有收到任何要更新的引用，甚至没有通过标准输入接收任何内容......

这很奇怪。 在接收后的途中一定有东西在吃stdin

zeripath picture zeripath 于 2020-09-10

当我在 Manjaro Linux 中克隆这个 repo 时会发生完全相同的事情，然后推送一个新的提交：

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 287 bytes | 287.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Pre-Receive hook...
remote: Update hook...
remote: Post-Receive hook...
remote: Ignoring bad post-receive line with less than 3 fields: Processed 0 references in total
To http://address:3000/ltGuillaume/MyProject.git
   3c0f4dc..ce74771  master -> master
ltGuillaume picture ltGuillaume 于 2020-09-10

你能再给我看看你的 post-receive.d/Gitea 脚本和 post-receive 脚本吗？

在 post-receive 中，添加以下内容可能会很有用：

echo "Received"
echo "${data}"
echo "End"
zeripath picture zeripath 于 2020-09-10 
remote: Pre-Receive hook...
remote: Update hook...
remote: Post-Receive hook...
remote: Received
remote: 
remote: End
remote: Ignoring bad post-receive line with less than 3 fields: Processed 0 references in total
ltGuillaume picture ltGuillaume 于 2020-09-10

是的，这证明它正在吃东西或阻止您接收后的消息到达钩子。 尝试将相同的回声添加到预接收变体中，看看它们是否遇到了同样的问题。

我对如何进行有点困惑 - 它看起来不再是 Gitea 问题了。 在这种情况下，所有钩子都会失败。

我不完全理解的是 git 的对象是如何传入的 - 那些也通过标准输入。

执行此操作的可能是 bash、cat、git 或 SSHD，但它不是 Gitea（可能除了它放在 authorized_keys 文件中的选项之一）。

诡异如地狱。

也许 post-receive 脚本需要阅读：

#!/usr/bin/env bash
data=$(</dev/stdin)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}

echo "RECEIVED"
echo "${data}"
echo "END"

for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" && test -f "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done

for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
done
zeripath picture zeripath 于 2020-09-10

实际上做到这一点：

数据=$(

zeripath picture zeripath 于 2020-09-10

这三个现在都有echo "${data}" 。
上面的脚本（带有data=$(</dev/stdin) ）在post-receive.d/gitea 。

remote: Pre-Receive hook...
remote: 
remote: End
remote: Update hook...
remote: 
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote: 
remote: END
remote: Processed 0 references in total
To http://address:3000/ltGuillaume/MyProject.git
   b8e3f18..76a202c  master -> master

现在去睡觉，希望我们能以某种方式解决这个问题......

ltGuillaume picture ltGuillaume 于 2020-09-10

抱歉今天没有回复。 你上面的发现肯定表明 git 应该发送的消息没有到达 bash 钩子。

现在这很奇怪。 所以问题是什么是罪魁祸首。

你可以做的一件事 - 只是排除 Gitea 可能受到指责的最后一种方式 - 是简化和删除 .authorized_keys 中授权密钥行的大部分限制，但我认为这不会解决问题。

我怀疑它是服务器上的 bash 或者它是服务器上的 git 版本。

但是你怎么知道呢？

一种选择是尝试升级这些以查看是否可以解决问题。 另一个是寻求拱门的帮助。 说明钩子在推送时在标准输入上没有收到任何内容。 他们可能知道问题出在哪里。

zeripath picture zeripath 于 2020-09-11

你可以做的一件事 - 只是排除 Gitea 可能受到指责的最后一种方式 - 是简化和删除 .authorized_keys 中授权密钥行的大部分限制，但我认为这不会解决问题。

我正在使用 HTTP 来推送我的提交，那么authorized_keys 会产生任何影响吗？

我怀疑它是服务器上的 bash 或者它是服务器上的 git 版本。
但是你怎么知道呢？
一种选择是尝试升级这些以查看是否可以解决问题。 另一个是寻求拱门的帮助。 说明钩子在推送时在标准输入上没有收到任何内容。 他们可能知道问题出在哪里。

一切都是最新的，而且我使用的是滚动发行版 (Arch)，因此它已经比大多数其他发行版更新了。
混帐：2.28.0
bash：5.0.018（bash 4.x 也有这些问题）

我只是尝试克隆，然后通过在服务器本身上使用 Git 对受影响的存储库提交一些更改。 结果是一样的：

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 299.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Pre-Receive hook...
remote:
remote: End
remote: Update hook...
remote:
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote:
remote: END
remote: End
remote: Processed 0 references in total
To http://localhost:3000/ltGuillaume/MyProject.git
   76a202c..e8533d5  master -> master

我将在https://archlinuxarm.org/forum/上创建一个主题，我将在我的 Manjaro 虚拟机上尝试 Gitea，以确保它不是跨平台的 Arch 问题（我非常怀疑）。

编辑：好的，在 Manjaro 中，来自https://github.com/go-gitea/gitea/issues/9792#issuecomment -689856986 的脚本的正确行为导致

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 259 bytes | 259.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: RECEIVED
remote: d55828af5c0b4f64966368def180496530ac6603 c1ca110e76cc2a4f27b9909e926802e60a66cc0b refs/heads/master
remote: END
remote: Processed 0 references in total
To http://localhost:3000/ltGuillaume/MyProject.git
   d55828a..c1ca110  master -> master
ltGuillaume picture ltGuillaume 于 2020-09-11

我想知道 Arch 上发生了什么。 多么奇怪。

zeripath picture zeripath 于 2020-09-11

FWIW 我在 pinebook pro (aarch64) 上使用 manjaro 并且我无法复制。

techknowlogick picture techknowlogick 于 2020-09-11

我想我离以下更近了一步（这肯定是最近添加的，显然我已经多次检查Wiki ）。

编辑：用户 Simplefied 已于 6 月 6 日将此解决方法添加到 Arch Wiki (https://wiki.archlinux.org/index.php?title=Gitea&type=revision&diff=618524&oldid=615095)。

在 ArchLinux ARM 上处理转储核心

推送新的 repo 后可能会出现问题。 在 web UI repo 中保持未初始化，并且系统日志中存在以下错误：

Jun 06 14:34:20 rpi-srv systemd-coredump[5724]: Process 5722 (cat) of user 986 dumped core.
                                                Stack trace of thread 5722:
                                                #0  0x0000000076f06e58 posix_fadvise64 (libc.so.6 + 0xd2e58)

要解决此问题，请覆盖 gitea.service：
# systemctl edit gitea

[Service]
SystemCallArchitectures=
SystemCallFilter=

这已经改变了推送输出：

remote: Pre-Receive hook...
remote:
remote: End
remote: Update hook...
remote:
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote:
remote: END
remote: End
remote: Processed 0 references in total

到

remote: Pre-Receive hook...
remote:
remote: End
remote: Update hook...
remote:
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote: e8533d5f096957a7d6298510aec9af8f89fb4e33 28f42c6f8275198abc5856307bd3d024e3759436 refs/heads/master
remote: END
remote: End
remote: Processed 0 references in total

看起来这意味着钩子不再获取标准输入内容没有问题，但仍然没有处理引用。

ltGuillaume picture ltGuillaume 于 2020-09-11

在重新创建 repo（并因此删除脚本）之后，我终于得到了

remote: . Processing 1 references
remote: Processed 1 references in total

此后的每个测试都始终生成一个有效的、完全初始化的 repo。

感谢@zeripath的所有帮助。 抱歉，我自己没有找到核心转储。 正如您所看到的转储链接到cat ，我没想到要寻找类似的东西，我想我应该在您的脚本之后找到它。

ltGuillaume picture ltGuillaume 于 2020-09-11

抱歉拖了这么久。 也许我们需要删除 bash 脚本并编写一些代码来完成它。

zeripath picture zeripath 于 2020-09-11

我不知道。 现在我找到了解决方案，我看到：

https://github.com/go-gitea/gitea/issues/6620#issuecomment -519912187 绝对相关，未正式解决（被 stalebot 关闭）。

https://github.com/go-gitea/gitea/issues/11231似乎还没有解决（被 stalebot 关闭）并且可能有相同的解决方案。

ltGuillaume picture ltGuillaume 于 2020-09-11

好的，如果您可以在此处的评论中写出清晰的解决方案，我们可以关闭此问题并在这些问题上添加指向它的链接。

zeripath picture zeripath 于 2020-09-11

Arch Wiki的以下补充为我解决了以下问题：

  1. 推送提交后，新创建的存储库在 Web UI 中保持为空
  2. 手动将 repos 设置为非空后，repo 大小保持为 0B
  3. 仪表板上没有 repo 更新 (https://github.com/go-gitea/gitea/issues/6620)

用户 Simplefied 在 6 月 6 日添加了此解决方法（https://wiki.archlinux.org/index.php?title=Gitea&type=revision&diff=618524&oldid=615095）。

在 ArchLinux ARM 上处理转储核心

推送新的 repo 后可能会出现问题。 在 web UI repo 中保持未初始化，并且系统日志中存在以下错误：

Jun 06 14:34:20 rpi-srv systemd-coredump[5724]: Process 5722 (cat) of user 986 dumped core.
                                                Stack trace of thread 5722:
                                                #0  0x0000000076f06e58 posix_fadvise64 (libc.so.6 + 0xd2e58)

要解决此问题，请覆盖 gitea.service：
# systemctl edit gitea

[Service]
SystemCallArchitectures=
SystemCallFilter=
ltGuillaume picture ltGuillaume 于 2020-09-11
👍1

谢谢@ItGuillaume真的很抱歉花了这么长时间

zeripath picture zeripath 于 2020-09-11
👍1

@ArchangeGabriel您可以添加：

[Service]
SystemCallArchitectures=
SystemCallFilter=

到systemd服务文件？

zeripath picture zeripath 于 2020-09-11

@zeripath我不想，这是一个安全功能。 首先，它似乎只在 ArchLinux ARM 下失败，所以应该在那里更改而不是在标准 Arch（ARM 变体是一个单独的发行版，它同步我们的大部分 PKGBUILD 但进行特定更改）。 然后，最好确定应该允许的内容（有关文档，请参阅 https://www.freedesktop.org/software/systemd/man/systemd.exec.html#System Call Filtering）而不是允许所有内容。

ArchangeGabriel picture ArchangeGabriel 于 2020-09-11

很公平。

大概 arch arm systemd 对这些值有一些默认设置，这是相对限制性的——我想我们需要一个 arch 用户玩 whack-a-mole 游戏来弄清楚实际需要什么调用。

我会考虑一下我们是否真的可以避免这些 bash 调用——我认为如果我们稍微重组一下，我们应该能够做到这一点。 我不确定这是否一定会减少系统调用问题 - 它可能会减少 bash 无论如何可能会有所帮助

zeripath picture zeripath 于 2020-09-11
  1. 据我所知，包括SystemCallArchitectures=似乎是不必要的。 我不知道是否出于其他原因推荐它，但解决方法没有必要完成它的工作。
  2. 我已经在https://www.freedesktop.org/software/systemd/man/systemd.exec.html文档中为所有指定的集合尝试了SystemCallFilter=+@set ，但这没有做任何事情。
  3. 然后我比较了 Manjaro 和 Arch ARM 之间的systemd-analyze syscall-filter输出，没有发现结果差异：
    Manjaro 显示
# Unlisted System Calls (supported by the local kernel, but not included in any of the groups listed above):
#   mincore
#   seccomp
#   syslog

其中 ARM 在集合@file-system显示了一个额外的调用faccessat2 ，在集合@file-system了一个额外的调用cacheflush @default 。 所以我怀疑通过专门设置SystemCallFilter=+some_call有什么好处，它可能只是一个错误。

callfilters-manjaro.txt
callfilters-pi.txt

ltGuillaume picture ltGuillaume 于 2020-09-12

cat 二进制文件是否有可能是不同的 arm 架构二进制文件，所以问题是 systemd 阻止了调用？

zeripath picture zeripath 于 2020-09-12

cat 二进制文件是否有可能是不同的 arm 架构二进制文件，所以问题是 systemd 阻止了调用？

我认为在这种情况下SystemCallArchitectures=是解决方法运行所必需的。 如前所述，它不是。

我复制了 cat，它在这里。 它说ARM HF ABI:5 ，就像gitea可执行文件一样。
猫.zip

ltGuillaume picture ltGuillaume 于 2020-09-12

这里有一个与 havegd 非常相似的问题： https ://archlinuxarm.org/forum/viewtopic.php =15& t

ltGuillaume picture ltGuillaume 于 2020-09-12

如果我 _only_ 添加以下行（丢弃SystemCallArchitecture=和SystemCallFilter= ），推送提交也有效：

[Service]
SystemCallErrorNumber=EPERM

@ArchangeGabriel我想这会更好，对吧？ 或者这是否意味着以其他方式明确添加SystemCallFilter= ？ 我在文档中找不到，所以我猜它没有。

-------编辑-------

这就是/usr/lib/systemd/system/gitea.service

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
After=postgresql.service
After=memcached.service
After=redis.service

[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=~
RuntimeDirectory=gitea
LogsDirectory=gitea
StateDirectory=gitea
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini
Restart=always
RestartSec=2s
CapabilityBoundingSet=
NoNewPrivileges=True
#SecureBits=noroot-locked
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/etc/gitea/app.ini
PrivateTmp=true
PrivateDevices=true
PrivateUsers=true
ProtectHostname=true
ProtectClock=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=@system-service

[Install]
WantedBy=multi-user.target

因此，没有指定SystemCallErrorNumber 。

我将SystemCallErrorNumber=EPERM到文件中，删除了所有覆盖并且一切正常。

所以看起来我们只需要默认将SystemCallErrorNumber=EPERM放入gitea.service 。

ltGuillaume picture ltGuillaume 于 2020-09-12

@ltGuillaume好想法。

我认为这也可以添加到我们的文档中。

zeripath picture zeripath 于 2020-09-12

我希望这会被接受https://bugs.archlinux.org/task/60669#comment192661 （它被分配给@ArchangeGabriel）

@ArchangeGabriel此外，这个错误确实提到当前的强化根本不是很严格：它使用集合@system-service ，这是一个相当大的超集。 如果您/我们可以更具体地将其限制为 gitea 的任务，那么系统调用强化会更有用。

不过，我的想法是，在 Arch ARM 上，目前在cat周围已经不允许使用当前的@system-service系统调用强化，否则SystemCallErrorNumber就无关紧要了。

ltGuillaume picture ltGuillaume 于 2020-09-12

太好了，看起来一切都已实现。 维基也更新了👍

ltGuillaume picture ltGuillaume 于 2020-09-14
👍1
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

Fastidious picture Fastidious  ·  3评论
tuxfanou picture tuxfanou  ·  3评论
jakimfett picture jakimfett  ·  3评论
BRMateus2 picture BRMateus2  ·  3评论
flozz picture flozz  ·  3评论