Libelektra: 构建服务器的东西

@markus2330

刚刚推送了一些与构建系统相关的修复程序。 但是您还需要在稳定的 debian-stable 机器上修复一些软件包：

• 请从 wheezy-backports 安装 qtdeclarative5-dev（之后可以删除 /opt/Qt5.3.0）
• 请安装 java8 作为包：
  
  
  
  • 使用这个方法： http :
  
  
  • 让cmake真正找到jdk8： cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  
  
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  
  
  • 杀死 + 重新启动本地 jenkins java 进程。 否则所有构建都会失败
  
  
  • 可选：删除 jdk7
  
  

看起来不错，感谢您解决这些问题。

我也在 debian-stable 代理上做了这些步骤。

对于其他机器，安装 qtdeclarative5-dev 是不可能的，因为它与 kde4 所需的 qdbus 冲突。 所以我把之前的脚本configure-debian-wheezy恢复为configure-debian-wheezy-local。

我还在 README.md 中添加了您提到的安装步骤作为注释，因为其他人可能会对它们感兴趣。

感谢您升级代理！

稳定版上缺少的东西

1.) 乳胶（+ 我认为 texlive-latex-recommended 也是需要的）
见http://build.libelektra.org :8080/job/elektra-doc/495/console

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.8") 
CMake Warning at doc/CMakeLists.txt:46 (message):
  Latex not found, PDF Manual can't be created.


-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_EXAMPLES

2.) 你能安装clang吗（对于elektra-clang，wheezy的clang不起作用）？
3.) 你可以为 elektra-gcc-configure-mingw 安装 mingw+wine 吗？

apt install --no-install-recommends doxygen-latex + clang + mingw 完成

为什么需要酒？

顺便说一句，您应该在Toolchain-mingw32.cmake中将i586-mingw32msvc-X更改i686-w64-mingw32-X Toolchain-mingw32.cmake 。 现在这不适用于不稳定。

谢谢你的文档！

需要 wine 来执行交叉编译的 Windows 二进制文件（例如 exporterrors.exe）

我认为您安装了为 w64 构建的 mingw。 在 mingw32 包中，还有一个/usr/bin/i586-mingw32msvc-c++ 。

尽管如此，还是感谢 w64 的新工具链文件。

我安装了gcc-mingw-w64-i686 ，这是 mingw 的 x64 版本，目标是 i686。
包mingw32-binutils已弃用，不再适用于不稳定的版本。

Wine 安装在两个容器上。

实际上，mingw 构建肯定是稳定的，所以这应该不是问题。

MinGW-w64 是 mingw 的一个分支，是一个完全不同的目标。 到目前为止，没有人对其进行测试。

感谢安装 wine

Mingw-w64 看起来更胜一筹。 也许是时候继续前进了:-)

欢迎贡献;) 我没有任何机器来测试它。

恐怕你拿错了wine，应该是apt-get install wine32

另见http://build.libelektra.org :8080/job/elektra-gcc-configure-mingw/218/console

不。

root@debian-stable:~# apt-get install wine32
....
E: Package 'wine32' has no installation candidate

好的， dpkg --add-architecture i386将解决这个问题。 但是您不能将 mingw/wine 工作固定到您的构建机器上吗？ mingw 设置比较特殊。

编辑：我会看看我是否可以使用 mingw-w64 构建 elektra，这样我就不需要安装大量的 i686 库。

问题是我没有备用的 jessie 机器，而且 wheezy 的 mingw 不知道 C++11。

我设法让 mingw-w64 工作。 但是 std::mutex 不可用，因为 Windows 上没有 glibc 并且 std::mutex 依赖于 pthread。 有任何想法吗？

哇谢谢！

它会导致编译错误吗？ std::mutex 不用于内部
功能，但仅在用户要包含的头文件中。 它被使用
不过在测试用例中。

编译问题的一种解决方案是在 mingw 中提供一个 std::mutex
每次尝试锁定/解锁时都会抛出系统错误。 其实我会
期望 mingw 人至少提供类似的东西（例如，当
设置了一些宏，类似于 -D_GLIBCXX_USE_NANOSLEEP）

https://github.com/meganz/mingw-std-threads可能是另一种方式。 但那是
最有可能仅在所有测试用例（涉及 std::mutex 的测试用例除外）时有用
已经运行。

基本上，这只是 C++11 不正确可用的一个实例。

现在的 mingw 状态：

• 将 dlfcn-win32 作为外部项目添加到 libloader。 这样 cmake 检出 + 编译库作为额外的构建步骤。 我正在链接存档以避免额外的 dll deps。
• 将 winsock2.h/ws2_32.dll 依赖项添加到 cpp11_benchmark_thread。 gethostname()-call 需要

现在我正在用-static-libgcc + -static-libstdc++构建。 否则wine 无法找到dll。 额外的互斥锁也不会编译。 我试过 mingw-std-threads。 只是有更多的编译错误:-)

如果我从x86_64-w64-mingw32-X切换到x86_64-w64-mingw32-X-posix std::mutex 编译正常，因为 pthread 内容已定义。 但是，我对 libwinpthread-1.dll 有一个额外的依赖，wine 无法找到它。

我认为我们最好的选择是使用x86_64-w64-mingw32-X-posix 。

再次，我很惊讶你甚至有这个问题。 到目前为止，当我们获得 libelektra.dll 时，我们很高兴。

我不能对这个x86_64-w64-mingw32-X-posix决定说任何话，因为我不使用它，也不知道它的含义。 我想知道这样的 posix-lib 甚至存在，我认为 posix-layer 方法是 cygwin 而不是 mingw。

这个决定甚至对 libelektra.dll 有影响吗？ 如果它仅用于测试用例，则没有人会关心（只要构建服务器能够运行它）。 如果测试用例运行起来，那将是一个巨大的好处。 （请参阅 #270，其中单元测试在 Mac OS X 上发现了一些奇怪的错误）

好像可以下载libwinpthread-1.dll ，不知道wine有没有用？ 您是否也可以像使用 dlfcn-win32 那样将其添加为外部项目（以便所有 dll 都以相同的方式处理）？ 否则，如果您需要为测试下载 1 或 3 个 dll 可能并不重要（同样，我不是用户，并且不了解 Windows dll 的部署概念（如果有的话））。

@beku你怎么看？ 您有时间在 Windows 上与 oyranos 一起测试我们最新的 0.8.13 mingw-w64 版本吗？

通常是否为 mingw 构建作业启用测试？ 昨天他们都被禁用了。

是的，他们被禁用了。 但是像cpp11_benchmark_thread这样的 afaik 示例/基准也被禁用了。 所以我认为你改变了它并编译了比以前更多的东西。

我在启用 C++11 的情况下编译了整个 repo。 而已。

但是，只要您将所需的 dll 复制到 bin 目录，像 bin/basename.exe 这样用 -posix 构建的可执行文件就可以正常运行（感谢 Windows 没有 RPATH）。 我还没有找到 a) 让 cmake 找到 dll 目录 + b) 将 wine 指向 dll 目录的方法。
我认为静态链接会起作用，但是在链接 elektra dll 期间构建失败并出现重复的符号。 因为dll已经包含了符号。

@markus2330我设法让 elektra 用 mingw 编译 + 用 wine 运行而不复制任何 dll。 诀窍是始终为可执行文件和共享对象启用静态链接（ CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static "）。

为了解决重复的符号，我为 libelektra 和 libelektratools 添加了版本脚本。 这样只有我们的符号被导出。

这真的很好用。 例如

$ wine64 ./bin/kdb-static.exe
Usage: Z:\home\manuel\build\bin\kdb-static.exe <command> [args]

Z:\home\manuel\build\bin\kdb-static.exe is a program to manage elektra's key database.
Run a command with -H or --help as args to show a help text for
a specific command.

Known commands are:
check   Do some basic checks on a plugin.
convert Convert configuration.
cp      Copy keys within the key database.
export  Export configuration from the key database.
file    Prints the file where a key is located.
fstab   Create a new fstab entry.
get     Get the value of an individual key.
[...]

$ wine64 bin/cpp_example_iter.exe
user/key3/1
user/key3/2
user/key3/3

甚至 bin/cpp11_benchmark_thread.exe 也能工作。

其他事情只是崩溃：

$ wine64 ./bin/kdb-static.exe get
wine: Unhandled page fault on read access to 0x00000000 at address 0x7fd0e8b62c8a (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fd0e8b62c8a).
Register dump:
 rip:00007fd0e8b62c8a rsp:000000000033f428 rbp:0000000000000000 eflags:00010293 (  R- --  I S -A- -C)
 rax:0000000000000000 rbx:000000000033f700 rcx:0000000000000000 rdx:000000000033f5b0
 rsi:0000000000000000 rdi:0000000000000000  r8:0000000000000000  r9:0000000000000072 r10:0000000000000000
 r11:000000000003f615 r12:000000000033f5b0 r13:00000000000373b0 r14:0000000000000000 r15:000000000033f930
Stack dump:
0x000000000033f428:  00007fd0e748ea93 0000000000000000
0x000000000033f438:  0000000000000000 0000000000000000
0x000000000033f448:  0000000000000028 0000000000010020
0x000000000033f458:  8d98315017c96400 6f46746547485300
0x000000000033f468:  687461507265646c 0000000000000000
0x000000000033f478:  0000000000000000 0000000000000000
0x000000000033f488:  000000000003fab0 0000000000030000
0x000000000033f498:  8d98315017c96400 6f46746547485300
0x000000000033f4a8:  687461507265646c 0000000000000000
0x000000000033f4b8:  0000000000000000 0000000000000000
0x000000000033f4c8:  0000000000000000 0000000000000000
0x000000000033f4d8:  0000000000000000 0000000000000000
Backtrace:
=>0 0x00007fd0e8b62c8a strlen+0x2a() in libc.so.6 (0x0000000000000000)
  1 0x00007fd0e748ea93 MSVCRT_stat64+0x92() in msvcrt (0x0000000000000000)
  2 0x00000000004744af in kdb-static (+0x744ae) (0x000000000003f9d0)
  3 0x000000000043bda5 in kdb-static (+0x3bda4) (0x000000000003f9d0)
  4 0x0000000000431d76 in kdb-static (+0x31d75) (0x00000000000360a0)
[...]

现在我只是简单地添加了版本脚本的东西，而没有考虑其他编译器。 我是继续我的工作还是不感兴趣？

在 src/plugins/wresolver/wresolver.c 中崩溃，因为 pk->filename 为 NULL

pk 是resolverHandles.user

我试图看一下插件，但我无法理解elektraWresolverOpen的 for 循环。 循环调用elektraWresolveFileName --> elektraResolve{Spec,Dir,User,System}所有 malloc resolverHandle->filename并因此泄漏内存。

感谢您指出了这一点！ 自从c87ae8e87a716b02b2c7ed790ad56a89d95547a9中引入以来，代码显然被破坏了
仅在循环期间并且始终初始化系统句柄。 当使用另一个命名空间时，这会导致崩溃。

我把它修好了
edb4d50856bb5331749220de5a83fa2062624a9d

关于继续工作：一方面，如果编译的东西也能运行，那就太好了。 另一方面，发布应该在本周末发生，因此拉取请求很快就会很重要（至少应该有一个简短的反馈圈的机会，例如版本脚本实际上做了什么）

但是恕我直言，如果只有一种变体（静态编译）有效就足够了。 很高兴看到 kdb-tool 正在运行！

我在哪里可以找到 edb4d50856bb5331749220de5a83fa2062624a9d？

edb4d50856bb5331749220de5a83fa2062624a9d 被推迟了一点。

debian-unstable-mm 上安装了哪些 gcc 版本？

http://build.libelektra.org :8080/job/elektra-multiconfig-gcc-unstable/build_type=Release,gcc_version=5.2,plugins=ALL/56/console

说没有 gcc-5.2

你能安装尽可能多的编译器吗？

在某些问题或 PR 中，我说过我已经删除了除最新版本之外的所有编译器。
编辑：gcc 4.9 稳定版，4.9 + 5.x（默认）不稳定版

请在您自己的容器上进行此类测试（无论如何我发现它们非常不必要）。 反正我的不会永远留下。

我没有读过。 他们每个人可能有 50MB。 你能重新安装它们并回答第一个问题吗？

也许我在我们的会议上告诉过你。 但我肯定告诉过你。

debian-unstable:~ # gcc -v 2>&1 | tail -n 1
gcc version 5.2.1 20150903 (Debian 5.2.1-16)

特定于版本的二进制文件称为 gcc-5。 没有单独的小版本包了。 因此，具有这种详细程度的 multiconfig-gcc 有点过时了。 我建议删除 gcc 4.7 并用 gcc-5 替换 gcc-5.2 并完成。

我尚未安装的唯一可用的附加编译器是 gcc-4.8。 并且 gcc-4.8 已经被标记为删除。

谢谢（你的）信息！ 许多可用编译器的辉煌时代似乎已经结束。

我修复了 multiconfig-unstable。

我将暂时关闭，感谢出色的代理设置。

你好， jessie (stable) 需要更多的包。 请问可以安装：

• [ ] 假根
• [ ] gpg（+ 为 Autobuilder [email protected] 创建密钥）
• [ ] reprepro（可能已经安装，脚本还没有到此为止）

安装了 fakeroot，gpg + repropro 已经安装。
你能把你已经存在的 gpg 密钥邮寄给我吗？ 所以两台机器都有相同的

可以有不同的 gpg 密钥。 我不确定当前设置是否完全使用它们，因此请先等待http://build.libelektra.org :8080/job/elektra-git-buildpackage-jessie/2/ 失败。

• 安装了 debhelper + libsystemd-journal-dev
• python-dev 是一个错误的依赖项。 它应该是 python2.7-dev 或 python3-dev 或两者
• 为什么我们需要python-support？

感谢安装！

python-dev可用于 Jessie，也可用于python-support 。 请安装它们。

我在本地对其进行了测试，安装这些软件包后，它会为 jessie 构建。

当然，它是可用的，但它是一个错误的依赖项。 python-dev 依赖于 python2.7-dev，这是_不_足够的。 相反，需要 python2.7-dev + python3-dev。

恕我直言，根本不需要python-support。

我不知道为什么选择这样的依赖项，大部分打包是@iandonnelly在 gsoc 期间完成的。

是的，这些包也应该更新以构建 python3 绑定。 目前，它根本没有完成。 不过，你可以安装 python3-dev，这样构建就不会中断（当 python3 绑定+插件被添加到 debian 包时）。

这并不意味着它们是正确的 :-) - 我对 python-dev deps 相当确定。
你能更换它们并删除python-support dep吗？

python3-dev 和 python2.7-dev 已经安装。 否则不会建立绑定。

顺便提一句。 来自@pinotree的官方 debian 包@pinotree的工作

当我有时间时，我会将我们的“debian”分支更新为@pinotree在官方包中所做的。 他已经允许我们这样做了。 我会等待qt-gui更新，目前不急于更改。 并且拥有 python2 支持对于一个安装很重要（使用猎豹的地方，它不适用于 python3）。

我从来没有说过我会删除 python2 包。 我要说的是 python-dev 是一个不准确的依赖项。 我们需要显式版本。 所以 pythonX-dev 是正确使用的 dep。

希望 pinotree 正确计算出依赖关系。

顺便说一句，猎豹死了。 不要使用它。

好的，换了。 如果毕竟需要，请恢复 b7c266b36b0ab0fad9120e67a457b580c7c44690 并安装 python-support。

我确信 pinotree 做对了 ;)

它说： dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org :8080/job/elektra-git-buildpackage-jessie/3/console

已安装

python-dev 是一个错误的依赖项。 它应该是 python2.7-dev 或 python3-dev 或两者

• python-dev安装默认 Python 2 版本的开发包； 从 Wheezy 开始，这是 Python 2.7
• python3-dev安装默认 Python 3 版本的开发包； Wheezy 中的 Python 3.2，Jessie 中的 3.4，到目前为止仍然是 3.4 中的 Stretch（我想很快就会是 3.5）

因此，如果您想针对默认的 Python 2/3 版本进行构建，请分别使用python-dev / python3-dev ，而不是pythonX.Y-dev版本（您需要在明确想要安装一个精确的 Python 版本，即使不是系统上唯一安装的版本，也不是默认版本）。 使用任何一种都是我推荐的。

来自python-dev描述：
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

根据本文，python-dev 很快就会依赖 python3

更进一步：永远不会有另一个 python2 版本。 所以 python2.7-dev 将是有史以来最后一个 python2 dev 包。

我说的是依赖于 python3-dev。

现在只缺少密钥：

gpg: new configuration file `/home/jenkins/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/jenkins/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/jenkins/.gnupg/secring.gpg' created
gpg: keyring `/home/jenkins/.gnupg/pubring.gpg' created
gpg: skipped "Autobuilder <[email protected]>": secret key not available
gpg: /tmp/debsign.DlSdnFtB/elektra_0.8.13-1.41.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/08C91995 2015-09-30
      Key fingerprint = BA4C 688E 9071 FD3F 57ED  E9D6 D0A9 EDB9 08C9 1995
uid                  Autobuilder <[email protected]>
sub   2048R/E69F110A 2015-09-30

完毕

谢谢！

请通过 http 导出 /home/jenkins/repository。

cannot access /home/jenkins/repository: No such file or directory ?

→ http://194.117.254.29/elektra-stable/

@manuelm你能在代理上安装ronn吗？ （生成手册页需要）

apt-get install ruby-ronn

完毕

谢谢，jessie 包再次构建，现在包括手册页！

请安装musl，即

apt-get install musl musl-dev musl-tools

谢谢！

安装了 musl 并升级了代理

关于构建服务器的两个重要事项：

1. 不要创建新的空作业，而是复制它们，它们具有正确的设置（除了数字 2 中提到的内容）。
2. 我们应该使用参考克隆（在 /home/jenkins/libelektra 中）或者更喜欢为每个构建作业使用浅层克隆（目前只为某些构建作业完成，例如 elektra-clang）。 由于许多不必要的重新克隆，目前提交时的流量> 300MB。

@mpranj如果您能修复 2，那就太好了。

@markus2330只是为了确保：我应该将相同的克隆行为应用于所有构建作业，就像在elektra-clang ？

适用于所有构建作业的浅克隆，除了：

• [] elektra-git-buildpackage-jessie
• [] elektra-git-buildpackage-wheezy
• [] elektra-multiconfig-gcc-stable
• [] elektra-multiconfig-gcc-unstable
• [] elektra-source-package-test

这些作业签出到某个子目录。 不确定你想要什么，所以我暂时保留它们。

谢谢！ 是的，他们需要完整的历史和分支，浅克隆没有意义，但参考克隆存储库会很有用。

Jenkins 已更新至 1.651.2。 还更新了所有插件。

我将为参考克隆存储库保留该问题。 我们还应该有“cron 作业”不时更新存储库，最好使用 jenkins 本身。

詹金斯停止构建一些工作（因为更新显然）。 它失败了
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

谢谢（你的）信息。 我尝试将 github 请求构建器从 1.31 降级到 1.14。

现在在为 Github 提交设置构建状态时似乎卡住了。 它确实警告说这在配置中已被弃用。

我还尝试将名称中带有*git*每个插件降级，但是仍然出现错误（与 Mailer 插件相关的奇怪错误，Mailer 插件的降级没有帮助）。 所以我再次将所有内容更新到最新版本。 该问题似乎是上游的一个已知问题：

https://github.com/janinko/ghprb/issues/347

我希望他们能尽快修复它。

另一个问题：有人知道如何为每个 PR 运行多个作业吗？ （我想同时运行 elektra-mergerequests-stable 和 elektra-mergerequests-unstable）

elektra-test-bindings作业与参数化构建一起工作正常（如上游票据中所述）。 我们不能把它切换到参数化构建吗？ 该错误已在上游报告了一段时间，我认为它不会很快修复。

好主意，我们可以将所有 PR 作业更改为参数化构建，它实际上只有优点。 它也允许我们通过指定分支来手动运行作业。 它也可用于常规构建作业。

理想情况下，每个工作也可以由 github PR 执行。 （除了那些专门用于更新文档或主分支覆盖范围的非 PR 任务）

elektra-test-bindings 配置的一个缺点是它只进行轮询并且需要很长时间才能开始构建（最多 5 分钟）。 但是，我不想激活“使用 github 挂钩进行构建触发”，以免破坏构建工作。

顺便提一句。 您确定 github pullrequest builder 作业可以使用“浅克隆”选项吗？

我想知道 github 如何选择它用于新 PR 的构建作业。 为什么从来没有为新 PR 选择 elektra-test-bindings 和 elektra-ini-mergerequests？ 为什么有时 elektra-mergerequests-unstable 和有时 elektra-mergerequests(-stable)？

@manuelm你有什么想法吗？

顺便提一句。 不知何故，完成的构建作业和 github 的通信严重受损（即使对于 elektra-test-bindings）。 现在几乎在每个构建中都说“有些检查尚未完成”。

elektra-test-bindings 配置的一个缺点是它只进行轮询并且需要很长时间才能开始构建（最多 5 分钟）。

这是一个问题，因为？ 无论如何，测试需要超过 5 分钟。

为什么从来没有为新 PR 选择 elektra-test-bindings 和 elektra-ini-mergerequests？

为什么要呢？ elektra-test-bindings仅由“触发短语”触发。 不知道elektra-ini-mergerequests是什么。

为什么有时 elektra-mergerequests-unstable 和有时 elektra-mergerequests-stable？

-stable/-unstable 是新的吗？ 我不确定每个新 PR 触发多个工作是否可能。 我会做副业。

顺便说一句，我已经说过几次了，但我认为工作量越来越荒谬，而且是配置混乱的迹象。 但是批评总是比解决问题容易。

当您想要调试构建服务器时，5 分钟是一个问题。 我仍然希望我们能在某个时候进行快速的第一次测试，大约需要 5 分钟。

啊，好吧，我错过了“仅使用触发短语进行构建触发”选项。 github 请求构建器的配置真是一团糟。

有人谈到 github 项目，他们为每个 PR 运行多个作业。 （单独显示）

什么是子作业？ 你的意思是multijob吗？

有人谈到 github 项目，他们为每个 PR 运行多个作业。 （单独显示）

您必须在 github 上添加两个服务。

什么是子作业？ 你的意思是多任务？

是的，多任务。

顺便说一句， https: //docs.travis-ci.com/ 怎么样？ Travis 支持 OSX。

我知道它不会取代 jenkins，但可能会在每次提交构建时取代 PR/。 詹金斯仍然可以做多个编译器/等......测试。
编辑：Travis 甚至有 gcc + clang。

同意，免费使用他们的 CPU 功率/电力会很有趣，因为 elektra 是开源的。

很可能 github 和 jenkins 之间的连接实际上是 1:1。 在 github 服务中，我输入了http://build.libelektra.org :8080/github-webhook/ 并且我没有找到在 jenkins 中创建另一个 URL 的方法。 （我只找到了一种如何指定覆盖的方法，但这并没有创建新的 URL）。

在https://github.com/janinko/ghprb/issues/142他们讨论它应该“正常工作”吗？ （不添加多个服务）

但是，sha1 问题现在应该解决了。 它被破坏是因为 Jenkins 引入了一种新的安全措施，可以修剪未知的环境变量。 我固定它的建议（加入-Dhudson.model.ParametersAction.safeParameters = ghprbActualCommit，ghprbActualCommitAuthor，ghprbActualCommitAuthorEmail，ghprbAuthorRepoGitUrl，ghprbCommentBody，ghprbCredentialsId，ghprbGhRepository，ghprbPullAuthorEmail，ghprbPullAuthorLogin，ghprbPullAuthorLoginMention，ghprbPullDescription，ghprbPullId，ghprbPullLink，ghprbPullLongDescription，ghprbPullTitle，ghprbSourceBranch，ghprbTargetBranch， ghprbTriggerAuthor,ghprbTriggerAuthorEmail,ghprbTriggerAuthorLogin,ghprbTriggerAuthorLoginMention,GIT_BRANCH,sha1 到 /etc/default/jenkins）。

关于额外构建服务器的使用：是的，继续。 它还解决了单个 PR 的多个构建作业的问题；) 我从来没有使用过 travis-ci，所以不能说什么。 我允许 travis 访问 ElektraInitiative。

第一个 travis 构建： https :
我认为我们需要一些 yaml 文件，以便 travis 知道该怎么做。

我想出了如何为每个 PR 执行多个 jenkins 工作，每个构建工作都需要不同的上下文。 在下一次会议中，我们将讨论“快速”和其他构建作业应该做什么。

我正在研究 travis（或检查一些东西）

玩得开心。 Travis 还添加了一个 github 服务，所以我猜也会用 travis 构建一个 PR。

我已经大声发誓

-- 找不到 JNI（缺少：JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH）
-- 排除插件 jni 因为找不到 jni

我无法正确配置 java 插件。 但是 Java 绑定有效。 在 debian 上不稳定。 有任何想法吗？ 查看 cmake 模块并没有多大帮助。

编辑： /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h 、 /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h和/usr/lib/jvm/java-8-openjdk-amd64/include/jni.h已就位

编辑2：明白了。 JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/ ....

https://travis-ci.org/manuelm/libelektra/builds/130638376

在 docker 容器中构建的 Debian 不稳定。 但是建造需要很长时间。
有什么好主意吗？

clang 在构建时间方面通常更快，但我认为依赖项的安装需要大量时间

没有比使用的更小的 debian docker 镜像吗？ 似乎安装了很多不需要的软件包。

@sirblackheart是什么让你这么想？ https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm可能是 dist 升级。 许多软件包都得到更新，这些软件包是特定于桌面的，例如 wayland

号 dist 升级很短。 也许一分钟。 大约 50% 的时间是通过安装构建依赖项花费的。

我现在正在将构建映像推送到 hub.docker.com。 希望这会加快速度。 但图像有 1.9GB

已用时间 14 分 8 秒

不确定我们是否可以做得更好

就像我说的，clang 可能会让我们花 2-3 分钟。 至少它适用于 aseprite 项目
https://travis-ci.org/aseprite/aseprite

无论如何，同时拥有两个编译器会很有用。

刚准备工作时有个想法：如果我们提取推送请求中所有提交的路径并仅在它们受到影响时构建绑定/插件怎么办？ 例如

• cmake/* 中的更改会触发所有内容（插件 + 绑定）
• src/bindings/foo 的变化触发绑定 foo
• src/plugins/foo 中的更改会触发插件 foo
• 一切的改变都不会编译任何插件 + 绑定

我们仍然每天/每天两次完全建立在 jenkins 上。

@manuelm好主意，@tom-wa 会写这样的脚本，你能为此创建一个新问题吗？

@mpranj ：提醒：将 Mac OS X 构建添加到 travis 并将 mingw 构建添加到 PR。 (*BSD好像比较费劲)

@markus2330现在我理解@manuelm docker方法，travis 直到明年才会支持 ubuntu 16.04，因此需要 docker 来获取 ubuntu 14.04 没有的所有依赖项 = swig3.0 libsystemd-devel。

很抱歉我不能参加今天的会议。 在工作中，我们今天仍在准备大规模的软件部署，所以我不能离开办公室。 但在很短的延迟内，我可以回复电子邮件。

我两天前开始为 travis 添加 OS X 版本： https :
构建在这里： https :
在这里打开东西：

• [] cryto_openssl 无法编译
• [] 绑定测试失败
• [] 没有 Java

如果有人会从这里承担我的工作，我很高兴。 我没有 OS X，等待 travis 检查 OSX 系统总结得非常快。

回复：docker：是的，travis 默认的 ubuntu 版本不能正常工作。 甚至 cmake 也太老了。
获取上传的 docker 镜像只需要大约 3 分钟。 添加更多图像是毫无疑问的。 所以我认为这是解决默认 travis linux 环境（或更新后可能有）的任何陷阱的好方法。

我还没有找到将 libelektra (cmake + make + make test) 的不同构建和测试阶段与 docker (build + run) + travis (before_install, before_script, script) 集成的好方法。 命令完成后 Docker 容器退出。 由于 docker 容器是一次性的，因此您无法在之后恢复。 因此，除非您将本地目录安装到容器中，否则您的磁盘/编译状态将消失。 下周将继续在 docker 上工作。

@manuelm太好了，你比我们想象的更进一步。 用于 PR 和每次提交的 Mac OS X 真的很棒。 现在很多人都在使用 Mac OS X，我不想一次又一次地破坏他们的构建。 在今天的会议上@mpranj说他会接你的工作。 你想用 travis 文件创建 PR 吗？

不，因为之后仍然需要修改 travis 文件。 否则它只会构建 OS X。 我宁愿@mpranj占用我的 travis 文件并修复其余的 OSX 相关问题。 然后我将获取他的 travis 文件，将其转换为矩阵构建并集成 linux/docker 构建 + #730（如果届时可用）

PS：请在 usernamespaced repo 中进行 travis 测试。 你会做很多推:-)

mingw64 建立在 PR 的基础上，应该可以工作。 抱歉耽搁了。 我今天要研究特拉维斯！

使用 PR 中的短语（使用 Github PR 构建器）启用构建作业是否有不利之处？

我想从 #745 配置作业，以便我可以测试我是否修复了它，但我可以将它应用于大多数/（所有）构建作业。

编辑：我不想自动开始所有工作，我们已经有很多工作了。

如果我们可以将每个作业配置为用短语触发，我认为这是一个好主意。 我认为有一个小的缺点（至少对于 elektra-test-bindings）：您必须输入要构建的分支，而不能简单地按“立即构建作业”。 如果您找到解决方案，那就太好了。

你说得对，我们应该减少自动作业。

其实有一个非常简单的解决方案。 我们使用 (env) 变量sha1来构建 PR。 参数化构建会提示您输入值，无论是否设置了默认值。

解决方案：将环境变量sha1为master （在 jenkins 配置本身中）并禁用参数化构建。 如果不反对设置变量，这将完全解决您上面提到的@markus2330。

我已经设置了它，所以你可以点击例如elektra-mergerequests上的构建按钮，它就会开始构建主。

是的，这是一个非常好的解决方案，我喜欢它。 它还允许我们使用单个开关构建一个发布分支（如果我们将来需要一个）。 在那之前，如果不在 PR 中执行，“master”始终是正确的选择。

我认为它也可以解决过滤环境变量的问题，我们之前有过。

然后我们还可以考虑减少构建作业（-mergerequest bulid 作业没有重复）和新的一致命名模式。 （建议可以在这里完成。）可能有一个开放性问题：目前我们为 PR 和 master 构建coverage、docu、.. 并将它们复制到不同的地方。 如果我们合并构建作业，我们需要一种方法来区分作业主/公关作业中的复制覆盖范围、文档到不同的地方。

我几乎完成了将它应用于所有作业（但服务器 _just_ 变得非常慢）。
不适用于构建通配符**的工作（文档和其他一些，但很少）

如果您稍后重新启动它们（发布时间除外），您可以随时停止构建作业。 通常，jenkins 本身就是机器变慢的原因。 目前，来自备份的 rsync 可能是问题所在，但它很紧急。

是的，完全没问题，应该完成，但我会做一些最后的检查。

新闻@ElektraInitiative/elektradevelopers：

• 正如前面提到的，几乎所有的东西现在都可以从 PR 和/或只点击构建按钮来构建
• 触发短语始终是不带elektra-前缀的作业名称。 （如ELEKTRA-铛：詹金斯构建铛请）我没有改变jenkins build please等老短语遗留原因
• github 构建状态消息始终是构建作业名称

谢谢，干得好！ 请更新 doc/GIT.md 以便每个人都知道现在哪些短语有效。

（我希望@mention仅适用于一条消息，而不是每个人都会阅读我们在这里写的每条消息）

用于 xcode 6.1 构建的 Mac OS X 似乎已损坏：
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

我为那个触发了重新构建，但在我看来这就像一个临时的 travis 失败。

你能记录下如何重新触发 PR 的构建吗？ 我不知道这是可能的。

直接在 travis-ci.org 上，使用上面的链接：

我怀疑这是否值得记录，但我仍然可以这样做。
由于 git checkout，构建仍然无法正常工作。 我不认为这是我们的错。

啊。 我认为您在首先触发/开始构建之前合并了它。
当我重建其他以前成功的 PR 时，它也被破坏了。

这更像是一个 travis 问题。

好的，谢谢你的调查。

@manuelm debian-stable-mm 似乎无法访问（对于 jenkins 和来自 TU 网络的我）。 你能调查一下吗？

Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Removed slice User and Session Slice.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Graphical Interface.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Multi-User System.
etc..

看起来有人停止了容器。 我又开始了。

顺便说一句，从明天早上开始，我将离开家直到 8 月 1 日。我仍然可以通过电子邮件联系到，但预计会有短暂的延迟。

感谢您的快速修复！ 所以我想你也不会参加下一次会议。

是的

一些工作有错误：

Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.

例如http://community.markus-raab.org :8080/job/elektra-icheck/lastFailedBuild/console http://community.markus-raab.org :8080/job/elektra-doc/lastFailedBuild/console

它可能是由 jenkins 更新或@KurtMi创建kdb_import_man分支引起的？

自己注意：需要安装cppcms。

对不起分支，我直接在github页面上发了一个PR。

以这种方式创建 PR 是否更容易？ 合并后，github 不提供删除分支吗？

变化如此之小，所以我变得懒惰了。 对于非常小的修复，是的，但显然分支之后不会被删除。 合并后我没有看到任何删除分支。

我认为不稳定的构建被破坏了：

Cloning the remote Git repository
Cloning repository git://github.com/ElektraInitiative/libelektra.git
 > git init /home/jenkins/workspace/workspace/elektra-mergerequests-unstable # timeout=10
Fetching upstream changes from git://github.com/ElektraInitiative/libelektra.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: The remote end hung up unexpectedly

完整日志

@KurtMi再次不稳定工作（在大多数构建中），但 Walk 错误在一些更简单的构建作业中仍然存在。 似乎该分支仍在某处可用，也许在构建服务器的缓存中？

 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/* --depth=1
Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.
org.eclipse.jgit.errors.RevWalkException: Walk failure.

@mpranj也许我们应该在源代码中添加更多脚本，这将使每个构建作业的更新更容易。 在 #806 中，我们在构建目录中发现了另一个带有空格的错误，因此我们应该全局添加（对于每个构建作业）在构建目录中添加空格。 我希望我们可以添加一个脚本jenkins-setup来导出一些有用的变量（例如export HOME="$WORKSPACE/user space ）并且

mkdir "build space"
cd "build space"

此外，我们应该创建更新一个全局存储库的构建作业。 个人任务见上。

全球回购肯定有助于减少带宽。 在源代码中构建脚本也是一个好主意，至少它们会被 git 跟踪。

我不喜欢路径中的空格，但可以肯定。

快速构建 passwd 坏了？

快速构建工作很烦人，我尝试在每次构建时删除 kdberrors.h，然后看看它是否更顺畅。 从长远来看，#730 中的@manuelm提议是最好的解决方案：我们应该简单地检查源是如何更新的，并基于此进行适当的测量。

我认为 #894 也修复了快速构建，我将注释掉 kdberrors.h 的行。

某些作业已损坏，例如 html doc 作业。

@mpranj你有时间看吗？

@markus2330完成。 其余的构建失败似乎与构建系统无关。

@mpranj谢谢！ 你做了什么来修复它？ 我认为如果我们在这里收集构建服务器问题的解决方案会很有用。

我在“源代码管理”>“Git”中更改
“分支说明符”值“**”到“${sha1}”

这也是我们在其他工作中使用的。 这允许通过按钮（分支默认为 master）或通过 github PR 构建器（提交的 sha1）触发构建。

我记得曾经将 ENV 变量“sha1”设置为“master”。 现在似乎丢失了，但工作正常，所以让我们忽略它。

我认为我们可以通过更频繁地使用对象库来加快构建速度。 许多目标文件被多次编译。 我们只需要确保我们使用对象库的每个地方的编译标志都相同，但我想这应该很容易实现。

在我看来，KDB 是一个可以产生重大影响的例子。

@Namoshek请只在这里发布构建 _server_ 的东西，而不是一般的构建系统。 对象库已经用于插件，但是对于不同的变体，仍然需要不同的对象库（因为不同的编译器标志）。 但是请将具体建议作为单独的问题报告（您是指 kdb 工具吗？）。

Jenkins升级到2.7，所有插件升级，新增推荐插件：

• 管道（安装好像失败了？）
• GitHub 组织文件夹插件

并卸载了一些插件：

• 分支API
• CVS/SVN（似乎不再必不可少）

此外，每个代理上都安装了 ruby​​-dev。

我更新了顶帖中的“当前问题”。 重要的是 Elektra 也可以在没有安装任何依赖项的情况下进行编译，因此我们应该使用没有安装任何依赖项（cmake 和 build-essential 除外）的构建服务器代理来检查这一点。 然而，FreeBSD 和 OpenBSD 构建代理也很重要；)

@mpranj你知道 elektra-multiconfig-gcc47-cmake-options 有什么问题吗？ 他们有“致命的：引用不是树：”错误。 他们的工作在其配置中有“sha1”？

我使 multiconfig 独立于具体编译器（对于特定编译器有足够的其他构建作业），因此它们应该能够在任何代理上运行。

@markus2330不知道。 我没有改变任何东西，只是：

• 从 master 手动触发构建
• 从 github 触发构建

两个构建都能够检查树并开始构建。
所以：我无法重现它。

一个想法：当有 PR 时，travis 遇到了问题，你在 travis 可以进行克隆之前合并它。 也许elektra-multiconfig-gcc47-cmake-options发生了类似的事情，因为那里的构建需要大约 3 小时。

将工件推送到 doc.libelektra.org 再次起作用，Jenkins 和插件已升级。

我在 github 的 Webhooks 中更新了新的构建服务器 URL https://build.libelektra.org 。 所以希望下一个 PR 将再次构建。

詹金斯的家几乎满了。 它似乎也不是在构建 PR。

詹金斯的家几乎满了。

谢谢我调整了它。

它似乎也不是在构建 PR。

你知道这里有什么问题吗？ 手动触发似乎有效？

将文档发布到 doc.libelektra。 org:12025构建失败。 我重新启动了 ssh 服务器（在 build-homepage 代理上），它似乎又可以工作了。

*.libelektra.org 的虚拟服务器似乎无法访问。 我在hetzner报告了它。

关闭容器的网络连接的原因是 libelektra.org 受到了威胁。 有关更多信息，请参阅 #1505。

如果我们可以为拉伸添加一个 git-build-package 那就太好了，有越来越多的地方出现我们需要为拉伸构建的 debian 包。

@BernhardDenner你看过上面的帖子了吗？ 有什么可以轻松做到的吗？ 将来改进构建服务器作业时， @mpranj需要考虑什么吗？

根据@sanssecours 的要求，我（暂时）禁用了 elektra-mergerequests，以便 PR 不会总是出现错误错误。 此外，我为@KurtMi添加了

jenkins 请构建gcc-configure-debian-optimizations

@KurtMi如果您需要更改构建作业的功能，只需修改 scripts/configure-debian-optimizations

@sanssecours现在也可以访问构建服务器。

顺便提一句。 如果它们被其他作业取代，您可以取消作业（当前负载很重）。 只注意不要中止活动 PR 的工作，否则 PR 不会变绿。 （除非你用短语“jenkins build ... please”重新启动它们。）

@sanssecours Jenkins 重新启动（第二次）。 如果您安装新插件，请在此处记录。 （更新不需要记录）。

重启请求也可以在这里完成。

我将“静默期”从 2 更改为 5，以便有更多时间合并多个 PR 和/或推送不同的提交，而无需重复重建。

此外，我打开了描述构建超时的问题 #1689（由于错误消息很长，我没有在此处添加它）。

我还在新部分“过时/不相关的问题 [原因]：”中移动了一些过时的任务。

我更新了构建服务器上的插件。 希望更新可以解决我们在 PR #1698 和 PR #1692 中遇到的问题。

@markus2330你能重新启动构建服务器吗？

我将 Jenkins 从 2.73.2 升级到 2.73.3 并重新启动 Jenkins。

希望更新可以解决我们在 PR #1698 和 PR #1692 中遇到的问题。

这可能是一个与这两个 PR 无关的普遍问题？ 希望它现在已修复。

看起来JENKINS_HOME快满了😢。

@markus2330 👋 请问可以吗

• 清理主目录或告诉我我该怎么做，
• 更新 Jenkins 和所有过时的插件？

谢谢你ping我！

好像一个插件有一个“任意文件读取漏洞”，即“Script Security Plugin 1.35”。

我升级了所有插件并将 jenkins 从 2.73.3 升级到 2.89.1。

此外，我将磁盘从 20GB 调整为 50GB。

我们应该尽快重启服务器，有一些未重启的进程可能会受到库升级的影响，目前可能不安全（不过与 jenkins 无关）。 @BernhardDenner你能重新启动吗（如果没有启动就做修复）？

请不要犹豫，报告我在这些升级过程中遇到的任何问题。

服务器的负载为 20，几乎没有响应。 我们需要小心“jenkins build all please”，从长远来看，我们应该将代理从主服务器移开。

我升级到 Jenkins 2.89.2 并重新启动了服务器。 当一切恢复正常时，我会报告。

似乎所有代理现在都因错误“验证器回调未接受服务器主机密钥”而断开连接。

@BernhardDenner我看到 puppet apply 正在运行，您目前是否在进行设置？

我尝试降级到 2.89.1 和 2.73.3 没有任何成功：连接到代理仍然不起作用。

非常感谢@BernhardDenner解决了 ssh 问题。

我们应该在不阅读发行说明的情况下停止升级 Jenkins，似乎即使是稳定的更新也会破坏太多东西。 （甚至不能通过降级来恢复！）

我必须报告构建服务器的主要瓶颈。
elektra-multiconfig-gcc47-cmake-options需要 14 小时，然后
elektra-multiconfig-gcc-stable需要 4 小时。
我不确定这是否是一种新行为，我知道这些作业不是单一的构建作业，但不应忽视这个瓶颈。

感谢您的举报。 想法是将这些作业的子作业分发到 ryzen 硬件，不幸的是没有人有时间进行设置。 如果有人有兴趣，请与我联系。

a7.complang.tuwien.ac.at (ryzen) 似乎崩溃了。 我报告了这个问题。 我们的管理员希望在星期一重新启动计算机。

我暂时禁用了增量（奇怪的错误，参见#1784），管理员重新启动了 ryzen 服务器，然后我重新启动了 jenkins（因为 Jenkins 无法连接到 ryzen 并且有大量的 ryzen 构建积压）。

ryzen 现在再次工作并构建积压工作。

这个想法是将这些工作的子工作分配给 ryzen 硬件

@markus2330我注意到在Run each configuration sequentially的选项。 如果我们简单地取消选中它，它可能会自动分发，以便它一次构建多个配置选项，或者您是否已经尝试过？

不，我没试过，请试一试。

@markus2330从构建服务器队列来看，这似乎可以解决问题，在 gcc-stable-multiconfig 工作后，我会将它应用到 gcc-stable

然而，我注意到 ryzen 似乎无法处理这些工作。 我认为这是因为它被配置为仅处理与其标签匹配的作业，而乍一看，multiconfig 构建似乎没有适当地设置这些标签。 因此，我们应该让 ryzen 执行所有可能的操作，或者在构建作业上设置更多标签。 看起来 ryzen 不处理根本没有设置任何标签的作业。

在它适用于 gcc-stable-multiconfig 后，我会将它应用到 gcc-stable

谢谢！

然而，我注意到 ryzen 似乎无法处理这些工作。

不，它没有，但它已经执行了一堆其他作业。 但也许我们可以让 v2 ​​这样做？

我会另外将它应用到 gcc-stable

完毕

但也许我们可以让 v2 ​​这样做？

我已经配置了 v2，现在我只等待 #1806 PR 被合并，这样我就可以允许更多的构建而不是一个。 我认为 8 个作业应该适合它，因为它是 8 核，并且 -j 2 也可以利用 SMT？

要在 v2 崩溃或重新启动时重新启动 build-v2 容器，只需键入 。 请注意，这只能在已经构建容器的情况下完成 - 请按照 doc/docker/jenkinsnode/README.md 获取这些说明。 然后使用此命令在容器创建但已停止后重新启动：

docker start build-v2

另外，为了将新构建节点的 ssh 连接从 v2 通过 a7 转发到外部世界，我在 a7 上设置了以下 ssh 隧道（docker 容器将其 ssh 端口映射到 v2 上的 22222）：

ssh -L 0.0.0.0:22222:localhost:22222 <username>@v2.complang.tuwien.ac.at

除此之外，docker 容器的公共 ssh 密钥在每次映像重建时都会更改，因此也必须在构建服务器中进行调整。 如果容器仅重新启动，则这不是必需的。 要找到它，请在 v2 上输入以下内容：

sudo docker exec -it build-v2 bash
# now you should be on the docker machine
cat /etc/ssh/ssh_host_ecdsa_key.pub
> ecdsa-sha2-nistp256 <blablablalb> <root@6b906cc01f23>

只复制前两件事，所以密钥算法和密钥本身，最后不要把这个用户信息复制到 ryzen-v2 在 jenkins 的配置中为 ssh 密钥！

v2 已关闭，我通知了管理员。 很奇怪：a7和v2都是全新的硬件，出事也挺频繁的。

v2 似乎又回来了，我已经在那里重新启动了构建容器。 所以希望我们现在有更快的构建。 此外，我已将 elektra-haskell 添加到“jenkins build all please”中，因为我希望为我的类型检查器提供稳定的 haskell 构建，因此测试是一个很好的补充。

此外，我想在这里留下一个说明，我们还想创建另一个构建节点来处理现在似乎也是 v2 上的新瓶颈的 mm 构建。

最后， @markus2330我认为 point run bashism 检查器已经完成，因为这是我们通常的测试之一/testscr_check_bashisms.sh 。

标签debian-jessie-homepage||homepage和构建代理debian-wheezy-mr所有节点当前都处于离线状态。 重新启动构建代理不起作用。 如果对这些节点有 SSH 或物理访问权限的人可以调查这个问题，那就太好了。

我重新启动了虚拟服务器，但在 jenkins 中重新启动代理不起作用，并出现错误“请求中不包含有效的面包屑”。 @BernhardDenner你有什么想法吗？

似乎 v2 也已关闭。 所以我们有 3 个非功能性代理 😢

v2 回来了，但我想知道为什么它总是下降？ 它可能与我们的构建过程有关吗？

关于“没有有效的面包屑”，当我尝试在 v2 上重新启动代理时，我也看到了这一点，但是当我再次尝试时它起作用了。

v2 回来了，但我想知道为什么它总是下降？ 它可能与我们的构建过程有关吗？

这似乎是内核/硬件故障（计算机挂起时甚至 sysreq 都不起作用）。 我们的使用可能会触发错误。 计算机运行了几个月没有任何错误，自从我们使用它以来，我们已经将它崩溃了 3 次。

我升级了内核并清除了 X 服务器。

关于“没有有效的面包屑”，当我尝试在 v2 上重新启动代理时，我也看到了这一点，但是当我再次尝试时它起作用了。

谢谢！ 我现在能够再次启动主页代理。

此外，我禁用了代理 debian-jessie-minimal 及其构建工作。 我们应该为最少的工作创建 docker 容器，我将其添加为任务。

正如我们昨天惊讶的那样，社区服务器宕机了，因为它崩溃了，错误的 ARP 缓存将我们的 IP 重定向到其他服务器。 重新启动后，一切正常，但 RAID 同步仍在进行。 （因为高负载，它可能会很慢。）

社区服务器的负载几乎恒定为 10。目前是 13.20 11.29 9.35。 我们真的应该减少直接在社区服务器上运行的作业，并将负载转移到 v1。 有志愿者吗？

Jenkins 从 2.89.2 升级到 2.89.4。 不幸的是，我没有找到查看更新日志的简单方法（ apt-get changelog失败，因为它是一个非官方软件包）。 有什么理由不做这个更新？

上游变更日志位于https://jenkins.io/changelog-stable/
显然 2.89.4 包含安全修复程序。

感谢您查找！

我升级到 Jenkins 2.89.4，一切又开始运行了。

重启后默认情况下 elektrahomepage 未启动，我更改了它（/etc/vservers/elektrahomepage/apps/init/mark=default）。

我还激活了 test-docker 构建作业。

v2 又挂了 :cry:

但至少a7现在似乎很稳定。

我在 a7 和拉伸节点 (debian-stretch-mr) 上安装了 clang-format-5.0。

对于下一个 PR，请根据 clang-format-5.0 重新格式化。

https://build.libelektra.org/jenkins/job/elektra-clang-asan/被暂时禁用。

我们目前正在调查 v2。 UEFI 来自 6.6.17。 好像崩溃总是发生在周末，也许那个时候负载更高？ 我将尝试在 v2 上复制 v1 设置。

v1 和 v2 使用相同的内核启动并运行。

@e1528532似乎您的 ssh 桥没有启动，并且 doc/docker/jenkinsnode/README.md 中的命令失败，并显示“无法准备上下文：无法评估 Dockerfile 路径中的符号链接：lstat /root/Dockerfile：没有这样的文件或目录”，然后是“无法在本地找到图像 'buildelektra- stretch:latest '”。 这意味着目前无法访问 v2。

@markus2330写道：将问题移至 #1829

我认为构建服务器的最新更新之一破坏了elektra-gcc-configure-debian-stretch ，它无法再连接到存储库：

stderr: fatal: Unable to look up github.com (port 9418) (Name or service not known)

.

我认为elektra-gcc-configure-debian-stretch是构建服务器ryzen无法连接到 GitHub。 我相应地将构建作业的标签从debian更改debian-stretch-mr 。 现在构建工作似乎又开始工作了。

ryzen，无法连接到GitHub

似乎我们的管理员对“manged=true”的 NetworkManager 修复工作不可靠。 重启后“/etc/resolv.conf”又是一个悬空的符号链接。 我再次修复了它，从 ryzen 应该可以访问 GitHub。 不幸的是，rzyen v2 仍然无法访问（缺少 ssh 桥）。

Elektra 0.8.22 终于发布了。 网站建好后我会添加#676的链接，建站需要一个多小时。 也许我们可以将主页构建移动到更快的机器上，并且只将生成的网站复制到其位置。

我认为我们已经对托管http://build.libelektra.org的服务器做了一些处理几分钟：

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em><a href="/jenkins/">GET&nbsp;/jenkins/</a></em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.10 (Debian) Server at build.libelektra.org Port 443</address>
</body></html>

.

是的，受影响的不仅是 Jenkins，还有在这台服务器上运行的所有其他东西。 对我来说，这种情况也常常是不可接受的。 好像内存太少了。 （使用 2GiG 交换）

Jenkins 可能是原因，有几十个 Java 进程在 htop 中名列前茅。 很长一段时间我们有足够的 RAM 并且几乎没有使用交换，我们没有太大变化（除了升级 Jenkins 和增加构建作业的数量）。

我建议完全停止使用社区服务器作为代理。 为此，我们需要返回 v2，但@e1528532似乎很忙。 我们也可以租用更好的服务器，但是我们需要有时间进行迁移的人。

@markus2330你能重新启动构建服务器吗？ 目前，即使是像elektra-todo这样的简单工作也会失败。

我在星期天重新启动了 v2，但显然它已经再次关闭，所以我们应该先让 v2 ​​稳定，然后再考虑在上面放其他东西。

我重新启动了 Jenkins 和 v2。 詹金斯似乎再次顺利运行。

@e1528532 ssh 隧道似乎仍然不起作用。 即使在重新启动 a7 后，也无法连接到 v2。

所以我们应该先让 v2 ​​稳定，然后再考虑在上面放其他东西。

主要的停机时间是由 ssh 桥引起的。 如果 v2 出现问题，通常会在一天内重新启动。
我现在删除了 X 服务器的其余部分，所以我希望 v2 现在也稳定了。 对于 a7 来说，这似乎是诀窍（在相当长的一段时间内不需要重新启动）。 在 v2 上没有负载（需要 ssh 桥），但是，我们不确定它是否稳定。

拆分关于硬件（重启）和软件（Jenkins 升级）的讨论怎么样？

a7 和 v2 之间似乎存在网络连接问题。 v2 已启动并正在运行，但我仍然收到“No route to host”。 看来我今天无法修复它。

v2 的网络宕机了，因为卸载 GNOME 也卸载了 network-manager。 我们现在修复了网络（使用 /etc/network/interfaces）并升级到最新的 BIOS/UEFI。 所以希望现在一切都稳定了。

顺便提一句。 我们可以通过 ssh 桥使用另外一种硬件......（PCS）

ssh 隧道似乎仍然不起作用。 即使在重新启动 a7 后，也无法连接到 v2。

是的，这不是自动化的。 现在我已经照顾好了一切。 如果机器重新启动，docker 容器现在应该自动重新启动。 至少我已经根据https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode将 --restart 标志设置为“始终”

此外，我创建了一个名为“ssh-tunnel-a7-v2”的新用户，它在 a7 和 v2 上都没有设置密码（因此，禁用了该用户的密码身份验证）。 我在 a7 上为用户创建了一个 ssh 证书，并将其公钥添加到 v2 上的已知主机。 然后我向/etc/systemd/system/ssh-tunnel-a7-v2.service添加了一个 systemd 服务，它根据https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service 自动打开 ssh 隧道作为 systemd 服务。 因此，当服务器重新启动或 ssh 连接崩溃并且不再依赖于我或我的用户时，它也应该可以工作。 由于使用证书，连接时无需使用密码。

最重要的是，当这个新的自动配置处于活动状态时，v2 当然会重新启动。 希望它能在下一次崩溃中幸存下来（如果有的话），理论上应该可以，但我们会看到。

如果 Jenkins 在ryzen v2上执行作业，则构建作业test-docker总是失败：

docker inspect -f . elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: docker: not found
[Pipeline] sh
[test-docker] Running shell script
+ docker pull elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: docker: not found

. 我想将作业限制为ryzen v2以外的节点，但似乎test-docker的

谢谢你调查！ 是否可以为代理分配多个标签？ 然后，您可以为 ryzen v2 分配一个唯一标签并将作业与其绑定。

幸运的是，我们很快就会获得对构建服务器的支持：+1：

是否可以为代理分配多个标签？

据我所知是的，可以为一个代理分配多个标签。

然后，您可以为 ryzen v2 分配一个唯一标签并将作业与其绑定。

正如我在 [[1]] 之前已经说过的，似乎缺少“限制此项目可以运行的位置”选项：

我想将作业限制为ryzen v2以外的节点，但似乎test-docker的

.

啊，我误解了你的说法：“没有办法编写一个允许我说 (stable && !ryzenv2) 的布尔表达式”，并不是说根本没有代理限制的选项。

也许这可以通过 DSL 来完成。 我会问卢卡斯他是否知道该怎么做。

你好，

正如@sanssecours指出的，ryzen v2 没有安装 docker，但它有 docker 标签。
test-docker 运行需要节点具有 docker 标签。

可能的解决方案是在节点上安装 docker 或从 jenkins 中的节点中删除标签

可能的解决方案是在节点上安装 docker 或从 jenkins 中的节点中删除标签

感谢您为问题提供解决方案。 我刚刚从ryzen v2删除了docker标签。 据我所知，现在似乎一切正常。

我更新了“ryzen v2”节点的描述，以反映它实际上“只是”一个在 v2 上运行的 docker 容器。 因此，即使 docker 安装在 v2 上，为什么 docker 也不可用。

还向 jenkins 添加了一个插件，可以更轻松地构建数据可视化（无需单击每个构建）

v2 又宕机了，我举报了。

我重新启动了 v2，但无法重新连接代理。

至少我们最终得到了崩溃前发生的错误消息（当然不能保证错误消息与崩溃有任何关系）：

watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [docker-containe:789]
...
NMI watchdog: Watchdog detected hard LOCKUP on cpu 14
...

奇怪，看起来我的重启机器确实工作了，ssh 隧道和 docker 节点都重新启动，我可以连接到 a7.complang.tuwien.ac.at -p 22222，这意味着一切都应该打开。 然而不知何故，詹金斯出于某种原因向我展示了一个无限旋转的轮子，没有超时，什么也没有。

我像以前一样尝试了手动 ssh 桥接器，同样如此。 再次重新启动 docker 容器，同样如此。 所以老实说，我不确定现在没有错误消息到底出了什么问题，我发现的唯一一个人显然有一个类似的错误（旋转轮但没有消息）但除了重新启动整个主詹金斯之外没有其他解决方案节点（我没试过）： https :

编辑：我尝试了一种建议的解决方法（将主机名配置重置为不存在的内容，重新连接，然后 jenkins 意识到主机名错误，改回实际的主机名，然后它突然工作而没有任何进一步的麻烦）。 所以我想这个错误发生而不是我的重启设置，但让我们等待下一次崩溃来确定;)

@markus2330我敢打赌你已经自己找到了，但快速搜索告诉我这可能与 c-state 配置有关： https : //bugzilla.kernel.org/show_bug.cgi?id=196683 ，有一些建议解决方法

似乎构建服务器ryzen无法连接到我们的存储库：

无法从https://github.com/ElektraInitiative/libelektra.git获取

.

dns 配置再次悬空。 因为我不完全明白为什么会这样
按照目前的方式设置我只恢复了名称服务器设置和
重新启动 docker 构建作业。

在2018年3月在17:03 12，勒内·施魏格尔[email protected]写道：

似乎构建服务器 ryzen 无法连接到我们的存储库
https://build.libelektra.org/jenkins/job/test-docker/162/console ：

无法从https://github.com/ElektraInitiative/libelektra.git获取

.

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

因为我不完全明白为什么它是这样设置的

恐怕没人懂。 也许 DNS 服务器配置错误，没有提供正确的名称服务器信息。 对于 v2，我们卸载了网络管理器，现在似乎 resolv.conf 在那里稳定了。 因此，一种选择是也卸载 a7 上的网络管理器。 （并使用 /etc/network/interfaces） v2 和 a7 没有理由有不同的设置，这只是因为管理不善。

理想情况下（从长远来看），我们使用 Puppet 管理两者。

https://bugzilla.kernel.org/show_bug.cgi?id=196683 ，有一些建议的解决方法

C6 应该被禁用，但我们将继续调查。

新的构建代理“ryzen v2 docker”似乎没有像“debian-stable-mm”那样运行的 D-Bus 守护进程。

有人可以安装/启动它，或者告诉我哪个脚本配置了 multiconfig-gcc47-cmake-options 构建，以便我可以添加一个片段以确保它已启动？

@markus2330我怀疑因为 ifupdown 和 networkmanager 都已启用，所以它们都会互相影响。 禁用两者之一肯定会有所帮助。

好的，我在 a7 上删除了 gnome 和 network-manager 以与 v2 保持一致。

新的构建代理“ryzen v2 docker”似乎没有像“debian-stable-mm”那样运行的 D-Bus 守护进程。

构建代理位于docker容器中，希望@e1528532可以帮助您在那里启动 dbus 守护程序。

谢谢你。 这应该相当容易。 我使用以下命令在 docker 容器（Ubuntu 17.10 artful 从docs/docker/Dockerfile构建）中启动它：

mkdir /var/run/dbus # create directory for pidfiles & co
dbus-daemon --system

构建服务器 ryzen无法再次

对不起，我的错。 似乎停止网络管理器足以破坏系统。

现在应该修复了。 请不要犹豫，报告任何进一步的问题。

@markus2330很确定它会在下次重新启动时再次损坏

我冒昧地重做 /etc/network/interfaces 文件（并将接口的配置移动到 /etc/network/interfaces.d 中）
结合网络管理器的卸载应该有望保持稳定

请检查配置并可能触发重新启动以查看它是否有效

@ingwinlu谢谢你的修复，重启效果很好。

我发现我删除了太多的包，所以我再次安装了 Java (openjdk 9 headless and default-jre) :smile:

@ingwinlu你能不能让 dbus 在 v2 代理上运行？ 理想情况下，请将“/home/armin/buildelektra-stretch/Dockerfile”重新定位到一些非用户特定的目的地。

@markus2330我关于如何继续构建环境的建议实际上预见到删除当前的 dockercontainer-on-v2 节点并将其替换为支持 docker 的节点（即不再指向 v2 上的 docker 容器，而是直接指向 v2） .

之后，我们可以设置构建管道，从检入存储库的 Dockerfiles 构建镜像本身，以提供测试所需的不同环境。

当我到达时，我可以优先推出支持 dbus 的 docker 映像，但我不想做那些很快就会无关紧要的工作，如果我不需要的话。

是的，有道理！

v2 的长期目标是我们必须与其他一些 docker 容器（不适用于 Elektra）共享它，所以如果我们的所有部分都以无法影响其他 docker 容器的方式进行虚拟化，那将是一件好事。 （也许是递归 docker 或 Xen？）我们可以/应该为 a7 做同样的事情以获得相同的设置。

我们将继续直接在机器上访问，但我们应该降低 Jenkins 杀死与它无关的 Docker 机器的任何风险。

对于某些代理，我们已经有了 Puppet 设置。 如果我们不绕过它甚至更好：将这个设置扩展到 a7 和 v2。 我希望@BernhardDenner能尽快为您提供更多相关信息。

构建服务器又宕机了🙌。

顺便说一下，我们可以将关于构建服务器状态的讨论转移到GitHub 团队讨论中，因为订阅此问题的所有人可能不会对这个主题感兴趣。

是的，整个服务器都关闭了，包括构建服务器 :cry: 并且 v2 也关闭了（独立）。 我重新启动了 v2 并更改了 UEFI 中的 C-States 选项。 但似乎我们的服务器存在重大问题。 希望我们能用内存更大的更好的硬件代替它：crossed_fingers：

GitHub 团队讨论

如果我们在 GitHub 团队讨论中写一些东西，不是每个 ElektraDevelopers 都会收到通知吗？ 在这个问题中，每个人都可以决定他/她是否要订阅。

对我来说，一个悬而未决的问题是我们是否应该将这个问题分成两个问题：硬件相关的和 Jenkins 相关的。

如果我们在 GitHub 团队讨论中写一些东西，不是每个 ElektraDevelopers 都会收到通知吗？

据我所知，是的。

在这个问题中，每个人都可以决定他/她是否要订阅。

团队讨论也是如此。

构建服务器再次启动。 设置更改：

• xms 和 xmx 设置可在队列中有大量构建时减少垃圾收集量
• 我注意到我们使用 scm 轮询。 我一次将轮询器限制为 4 个全局并发轮询，希望能减少服务器当前获得的一些峰值。

编辑：

* 根据访问 webui 时读取的多个来源，将所有管道的构建数量设置为 30，因此大量旧构建会减慢请求

将 Jenkins 更新到版本。 2.107.1

• 更新詹金斯战争文件
• 禁用Use browser for metadata download插件安全设置，因为它不允许更新插件
• 将插件更新到最新的可用版本

编辑 2018-03-18：

• 为在 mm 上运行的所有节点添加了第二个执行程序

* 取消所有运行在 mr 上的代理的优先级

Master现在在负载下应该响应更快。 与之前的 4h+ 相比，build all 应该更接近 2h。

编辑 2018-03-24：
抱歉耽搁了，忙碌的一周...

• 向 jenkinsserver (elektra-jenkinsfile) 添加了一个新作业，它将运行在 repo 中找到的 Jenkinsfile（一旦它存在）

编辑 2018-03-28：

• 重做隧道单元文件，现在它解析环境文件，因此可以调整为指向多个目标
• 添加了 v2 服务器作为能够运行 docker 的从属服务器
  
  
  
  • 在 v2 上添加了 jenkins 用户
  
  
  • 在 v2 上安装了 openjdk-9
  
  

编辑 2018-03-29：

• 修复 jenkins master 上的 ulimit 设置

虽然我很确定@ingwinlu或有人已经在做这件事：似乎ryzen v2配置错误：

FATAL: Could not apply tag jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Command "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" returned status code 128:
stdout: 
stderr: 
*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <[email protected]>) not allowed

来自https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console 但发生了在多个场合。

哎呀，对不起。 它没有安装 deps，应该只充当 docker 主机。 我将删除额外的标志。
//编辑：应该完成。 希望这就足够了
//EDIT2：我现在也禁用了test-docker ，因为它显然找不到运行测试所需的构建映像。

但是该死的东西如果真的能得到它可以构建的东西，它就会很快
//EDIT3: 启用 test-docker 以仅在带有 docker-prefab 标签的节点上运行并将该标签提供给 ryzen

可悲的是，问题似乎比原先预期的要大。

有些作业的节点是硬编码的。 一些标签已过时（在 jessie 节点上稳定）。 一些作业不需要正确的节点并且只在正确的节点上执行，因为它之前在那里执行过一次并成功构建。

新节点（ryzen v2 native）的引入使分配混乱了一点，即使它不应该有。

请期待一些意外的行为，直到一切再次运行。

变更日志：

• 重命名的节点， <os>-<hostname>-<buildenv>
• 已禁用elektra-multiconfig-gcc47-cmake-options
  它实际上已经有一段时间没有在 gcc47 从站上运行了，根据计划的位置，混合了 gcc49 或 gcc63 构建。 如果重新启用它可能应该进入 v2 上启用 gcc63 的 dockercontainer
• 重新标记了大量工作（可能错过了其中一些）
  
  
  
  • elektra-todo 需要stable ，但并非所有稳定节点实际上都安装了sloccount
  
  
  • 更多类似案例
  
  

A7好像掉了

waht [email protected] schrieb am Do., 29. März 2018, 21:24:

虽然我很确定@ingwinlu https://github.com/ingwinlu或
有人已经在这了：似乎 ryzen v2 配置错误：

致命：无法应用标签 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException：命令“git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185”返回状态代码 128 ：
标准输出：
标准错误：
*请告诉我你是谁。

跑

git config --global user.email " [email protected] "
git config --global user.name "你的名字"

设置您帐户的默认身份。
省略 --global 以仅在此存储库中设置身份。

致命：不允许空身份名称（对于[email protected] ）

从
https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console
但发生过多次。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

你想为此工作吗？ 我今天可以重新启动它。 作为替代，我们的管理员或我可以在星期二重新启动它。

如果不是太麻烦的话。 否则我不能在我的公关上工作
周末

markus2330 [email protected] schrieb是萨，31马兹2018，14:33：

你想为此工作吗？ 我今天可以重新启动它。 作为替代，我们的
管理员或者我可以在星期二重新启动它。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

好的，我重新启动了它，并在 BIOS/UEFI 中禁用了 C6-State（已启用）。 我还删除了 gnome/xorg（我以为我已经这样做了？）。

顺便提一句。 屏幕全黑，所以我们只能猜测是什么原因。

这些每隔 10 分钟左右就会出现在 a7 上：

Apr 04 07:14:23 a7 kernel: [Hardware Error]: Corrected error, no action required.
Apr 04 07:14:23 a7 kernel: [Hardware Error]: CPU:0 (17:1:1) MC15_STATUS[Over|CE|MiscV|-|AddrV|-|-|SyndV|-|CECC]: 0xdc
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Error Addr: 0x00000003705a2f00
Apr 04 07:14:23 a7 kernel: [Hardware Error]: IPID: 0x0000009600050f00, Syndrome: 0x0000015c0a400f03
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Extended Error Code: 0
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Error: DRAM ECC error.
Apr 04 07:14:23 a7 kernel: EDAC MC0: 1 CE on mc#0csrow#3channel#0 (csrow:3 channel:0 page:0x700b45 offset:0xf00 grain
Apr 04 07:14:23 a7 kernel: [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
lines 5977-6036/6036 (END)

这些可能是 a7 停机的原因以及 a7 延迟上的一些奇怪的构建行为

禁用elektra-ini-mergerequests valgrind 部分，因为它是通过make run_memcheck

这些每隔 10 分钟左右就会出现在 a7 上

是的，我们已经看到了。 买电脑的时候，有人实际检查过ECC是否有效，当时没有出现这样的错误。 这些错误的频率是否以某种方式取决于系统的负载？

在 elektra-ini-mergerequests 中禁用 valgrind 部分，因为它是通过 make run_memcheck 运行的

谢谢你清理这个。

我在 a7 上有随机输出（容器崩溃，构建在中间停止，断开连接，......）再次没有任何“真实”日志。 只有已经提到的记忆修正。

谢谢，好像有什么不对的地方。 我们现在也有无法纠正的错误：

Apr  5 09:50:40 a7 kernel: [39549.503787] mce: Uncorrected hardware memory error in user-access at 73d6ce880
Apr  5 09:50:40 a7 kernel: [39549.503794] [Hardware Error]: Uncorrected, software restartable error.
Apr  5 09:50:40 a7 kernel: [39549.505882] [Hardware Error]: CPU:2 (17:1:1) MC0_STATUS[-|UE|MiscV|-|AddrV|-|Poison|-|-|UECC]: 0xbc002800000c0135
Apr  5 09:50:40 a7 kernel: [39549.506581] [Hardware Error]: Error Addr: 0x000000073d6ce880
Apr  5 09:50:40 a7 kernel: [39549.507287] [Hardware Error]: IPID: 0x000000b000000000
Apr  5 09:50:40 a7 kernel: [39549.507980] [Hardware Error]: Load Store Unit Extended Error Code: 12
Apr  5 09:50:40 a7 kernel: [39549.508677] [Hardware Error]: Load Store Unit Error: DC data error type 1 (poison consumption).
Apr  5 09:50:40 a7 kernel: [39549.509378] [Hardware Error]: cache level: L1, tx: DATA, mem-tx: DRD
Apr  5 09:50:40 a7 kernel: [39549.510136] Memory failure: 0x73d6ce: Killing java:1470 due to hardware memory corruption
Apr  5 09:50:40 a7 kernel: [39549.510908] Memory failure: 0x73d6ce: recovery action for dirty LRU page: Recovered

又是a7。

在更高效的方面：我为 jenkins 安装了蓝色海洋前端。 预览

又是a7。

它真的很令人沮丧。 我重新启动了机器并重新连接了代理。 我会要求我们的管理员明天更换 RAM，所以预计明天会停机。

在更高效的方面：我为 jenkins 安装了蓝色海洋前端。 预览

看起来很棒！ 也许你可以在下一次会议上向我们展示它？

我们的管理员已经在周末了。 我将重新启动 a7 并将 BIOS/UEFI 重置为出厂默认设置。 如果错误持续到周末，他将有望更换 RAM。

编辑：没有构建作业正在运行，因此没有构建作业被取消。

编辑：一切又开始了。 到目前为止没有内存错误。

看起来好多了。 有人看了太多 linus 技术提示并超频服务器吗？

抱歉，我不得不阻止詹金斯一段时间。 服务器的负载为 20，我需要做的事情不再可能（> 1 小时的等待时间，然后我放弃并停止了 Jenkins）。

是否有可能即使是未启动的构建作业也需要 RAM？ （队列列表很长）否则本地构建作业是这些问题的最佳候选者。 （正在运行 3 个本地构建作业）

@ingwinlu理想情况下，我们不在该服务器上构建任何内容。 此外，我们能否让构建作业依赖于服务器上的负载。 （不要在负载 > 5 的服务器上启动作业？）。

我重新开始了一切，但我希望我们能找到一个快速的解决方案。

我在 Jenkins 系统设置中输入了 VERSION 和 CMPVERSION。

@ingwinlu如果我们在 Jenkinsfile 中也有这些设置，那就太好了。

@markus2330参见 8de9272051fe903a7df08f0abdf18879701f7ac9 的示例，了解如何在 Jenkinsfile 中实现此目标

从以下目标中删除make run_memcheck由于它们在一段时间内失败并最终出现在构建系统中，这要归功于 #1882

• gcc-configure-debian-stretch-minimal
• gcc-configure-debian-wheezy
• elektra-gcc-i386

限制elektra-gcc-configure-debian-stretch在节点上运行： stretch && !mr

将 jenkins master 更新为ver. 2.107.2 + 更新所有插件

我今天尝试将allowMembersOfWhitelistedOrgsAsAdmin到所有构建作业中，但似乎我仍然无法正确触发所有构建（参见 #1863）并且只有一些作业被执行

@markus2330 https://github.com/janinko/ghprb/issues/416#issuecomment -266254688

有人可以请

• 使固定
• 禁用，或
• （甚至更好）删除

elektra-clang-asan请🙏。 目前，尽管所有失败的测试，构建作业都失败了：

• testlib_notification
• testshell_markdown_base64
• testshell_markdown_ini
• testshell_markdown_mini
• testshell_markdown_tcl
• testshell_markdown_xerces
• testshell_markdown_tutorial_validation

在Travis上工作得很好。

他们的测试与（例如）他们使用不同的 clang 版本不同......

由于此线程对于错误报告或更长的讨论绝对无法跟踪，因此我会尽快为 clang 和 clang-asan 打开新问题。

他们的测试与（例如）他们使用不同的 clang 版本不同......

我同意，虽然 Travis 使用过时的clang 5.0.0 ，但elektra-clang-asan上的 Clang 版本是古老的（ 3.8.1 ）。 对于这样一个旧的编译器，我看不到启用 ASAN 的构建作业的价值。

我为“elektra-clang-asan”上失败的“testlib_notification”测试创建了#1919。

我在禁用所有 mr 代理的情况下测试了一个构建，并且 master 完全响应，而启用所有 mr 代理的构建实际上使某些构建超时。 因此，如果我们可以摆脱所有 mr 代理，#1866 肯定会提供改进（-wheezy，因为它不可容器化）

进一步的测试表明它几乎只是主页构建工作。 我暂时将它从build all删除，因此它只能显式运行。

它将被容器化的解决方案所取代。

v2 再次上线并使用最新的 BIOS。

请在此处报告任何段错误（CPU 可能有问题）。

a7好像挂了？

2018 年 5 月 4 日 11:10，markus2330 [email protected]写道：

v2 再次上线并使用最新的 BIOS。

请在此处报告任何段错误（CPU 可能有问题）。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 再次使用最新的 BIOS

a7又降了？

是的，它坠毁了。 它显示了没有任何错误消息的登录提示，并且对任何输入（包括 sys-req）都没有任何反应。 只有硬重置有帮助。

如果您有任何想法可能是什么问题，请告诉。

遗憾的是，a7 上没有设置持久日志，因此没有日志

我们什么时候可以期待 a7 和 v2 再次可用？

哦，我不知道他们倒下了。 我会要求我们的管理员重启，如果他不能重启，我会在 17:00 左右重启。

编辑：他说他会立即重置它们。

编辑：他们都又起来了。

我今天手动重新启动了 a7 和 v2。 似乎无法再访问 v2。 你能请它实际上正在运行吗？

//编辑：通过修复两台机器上的网络配置来解决

显然a7再次下降。

好的，我会重启她。 否则我们永远不会完成这个版本。

任何原因的迹象？ 只是网络问题还是机器再次无响应？

现在一切都应该启动并运行。

我只是在正确的时间得到它，有一些日志直到它最终完全冻结。

日志是：

INFO: rcu_sched detected stalls on CPUs/tasks:
...
rcu_sched kthread starved for 7770 jiffies
watchdog: BUG soft lockup - CPU#2 stuck for 22s! [docker-gen]
... (many repetitions)
NMI watchdog: Watchdog detected hard LOCKUP on cpu 2

那可以是任何东西。 从有问题的 ryzen cpu 到坏的 psu :(

2018 年 5 月 12 日 14:33，markus2330 [email protected]写道：

现在一切都应该启动并运行。

我刚刚在正确的时间得到它，有一些日志直到最后
完全冻结。

日志是：

信息：rcu_sched 在 CPU/任务上检测到停顿：
...
rcu_sched kthread 饿了 7770 jiffies
看门狗：BUG 软锁定 - CPU#2 卡住了 22 秒！ [码头工人]
...（多次重复）
NMI 看门狗：看门狗检测到 cpu 2 上的硬 LOCKUP

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

关于#1993

@ingwinlu如果作业当前没有成功，请禁用它们（或者至少不要在默认情况下触发它们，也不要使用“jenkins build all please”）。 我们应该高度重视我们不会在 PR 中失败，因为实际上一切都很好。 （阿桑失败了很长一段时间并不是一个好情况）

如果他们因为您所做的某些 Jenkins 操作而失败，那么重新启动作业会很好 :heart: 在 #160 中这样说也可以。

v2 再次启动，带有新的 CPU！

请提交许多工作进行压力测试 :smile:

a7好像又降了。

谢谢，一切又恢复了。

我再次重新启动a7。

拥有一个每小时重置 a7 的电路很可能会增加可用性。

我们什么时候可以看到 a7 再次上线？

a7重新上线

v2重新上线

v2的电源会在1h左右更换。

@ingwinlu你能禁用代理然后再启用它们吗？ （如果您目前正在处理它。）

v2 代理暂时被禁用

v2 再次运行。 它有一个新的电源。 请提交许多作业以对机器进行压力测试。

我更新了詹金斯插件。 由此产生的重启部分恢复了旧的 jenkins 节点（在它们被重命名之前），由于 git 存储库被破坏，导致到处都是破坏的构建。

为了确定起见，我清理了受影响的存储库并清理了缓存的 docker 容器。

a7 再次关闭，因此基于 docker 的构建不再可用。

我也将更新回滚到 xunit，因为它违反了安全限制。

我重新启动了 a7 并重新连接了所有代理。

docker build 不可用，因为 a7 再次关闭。

我重新启动了服务器并重新连接了代理。

我认为更换 a7 是最好的方法，见 #2020

我认为它再次失败，我最近的提交导致无法联系 a7-debian-stretch：java.lang.InterruptedException

@e1528532谢谢你写在这里！ 如果你愿意，你也可以投票#2020

我重新启动了 a7 并重新连接了代理。
让我们最好地希望周末不会出现问题。

a7 再次下降 :cry: 令人惊讶的是它几乎整个周末都在工作。 可能是一周的正常运行时间记录。 然而#2020并没有得到很多评论。

我重新启动了 a7（它对 sysctl 做出了反应），其他人启动了 jenkins。 一切都重新启动并运行。

a7又掉线了。

谢谢你的信息！ 我重新启动了 a7 并重新连接了代理。

我们有代理“debian-jessie-minimal”有意义吗？ 我认为一旦将其集成到 Docker 中，您就可以安全地将其删除。 （而且好像已经是了）

编辑：
在https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
和https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
有警告：

WARNING: LinkageError while performing UserRequest:hudson.Launcher$RemoteLauncher$KillTask<strong i="13">@544b40e</strong>
java.lang.LinkageError
    at hudson.util.ProcessTree$UnixReflection.<clinit>(ProcessTree.java:710)
    ...
Caused by: java.lang.ClassNotFoundException: Classloading from system classloader disabled
    at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854)

坏消息。 v2 也下线了。

编辑：但我似乎能够通过 ssh 连接到它....
EDIT2：在 v2 上重新启动，但现在我无法再连接。 仍然可以从 a7 ping 通...

EDIT3：现在 a7 也下降了。

感谢您的举报！ 我重新启动了 a7 和 v2。 我们应该重新考虑#2020。

我认为 v2 再次关闭：

无法联系 v2-debian-stretch：java.lang.InterruptedException

使用 v2 一切正常，但 a7 再次出现故障。 现在所有代理都重新上线了。

v2 似乎再次半无响应。 可以从 a7 ping 但根本没有 ssh 操作。 应该是 btrfs 的问题单从症状。 你能在周末回家之前重启一切吗？

@ingwinlu谢谢@waht ，我成功重启了v2，但我无法连接代理（“连接被拒绝（连接被拒绝）”）。 知道这里有什么问题吗？ （交互式 ssh 登录有效）

ssh 仅在不通过网桥连接时才有效。

重新启动桥接服务后，可以建立连接。

似乎 ssh-tunnel 最终处于一种奇怪的未定义状态并且没有杀死自己。 不知道为什么它没有杀死自己（serveraliveinterval 开启）。

我还需要手动清理 v2 上的所有工作区，因为 fs 已损坏并且它们上的所有构建作业都失败了。

a7好像挂了。 我不确定我是否可以在星期一之前重新启动它。

我重新启动了 a7 和 v2。 （v2 因为在 a7 上有错误消息，它无法创建到 v2 的 ssh 桥。但在重新启动 v2 后也出现了相同的错误消息。不过，ssh 桥似乎可以工作。也许缺少一些依赖（网络？） a7的启动脚本？）

也许 a7 的启动脚本中缺少某些依赖项（网络？）

不，它在那里。

它无法创建到 v2 的 ssh 桥

我相信当 v2 内核开始无响应时会发生这种行为（因此无法建立传入的网络连接）。 过去，您提到了指示 v2 上 btrfs 错误的日志。

我准备关闭构建服务器以稍后更换 CPU。

a7 和 v2 又回来了（a7 带有新 CPU，v2 带有检查根文件系统）

虽然它在白天保持不变（具有一致的构建），但似乎 a7 再次下降。

是的，我明天早上重新开始。

我们应该再次讨论#2020。

我重新启动了a7。 这又是一个 CPU 挂起。

a7又掉线了。

谢谢，我重启了。 所有代理重新上线。

看起来一些 debian 节点已关闭，因此一些 PRS 已经在等待很长时间才能开始测试执行。 这是故意的吗？

看起来一些 debian 节点已关闭，因此一些 PRS 已经在等待很长时间才能开始测试执行。 这是故意的吗？

在 mm-debian-unstable 节点上升级期间，机器变得无响应，此后我们一直无法连接到它。 由于所有者没有回复我们的电子邮件，因此它可能会永远消失。

虽然我们已经将大量构建作业移植到新系统中，但缺少的是当前挂在队列中的那些。

我禁用了受影响的作业并将它们标记为已替换 + 从文档中删除

@ingwinlu谢谢你的照顾！

如果有人想在解析器上工作，阅读 xdg 测试非常重要。 我在此处的顶部帖子中添加了它。 你能更新你在上面的检查清单中已经取得的成就吗？

这次v2是幸运的赢家。

@markus2330我清理了顶帖。

谢谢你的清理！ 我将在明天早上重新启动 v2（也许 a7，让我们看看）。

我重新启动了它。 没有反应，也没有消息。 见#2020

请重新启动 a7 和 v2。

我重新启动了a7。 我没有发现 v2 有任何问题，我应该重新启动它吗？

i7 现在可以在 192.168.173.96 使用你能通过 a7 创建一个桥接吗？

您需要在机器上创建一个 ssh-tunnel-a7-v2 用户或为我创建一个帐户。

我们添加了一个额外的构建从站i7-debian-stretch来帮助libelektra构建作业。

v2-docker-buildelektra-stretch (offline)因为没有更多的构建作业被安排在那里。 a7 上暴露代理的 ssh-bridge 也被禁用。

你好@ingwinlu ，
正如上次会议所讨论的，我需要接入点。
您能否将每封电子邮件的信息发送给我，我的电子邮件在AUTHORS.md 中。
顺便提一句。 在任何地方都找不到您的电子邮件，也许您应该将自己添加到此文件中。

我们的 v2 构建服务器将在 31.07 09:00 之前脱机，因为我们正在对其运行基准测试。 预计构建时间会更长。

带来不便敬请谅解。

//编辑：将停机时间延长 2 小时

似乎扩展现在也通过了。 午餐后（大约 13:00）恢复快速构建会很好。 ：微笑：

mm-debian-unstable 已升级并重新上线。 是否有我们可以重新激活并固定到服务器的作业？

i7的磁盘好像满了。 我的工作失败了No space left on device （工作和工作）

顺便说一下，我真的很喜欢新的构建界面（dockerization 和 jenkinsfile）。 非常有助于重现构建错误。

感谢您的举报！

不幸的是，调整大小需要重新启动（rootfs 需要变小才能扩展另一个）并且只能带来 20G。 我删除了 Jenkins 构建文件夹，但它们很小，所以我们仍然是 99%。

所以清理 _docker 会更有效：
@ingwinlu似乎 _docker/overlay2 都很大。 知道为什么所有这些东西都收集在那里吗？

我用docker system prune -fa强制清理了 docker 工件。 这个
清理了 docker 镜像中使用的大约 190GB 空间。

在周一，2018年8月13日在07:54，markus2330 [email protected]写道：

感谢您的举报！

不幸的是，调整大小需要重新启动（需要制作 rootfs
在另一个可以扩展之前更小）并且只会带来20G。 一世
删除了 Jenkins 构建文件夹，但它们很小，所以我们仍然在
99%。

所以清理 _docker 会更有效：
@ingwinlu https://github.com/ingwinlu似乎都是 _docker/overlay2
很大。 知道为什么所有这些东西都收集在那里吗？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

谢谢！

我们可以将其放入 libelektra-daily 或 cronjob 中吗？

Daily 做一些类似但不那么激进的事情。 将不得不采取另一个
看看我什么时候回到维也纳。

markus2330 [email protected] schrieb是密苏里州，13 2018年8月，09:22：

谢谢！

我们可以将其放入 libelektra-daily 或 cronjob 中吗？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

您可能已经注意到构建服务器在早上（任何可能在晚上）都关闭了。 电源单元已损坏，现已更换。

此外，a7 或 v2 可能会在下周短时间离线进行基准测试。 如果 anton 启动基准测试，您将看到离线消息“基准”。 如果计算机离线时间过长（例如超过一天），请联系我们。 （然后可能忘记再次将其切换到在线。）

解决了我们的 sid 映像的问题。

testkdb_allplugins在 debian-unstable-full-clang 测试期间在我们的 sid 映像中出现段错误，但仅在 v2 上执行时。 我手动更新了映像以使用最新的可用软件包并将其推送到我们的注册表中。

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ 已通过，但会密切关注。

该问题已在 #2216 和 #2215 ( @mpranj @sanssecours) 中提及。

我实现了对我们的 docker 注册表的公共访问。 有关如何访问它的一些文档，请参见此处。

如果某些事情没有按预期工作，请告诉我。

//EDIT 似乎即使登录成功推送也不起作用。
//EDIT2 公共访问再次被禁用。 https://github.com/moby/moby/issues/18569。 恢复功能以构建系统
//EDIT3：公共回购在 hub-public.libelektra.org 再次启动

安东想在下周二或周三（我们可以选择）更换禁用超线程的电脑主板。 有人在这两天之一需要 buildserver 吗？

我重新启动了 docker 注册表并手动运行清理。 希望能解决网站图像的任何构建问题。

@ingwinlu感谢您的维护工作！

不幸的是，WebUI 阶段非常可靠地失败，例如321或320 （甚至更早失败，但在拉动 WebUI 时也失败？）。

我越来越相信取消 master 上的工作是个坏主意。 我们几乎没有在 master 上成功构建，因为构建要么被取消，要么由于网络问题而失败。 在提交历史中很难说出发生了什么，因为无论哪种方式，它们都只是显示为失败。

作为解决方法，我禁用了 c3b59ecef95287ffc33b094b37e03d0ec6b5710f 中的不可靠阶段，但我希望我们能尽快再次启用它们！

a7-debian-stretch仍应离线进行基准测试？ （自 2019 年 2 月 21 日上午 10:47:56 起下线）

感谢您的举报！ 好像安东忘记重新激活了。 我再次激活了节点，并且还删除了旧节点（mm 除外，因为它们仍在运行）。

早上我们的服务器停机了。 一切都再次运行，但我们收到了他们将更换硬件的提议。 所以很可能我们今天还会有大约一个小时的停机时间。

服务器又起来了。 不幸的是，我们得到了相同的硬件。 如果有人有时间进行安装/设置，我们可以升级硬件。

看起来 Jenkins 构建很慢（完整构建需要几个小时）。 据我所知，只有a7-debian-stretch和i7-debian正在执行测试，而所有其他节点都处于空闲状态。 这是预期的行为吗？

感谢您报告此问题！

不，这不是预期的行为。 似乎 v2 已关闭。 我会尽快重新启动它。

v2 现在应该再次启动

v2 已关闭，恐怕它会一直保持到星期一。 到那时，构建将非常缓慢。

v2 再次配备新主板

我会将所有 3 个构建代理（按 i7、v2、a7 的顺序）升级到 Buster 以避免 #2852

我会尽量减少停机时间。 构建作业可能会失败，请重新启动它们（在代理再次启动后）。

i7-debian-buster，之前的 i7-debian-stretch 又上线了

v2 是下一个

v2-debian-buster 和 a7-debian buster 也再次上线

我在 master 上重新启动了之前成功的构建作业，以查看是否一切正常：
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

此外，我添加了 PR https://github.com/ElektraInitiative/libelektra/pull/2876以启用 buster 构建作业。

v2 似乎已关闭（ssh 连接也失败），不幸的是我不在维也纳。 我希望我们的系统管理员明天会修复它。

a7现在也关闭了，i7（通过a7上的桥连接）。

所以目前无法执行构建。 我联系了管理员。

所有服务器再次启动。 请通过推送新提交或将“jenkins build libelektra please”作为对您的 PR 的评论来重新启动构建。

技术说明：a7 因“watchdog bug soft lockup”而宕机。 我试图添加“nomodeset nmi_watchdog=0”。 让我们希望他们不再像以前那样不稳定。

a7（还有 v2 和 i7，因为它们通过 a7 上的桥连接）已关闭。 我联系了我们的管理员。 请尽量避免现在开始构建，因为它只会排长队。

a7 重新上线（已经是昨天），v2 不受影响

根据构建服务器状态页面，服务器：

• a7-debian-buster ,
• i7-debian-buster ，和
• v2-debian-buster

下来了。 Jenkins 数据目录似乎也很满。 当我们在做的时候：如果我们可以升级 Jenkins 和它的插件，那就太好了。 我对解决这些问题很感兴趣。 但是有两个问题。

1. 我没有太多（或真的没有）管理服务器的经验。
2. 我可能需要对机器进行物理访问，因为它们似乎非常不稳定。

a7 是 i7 和 v2 的桥梁，所以随着 a7 被关闭，我们不知道 i7 和 v2。

访问没有问题，我可以给你。 但是你应该知道升级 Jenkins 是一个很大的操作，因为它通常需要重新配置 Jenkins（根据发行说明，因为我们有一段时间没有升级，所以很多）并修复 Jenkinsfile（根据插件的 API 更改） ）。 如果您想访问，请给我发电子邮件。

a7（和所有其他人）再次上升。

a7又挂了，我联系了管理员。

技术说明：a7 因“watchdog bug soft lockup”而宕机。

快速搜索表明这可能是 BIOS 问题。 有人检查过是否有可用的 BIOS 更新吗？

a7 是 i7 和 v2 的桥梁，所以随着 a7 被关闭，我们不知道 i7 和 v2。

这似乎是一个糟糕的设计。 没有办法解决吗？

快速搜索表明这可能是 BIOS 问题。 有人检查过是否有可用的 BIOS 更新吗？

我们安装了新的 BIOS，更换了 CPU 并升级了内核（请参阅上面的消息）。 从那时起，系统就很稳定了。 现在升级到 Debian buster 后它又不稳定了。

不过，我问管理员是否有新的 BIOS 可用。

这似乎是一个糟糕的设计。 没有办法解决吗？

i7 和 v2 在专用网络中，因为没有足够的 IPv4 地址。 我问我们的管理员是否可以设置 IPv6。

我问我们的管理员是否可以设置 IPv6。

我们并不真正需要 IPv6，使用另一台更稳定的服务器作为桥接器就足够了。

最有可能的是，v2 和 a7 一样不稳定（只有一次崩溃，但这并不能说明什么，因为当 a7 死掉时，它会立即承担 v2 的负载）。 我们可以使用 i7 作为桥接器。 但是如果 v2 和 a7 出现故障，i7 也没有多大用处，完成构建工作需要很多小时。 此外，i7 没有足够的空间用于 docker 注册表。

因此，这种改变将是费力而收效甚微的。

解决a7和v2的实际问题更有希望。

此外，i7 没有足够的空间用于 docker 注册表。

在这种情况下，唯一的解决方案是修复 a7。

不幸的是，a7 又挂了 :cry:

我尝试使用旧内核启动，但这没有帮助。

对于 BIOS，还有一些其他版本可用，但根据他们的发行说明，他们几乎没有希望解决此问题，如果情况变得更糟，则无法再次降级...

a7 的 BIOS 目前已升级。 此外，我们将尝试使用来自 backports 的更新内核。

a7 有望很快再次上线。

新的 BIOS 没有帮助，现在 a7 在几分钟内崩溃了。

a7又挂了，我联系了管理员。 将在下次重新启动时尝试来自 backports 的较新内核。

a7 再次使用 5.2 内核

我想它又崩溃了......

我们仍然收到相同的错误消息还是至少有一些变化？

是的，a7又掉了，我向管理员报告了。 他会在重新启动时告诉我们有关消息。

有人有其他想法吗？ （我们已经升级了 BIOS 和内核。）

一些消息来源表明 nouveau 图形驱动程序存在问题，我们应该尝试nouveau.modeset=0 （不知何故这与nomodeset ）。 还建议在 BIOS 中禁用“C-states”。

是的，a7又掉了，我向管理员报告了。 他会在重新启动时告诉我们有关消息。

有人有其他想法吗？ （我们已经升级了 BIOS 和内核。）

也许禁用 a7 作为 jenkins slave 以确定它是否仅在机器上有“真实”负载时发生。

@ingwinlu谢谢，好主意。 我现在减少到一个构建工作 a7（它是 2）。 在周末（一旦管理员离开办公室），我将完全禁用代理。

@kodebach ：谢谢，我会将信息转发给管理员。

a7什么时候重新上线有时间表吗？

a7 再次启动，关闭了超线程并且只有一个并发构建作业。

我们还可以通过将alpine和ubuntu-xenial构建移至 Cirrus 来减轻 a7 的一些负担。 它们都是简单的“构建和测试”运行。 他们没有做任何特别的事情，比如报道报道。

Cirrus 允许每个用户同时进行linkchecker版本是 Cirrus 上唯一的 Linux 版本。

实际上ubuntu-xenial有点多余，因为我们的 Travis 构建在 Ubuntu Xenial 上运行。

感谢您的提示，但我们不打算从 Jenkins 卸载任何 Linux 构建。 相反， @Mistreat将致力于改进我们的 Jenkins 基础设施，使其更加及时和有用（例如，通过构建更多包）。 我们詹金斯的优势是：

1. 我们完全控制它
2. 我们可以轻松扩展它（构建代理只需要 Java+Docker）
3. Jenkinsfile 非常整洁并且（对于大多数部分）很容易扩展

但是，当然，欢迎每个人也扩展 Cirrus（或任何其他免费提供的附加构建系统，请参阅 #1540）。

这只是一个临时解决方案，以抵消禁用超线程和限制在 a7 上的 1 个并发作业。

a7 只构建了一小部分（大约 2/5），因此减少一半应该几乎不明显。 或者现在有什么具体问题吗？ （当然，目前，从停机时间赶上许多工作需要时间。）

a7 只构建了一小部分（大约 2/5）

2/5 是 40%。 我不会认为那是一小部分。

或者现在有什么具体问题吗？

不，事实上它似乎比以前工作得更好。

抱歉，我的意思是大约 2/6（1/6 是 i7，3/6 是 v2）。 而这部分并没有去除，而只是减少了。

不，事实上它似乎比以前工作得更好。

完美的！

好像a7又挂

谢谢！ 我举报了

以后要是第一个发现的能直接上报就好了

在 complang.tuwien.ac.at 的赫伯特

可以说，“a7 ist leider nicht erreichbar”就足够了。

然后也在这里报告，这样赫伯特就不会收到几封电子邮件。

当然，有一种方法可以让 Jenkins 主服务器自动发送这样的电子邮件，也可以发布到这个 GitHub 问题。 如果没有Jenkins插件来完成这么简单的任务，那就太奇怪了……

是的，有https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin但我不确定它是否完全符合我们的要求。 当有人故意推迟代理时，它也可能会发送电子邮件。 并且管理员更有可能更快地处理个人电子邮件。

如果我们自动执行某些操作，那么如果无法访问 PC，则直接重新启动它们（也许它们甚至内置了某种看门狗？）

a7 已重新启动并且“全局 C 状态控制”已禁用。

但是，它不是作为构建代理在线的。

让我们看看它是否也会在没有负载的情况下崩溃。 v2 和 i7 再次工作。

管理员 (Herbert) 明天不可用，所以我暂时将 a7 作为构建代理。

我的计划（如果之前没有抗议或 a7 崩溃）是明天打开 a7 作为构建代理。 如果 a7 再次崩溃，Herbert 可以在周五重新启动 a7。 这个可以吗？

如果队列不是太长，我认为我们应该将 a7 上的构建代理禁用一段时间。 最后一次崩溃发生在 3 天之后。 如果我们明天启用它，我们将不知道构建代理是否导致崩溃，除非它在那之前崩溃。

好的，接下来让我们看看队列大小是怎样的。

我希望“全局 C 状态控制”最终解决了这个问题，我认为我们需要高负载来测试它。

队列很长，主构建都挂了，因为他们需要 a7 进行网站部署。

所以我再次启动了a7代理。

由于主构建服务器上缺少磁盘空间，一些最近的 Jenkins 构建作业被取消。 我通过删除旧构建作业的日志释放了一些空间。 请注意，我可能还删除了一些新构建作业的日志文件。 在某些情况下，为您的最新提交构建的 Jenkins 可能会失败，您现在只会看到一些与 404 错误相关的消息。 在这种情况下，请只是

• 在 PR 下方的注释中使用jenkins build libelektra please重新启动 Jenkins 构建，或
• 重写最后一次提交而不进行更改（例如使用git commit --amend ）并强制推送

. 带来不便敬请谅解。

感谢您的维护！

我将节点v2-debian-buster标记

感谢您寻找基础设施！

v2 磁盘空间不足。 我执行了docker system prune总回收空间：58.37GB

然后我重新启动了 v2 并使代理再次连接。

我现在执行du -h | sort -h以查找要删除的其他文件。

我用一个新的 Docker 版本再次启动了 v2。 请立即报告损坏的构建。

我重新安装了 docker，清除了所有配置，并删除了 /var/lib/docker。 希望这能解决它。

v2 将再次包含在内。请立即报告损坏的构建。

正如这里所建议的

ethtool -K enp3s0 sg off # on v2
ethtool -K enp0s25 sg off # on i7
ethtool -K enp37s0 sg off # on a7 (internal network interface)

我还重新启动了 i7（有很多 docker 网络接口，它们现在已经消失了）

docker-ce 现在无处不在5:19.03.1~3-0~debian-buster

请立即报告损坏的构建。

看起来master构建再次失败，因为v2-debian-buster的连接问题（另请参见问题 #2995）。

我让我们的管理员看看 a7/v2/i7 之间的切换。 我暂时停用了 v2 和 i7。

我重新启动了 libelektra/master 和 libelektra-daily。

我们更改了所有 3 台 PC 的端口。

然后我删除了 v2/i7 上的 jenkins homedir 并重新启动了 v2/i7 代理。

看起来v2-debian-buster上没有更多可用空间：

ApplyLayer 退出状态 1 标准输出：标准错误：写入 /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o：设备上没有剩余空间

.

感谢您的报告，我在 v2 上腾出了（更多）空间。

删除作业完成：

已使用的文件系统大小 Avail Use% Mounted on
/dev/sda3 417G 227G 164G 58% /

buildserver 由于迁移而关闭（以便我们在新 buildserver 的备份中获得一致的状态）

https://build.libelektra.org/jenkins/又开始了

由于备份期间内核错误，构建服务器上的负载为 200，服务器不再反应，需要重置。

日志消息是（示例）：

[87400.120008]  [<ffffffff810be6a8>] ? find_get_page+0x1a/0x5f

[87372.120005]  [<ffffffff81357f52>] ? system_call_fastpath+0x16/0x1b
[87372.120005] Code: f6 87 d1 04 00 00 01 0f 95 c0 c3 50 e8 d7 36 29 00 65 48 8b 3c 25 c0 b4 00 00 e8 d0 ff ff ff 83 f8 01 19 c0 f7 d0 83 e0 fc 5a c3 <48> 8d 4f 1c 8b 57 1c eb 02 89 c2 85 d2 74 16 8d 72 01 89 d0 f0
[87372.120005] Call Trace:
[87372.120005]  [<ffffffff810be6cc>] ? find_get_page+0x3e/0x5f
[87372.120005]  [<ffffffffa016962f>] ? lock_metapage+0xc2/0xc2 [jfs]

[87400.110012] BUG: soft lockup - CPU#0 stuck for 22s! [cp:15356]

希望我们能在下周初尽快迁移（ @Mistreat ？）

服务器当前对raid进行重新同步，因此预计它会非常慢。

不再执行 Jenkins 构建，参见 #3035

詹金斯现在又开始了。 请重复 Jenkins 构建作业。

看起来v2-debian-buster处于离线状态：

打开到 a7.complang.tuwien.ac.at:22221 的 SSH 连接。
连接被拒绝（连接被拒绝）

.

谢谢，我联系了我们的管理员，但我担心他已经不在办公室了。

赫伯特昨天已经重新启动了 v2。 他禁用了“同时多线程”。

如果服务器（v2、i7、a7）再次崩溃，也请通过“herbert at complang.tuwien.ac.at”直接联系我们的管理员。 也请在此处报告，以避免多封电子邮件。

我认为v2-debian-buster上master分支的 Git 存储库有问题：

git fetch --tags --progress https://github.com/ElektraInitiative/libelektra.git +refs/heads/master:refs/remotes/origin/master +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128:
stdout: 
stderr: error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
fatal: loose object 9c0bc3ca6fcbc610abd845aeff5f666938d24117 (stored in .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117) is corrupt
fatal: the remote end hung up unexpectedly

. 我已经重新启动了三次构建，但 Jenkins 总是失败并出现相同的错误。

不幸的是，v2 有 btrfs，有时似乎会损坏文件。 我们在docker pull失败时已经遇到了类似的问题。 在当前情况下，文件 0bc3ca6fcbc610abd845aeff5f666938d24117 似乎已损坏。 在出现此文件时运行 md5sum 时，我得到：

b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/libelektra/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
d41d8cd98f00b204e9800998ecf8427e  ./workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117

我现在删除了 master 的整个目录并重新启动了构建。 另见#3054

由于我现在有几天没空，请联系“herbert at complang.tuwien.ac.at”关于无法访问 a7/i7/v2 的问题。 @Mistreat将负责与重新启动服务器无关的所有事情。 （希望我们能很快得到一个新的构建代理。）

也请始终在此处报告，以避免多封电子邮件，以便每个人都能很好地了解正在发生的事情。

构建服务器当前是否有故障？
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

构建服务器当前是否有故障？

似乎主要的 Jenkins 构建服务器无法连接i7 。 我将该节点标记为暂时离线。

在任意情况下构建失败：
这里被无故中断
这里一个测试用例失败了，它与我的 PR 无关（我只是添加了一个设计决策，不涉及任何代码）

这里被无故中断

我为两个 PR 得到了相同的中断代码 143，但还无法解释它们。 我重新启动了构建并希望它现在可以工作。

这里有一个测试用例失败，这与我的 PR 无关

多亏了@sanssecours #3103，这应该得到解决。 请rebase到master。

新的 Jenkins 节点hetzner-jenkins1似乎无法正常工作。 我将该节点标记为暂时离线。

我在 i7 上升级了 docker 并重新启动了机器。 我希望这能解决问题。 代理又上线了。 请在此处报告问题（和/或停用代理）。

目前，#3065 的作业正在 i7 上运行。

@Mistreat你能调试 hetzner-jenkins1 吗？

是否有可能在一段时间内轻松关闭链接检查？

一整天都在发生这种情况：

doc/tutorials/snippet-sharing-rest-service.md:63:0 http://cppcms.com/wikipp/en/page/apt
doc/tutorials/snippet-sharing-rest-service.md:158:0 http://cppcms.com/wikipp/en/page/cppcms_1x_config
doc/news/2016-12-17_website_release.md:94:0 http://cppcms.com
doc/tutorials/snippet-sharing-rest-service.md:62:0 http://cppcms.com/wikipp/en/page/cppcms_1x_build

其他 PR（最近的 #3115、#3113）也受到影响。 根据downforeveryoneorjustme链接确实不可用。

更新：该网站仍处于离线状态。 我为此#3117 做了一个 PR。

是否有可能在一段时间内轻松关闭链接检查？

您可以通过将单个链接添加到 tests/linkchecker.whitelist 来关闭它们（正如您已经发现的那样）

我无法从 Cirrus 重新运行失败的构建。 见https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

按钮什么都不做。 有什么魔术可以让它工作吗？

编辑：要么有人改变了某些东西，要么第 x 次尝试终于奏效了。 构建再次运行！ :)

看起来构建代理a7-debian-buster无法重新启动：

…
[10/28/19 06:02:59] [SSH] Starting slave process: cd "/home/jenkins" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout

.

编辑：要么有人改变了某些东西，要么第 x 次尝试终于奏效了。 构建再次运行！ :)

看到您的评论后，我也按下了“重新启动失败的构建作业”按钮。 据我所知，按下按钮确实重新启动了失败的构建作业。

看到您的评论后，我也按下了“重新启动失败的构建作业”按钮。 据我所知，按下按钮确实重新启动了失败的构建作业。

不过它对我不起作用，下次我会提供一些gif！

我将重新启动构建服务器及其节点。 #3121 和 #3099 的构建作业需要重新启动，因为它们在死代理上有作业。

不过它对我不起作用，下次我会提供一些gif！

你不需要提供GIF，因为我已经相信你了😊。

好像jenkins 有麻烦了，我等了一会儿才强行杀掉所有Java 进程。

我还升级了所有代理上的 docker（在 i7 上已经升级）。

Jenkins 再次按照#2984 中建议的心跳间隔启动。 所有节点都连接在一起。

请根据需要重新启动所有作业，并在此处报告任何问题。

v2 已关闭，我要求我们的管理员重新启动。

我再次启用了 v2，因为它似乎已经启动并且我们的构建积压工作已经足够大。

构建是否再次出现问题（ hetzner-jenkins1 ）？
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

构建是否再次出现问题（ hetzner-jenkins1 ）？

是的。 我禁用了节点。

它只是超出磁盘配额，我不想用内存过度使用它。 我现在把它清理干净了。 又起来了

节点更新。

我将 hetzner-jenkins1 增加到 4 个并行构建。 只要没有其他东西在那里运行，这只是一个临时措施。

由于测试套件超时，我暂时将 hetzner-jenkins1 上的执行程序数量从 4 减少到 2。 我认为当测试运行时正在编译太多作业时会发生这种情况。 我们可能需要限制单个容器可用的资源，以免过多干扰其他作业。

如果您认为这是错误的方法，请随时纠正它。

编辑：减少到 1 因为测试仍然超时并且不断重建浪费更多资源。

@mpranj感谢您修复它！

@mistreat你可能只分配了一个 CPU 或类似的吗？ 您可以分配更多并提高执行者的数量吗？ 硬件应该比 v2 更强大。

我禁用了i7-debian-buster因为没有剩余的磁盘空间导致所有构建失败。 如果有人可以访问，请清理并重新启用它。

@mpranj感谢您禁用！

抱歉，我目前所在的位置 ssh 被阻止（某些应用程序防火墙，其他端口上的 ssh 也不起作用）。 所以我现在无法访问或进行任何清理。

由于 i7 是代理中最弱的，所以它可能没什么大不了的。

@Mistreat你可能只分配了一个 CPU 或类似的吗？ 您可以分配更多并提高执行者的数量吗？ 硬件应该比 v2 更强大。

我不知道 v2 有多强。
目前jenkins1使用 4 个 CPU，8 个内存和 16 个交换。 我可以轻松增加它，我只是不知道您希望我增加到什么程度。

对未来硬件决策的说明：phoronix 似乎在他们的 CPU 文章中进行了编译测试（例如Ryzen 7 3700X、Ryzen 9 3900X 测试，在文章的底部）。

似乎 hetzner 最近将 AMD Ryzen 7 3700X 添加到他们基于 AMD 的服务器中。

我不知道 v2 有多强。

@ingwinlu在他的论文中写到了这一点（可在 abgaben repo lukas_winkler 中找到）

目前 jenkins1 使用 4 个 CPU，8 个内存和 16 个交换。 我可以轻松增加它，我只是不知道您希望我增加到什么程度。

只要我们没有在服务器上运行其他任何东西，您就可以分配所有资源。 以后我们还可以往下走（当我们移动詹金斯时）。

我更新了 hetzner-jenkins1。
前端内存不足的错误已得到纠正。
现在它运行 2 个并行构建。

看起来v2-debian-buster上没有剩余空间：

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

谢谢，我也把它标记为离线，直到有人可以清理它。

hetzner-jenkins1刚刚失败了我的 3 个 PR，因为超出了磁盘配额。 这是输出：

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on hetzner-jenkins1
/home/jenkins/workspace/libelektra_PR-3106-LB35J55FSRLFKFEU2WP6AWVLM3IH4JWI6C5B57NWB6DDARN4JDUA@tmp/ff803792-a127-4b8f-8588-439af982c8a4: Disk quota exceeded

由于超出磁盘配额，将hetzner-jenkins1标记为脱机。

我清理了 i7 和 v2（通过删除 /home/jenkins/workspace/* 并运行docker system prune ）。 现在我们有：

• i7：/dev/mapper/i7--vg-home 199G 152G 37G 81% /home
• v2：/dev/sda3 417G 255G 147G 64% /

然后我重新启动了代理。

@Mistreat能否请您修复#3160，以免这种情况再次发生如此之快。 还请修复 hetzner-jenkins1。 这台机器上有很多资源，它真的没有必要每天都达到资源限制。

我不知道是否有一个很好的方法来调整磁盘大小。 这就是为什么我没有立即为节点提供所有内容.. hetzner 又起来了。

v2 又没空间了，我清理了：/dev/sda3 417G 315G 102G 76% /

@Mistreat https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log不启动

我认为构建系统目前完全卡住了，没有构建 PR。

感谢您的报告，我将重新启动Jenkins并在光盘已满时清理一些文件。

@Mistreat https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log不启动

代理成功连接并在线

我认为 hetnzer-jenkins1 现在一切正常？

非常感谢！ 似乎 Jenkins 仍然没有对构建做出反应。 v2 和i7 现在都失败了： java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave 。

Jenkins 再次启动，请重新启动作业。

java.io.IOException: 无法将 slave.jar 复制到 slave 上的“/home/jenkins”。

固定（也没有空间）

@Mistreat请修复 jenkins-daily 因为这使得我们现在总是需要手动执行清理任务！

@Mistreat "jenkins build libelektra please" 仍然被破坏，这与 webhooks 的变化有关吗？

也许今天尝试更改为新的 Jenkins 但如果您无法做到，请让旧实例再次工作！

我触发了存储库扫描，现在“jenkins build libelektra please”似乎又起作用了。

看起来磁盘已满v2-debian-buster

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

很遗憾。 在解决之前，我将v2标记为离线。

感谢您的举报！

@mpranj我给了你访问权限，你可以尝试清理吗？

谢谢！ 在我看来，周围的 docker 旧图像浪费了大量资源。 此外，似乎 btrfs + docker 有问题。 Docker 为每个容器创建 btrfs 子卷，之后不会对其进行清理。 docker system prune -f命令也不会释放空间。

我将v2和a7用于维护以释放资源并平衡 btrfs。

docker登录失败

构建无法拉取 docker 镜像。 docker hub 出了什么问题？

是的，抱歉，我还用a7取消了 docker hub。 当它再次出现时，我会在这里发布一条消息。

a7包括 docker hub 再次启动。 我让v2离线，因为它无法登录集线器来拉图像？！？ 我不知道那里出了什么问题，我没有更改任何凭据，其他节点可以登录。 有任何想法吗？

Btrfs 还在后台平衡， a7可能再慢一个小时左右。

@mpranj谢谢你解决这个问题！ btrfs 重新平衡需要哪些命令？

不幸的是，我不知道凭据，我希望@ingwinlu可以帮助我们。

我用来重新平衡的命令是：

使用 btrfs 修复一个可能的错误：

btrfs balance start -dusage=0 -musage=0 /mountpoint

重新平衡fs真的，这需要很长时间。 可以/应该调整使用参数，这就是今天的工作：

btrfs balance start -dusage=80 /

凭据可以轻松更改，但我们必须使用新凭据登录所有再次连接到 docker hub 的 jenkins 代理。

更大的问题是一些 docker 容器仍在运行，而 docker system prune 没有做太多。 因此，我取消了代理并在其关闭时释放了所有内容。 周围有成吨的容器。

是的，不幸的是，容器很快就会重新创建。 我希望@Mistreat可以尽快修复 libelektra-daily 工作（它执行docker system prune ）。

我还做了一些相当复杂的数字取证并窃取了集线器凭据。 ：笑：

v2重新启动并运行。

非常感谢！ :100：请将凭据发送给我们。

发送。 顺便说一句，我认为a7可能只是因为磁盘速度很慢才慢，但它有足够的空间用于 docker hub 是件好事。 似乎大部分时间 CPU 在那里什么都不做。

另一个想法：也许我们可以为每个 cronjob 额外做一些关键的清理工作，以避免像我们现在这样的情况。

请将凭据发送给我们。

@mpranj我想我属于这群“我们”。 我不在某个 CC 或类似的地方？

@Mistreat抱歉，我已将其发送给 markus，但没有您的电子邮件。 在a7您会在 homedir 中找到CREDENTIALS.txt 。

我需要 hetzner-jenkins1 节点来测试新的 jenkins-server。 我要在旧服务器上关闭它，直到明天早上。

您可以轻松地为测试创建第二个 hetzner-jenkins2。 如果只是为了今晚，应该没问题。

另一个想法：也许我们可以为每个 cronjob 额外做一些关键的清理工作，以避免像我们现在这样的情况。

libelektra-daily 执行此清理工作，但现在失败了：#3160。 如果您有改进这项工作的想法，请告诉我们。

我想我属于这个“我们”的群体。 我不在某个 CC 或类似的地方？

是的，抱歉，我忘了告诉 mpranj，“我们”指的是您。

我希望我可以保留hetzner-jenkins1一段时间，现在所有构建都很好，我想我可以让服务器今晚完全运行。

v2无法访问，我联系了管理员。

我希望我可以将 hetzner-jenkins1 保留一段时间，现在所有构建都很好，我想我可以让服务器今晚完全运行。

这会很棒！

v2 无法访问，我联系了管理员。

谢谢，但我担心他在星期一之前不会回复。

v2 获得了一个新内核（它只是崩溃了）。

i7 也将重新启动。

所有 3 个服务器（v2、a7、i7）现在都有“Linux v2 5.2.0-0.bpo.2-amd64 #1 SMP Debian 5.2.9-2~bpo10+1 (2019-08-25) x86_64 GNU/Linux ”

它们已启动并在线，如果需要，请重新启动作业。

只是一个注意事项：
我用新服务器再次扫描了 repo。 这可能会对旧的产生一些错误..

似乎 master [1] 也建立在新服务器上。 它没有成功。 单击状态时，会出现一个登录页面 [2]。 请重新配置Jenkins，无需登录即可查看所有内容。

希望我们可以很快切换到新的 Jenkins。 看到来自两个不同 Jenkins 的错误并没有使情况变得更容易 :wink:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 :8080/login?from=%2Fjob%2Flibelektra%2Fjob%2Fmaster%2F1%2Fdisplay%2Fredirect

@markus2330 a7/v2 升级后可以远程重启还是有什么

通常它可以工作，但如果不紧急，最好等到管理员在那里。 如果这对你来说没问题，我可以在星期二重启？

谢谢！ 没什么紧急的，只是一个一般性的问题。 它的出现是因为 Debian 10.2 刚刚发布。 我会等一下升级。

尽管如此，您仍然可以进行升级（仅无需重新启动）。 然后，在崩溃的情况下，当管理员按下重置按钮时，我们已经拥有 10.2 内核：wink：

@mpranj您可以添加一个清除旧快照的 cronjob 吗？ 或者，如果不停止 docker，这是不可能的？

https://docs.docker.com/storage/storagedriver/btrfs-driver/建议在 cronjob 中也重新平衡 btrnfs。

您可以添加一个清除旧快照的 cronjob 吗？ 或者，如果不停止 docker，这是不可能的？

我可以在不停止所有 docker 容器的情况下添加 cronjob。 这可能不会清理所有内容，但我们可以尝试一下。 就像我说的，有时容器会一直运行/直到机器崩溃。 完全清理需要我们暂时禁用构建代理，然后我们可以强制停止所有容器。

我还可以将重新平衡添加为 cronjob。

谢谢，让我们试试。

师父内存不足。 我想在旧的 Jenkins 上运行 Scan Repository，因为 a7 和 i7 在拉取 docker 图像时出现以下错误：

docker登录失败

我现在在新服务器上运行了 v2 和 hetzner-jenkins1。

师父内存不足。

谢谢举报。 我删除了一些旧的覆盖数据并再次启用主节点。 对于所有有开放拉取请求的人：请使用jenkins build libelektra please重新启动您的 Jenkins 构建。 带来不便敬请谅解。

在 #3234 @raphi011 中建议：

imo 这真的很紧急，如果您必须等待这么长时间来验证它们，那么测试的脆弱性和缓慢性使得即使不是不可能也很难进行任何更改。

我同意这真的很紧急，但@Mistreat已经做了他能做的。

所以也许我们可以更谨慎地使用构建服务器，并且只有在我们真的认为 PR 将很快被合并时才构建。 应该取消不必要的构建。

或者（暂时）停止在推动更改时自动构建 PR（因此构建仅以jenkins build libelektra please ）呢？ @Mistreat你知道如何重新配置​​ Jenkins 吗（我没有找到这个选项）？

我也觉得jenkins build libelektra please目前不起作用，至少它不适用于这个构建： https :

在 a7 和 v2 上实现了清理 cronjob 和向后移植内核。 内核有相当多的更新日志，它将在下次重新启动时处于活动状态。

非常感谢！ 是否仍然安装了“旧的”向后移植内核，以便在它无法启动时进行回退？

是的，它可以在成功引导到新内核后删除。

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on i7-debian-buster

docker login failed

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3244/1/pipeline

我禁用了i7以进行手动清理、内核和 docker 升级。 有人在我工作时启用了i7 。 一切都重新启动并运行。

@Piankero我现在重新启动了你的构建。

我也觉得jenkins build libelektra please目前不起作用，至少它不适用于这个构建：#3073 我不得不推送一个空提交来启动管道。

现在工作

@Mistreat你知道如何重新配置​​ Jenkins 吗（我没有找到这个选项）？

我在 Jenkins 配置中添加了以下内容：

抑制自动 SCM 触发

给大家的提示：现在必须使用“jenkins build libelektra please”，构建作业不是通过简单的推送开始的。 当我们恢复此设置时，我们会在此处通知。

@虐待谢谢！ 让我们看看这是否足够。 我希望推送到 master 仍然会触发 master 构建？

尽管如此，拥有 hetzner 节点会非常好。 如果该节点同时被两个构建服务器使用，会不会有什么问题？ 或者如果这是一个问题：简单地克隆CT是不是很容易？

@虐待谢谢！ 让我们看看这是否足够。 我希望推送到 master 仍然会触发 master 构建？

master 分支现在是以下规则的一个例外：

抑制自动 SCM 触发

至于

尽管如此，拥有 hetzner 节点会非常好。 如果该节点同时被两个构建服务器使用，会不会有什么问题？ 或者如果这是一个问题：简单地克隆CT是不是很容易？

我添加了一个新的 CT（hetzner-jenkinsNode3）。

无法克隆 repo： https :

也许这与新节点有关？ （胡乱猜测）

也许这与新节点有关？ （胡乱猜测）

这个错误是在 a7

这个错误是在 a7

soooo .. 重试？

soooo .. 重试？

是的，我不认为它会再次发生..

我会为你重新运行它。

@Mistreat我认为我们可以再次开始自动构建。 但是请先看#3160。

知道为什么这会失败吗？

go: github.com/google/[email protected]: Get https://proxy.golang.org/github.com/google/uuid/@v/v1.1.1.mod: net/http: TLS handshake timeout

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2827/8/pipeline/648

知道为什么这会失败吗？

听起来这是一个临时问题，当前可以从构建代理访问该 URL。

从长远来看，最好在 docker 镜像中设置这些依赖项，以避免为每个构建重复下载它们。 这也应该可以防止由于上面提到的暂时不可用的包而导致构建失败。

那么.. jenkins build libelektra please第三个

是的，正是出于这个原因，我们直接在 docker 镜像中拥有所有依赖项。 我创建了#3251

我让 v2 ​​和 a7 离线重新启动。

@markus2330如果有机会，请在a7上启用超线程。

v2 再次启动，在 a7 上仍有构建作业。

我将节点添加到新服务器中。 我要让它运行一夜。 明天，如果新的 Jenkins 服务器上还有其他错误，我将返回节点。

hetzner-jenkinsNode3仍将在旧的 Jenkins 上运行。

明天，如果新的 Jenkins 服务器上还有其他错误，我将返回节点。

小的构建错误不是切换回来的理由。 在某些时候我们需要修复错误，来回非常耗时。

然而，新服务器无法访问，这可能是一个阻碍。 （两者都不
http://95.217.75.163:8066 或 ssh）。 我按下了电源按钮，让我们看看机器是否重新启动。 不过，我们应该调查问题出在哪里。

http://95.217.75.163 :8066

如果有时间，请使用 letencrypt 启用 TLS，这样我们就不会泄露凭据并使自己面临各种其他问题？

谢谢你的反馈！ 我建议我们在切换 build.libelektra.org 时立即执行此操作。 否则我们需要双重努力。

这个错误是已知的吗？ Caught the following exception: null

看起来格式检查失败，其他构建已终止。

你是对的。 多么糟糕的错误信息：P

@Mistreat你能再次激活 PR 是自动构建的吗？ 由于有许多代理，服务器现在大部分时间都在休眠。

@Mistreat你能再次激活 PR 是自动构建的吗？ 由于有许多代理，服务器现在大部分时间都在休眠。

完毕。

我将为新服务器再次借用hetzner-jenkins1和v2 。

你不需要还给它，我希望我们今天可以切换。

提示：在进行此类切换时，最好将 DNS 条目的 TTL 降低到异常低的值（例如，60 而不是目前 build.libelektra.org 的 21599）。 更改传播后，它应该让我们在一分钟而不是几小时内切换 DNS 条目。 如果为时已晚，它可以帮助清除 google 和 opendns 的 DNS 缓存，但有些人将不可避免地看到旧资源，直到缓存条目在全局范围内过期。

编辑：更改后 TTL 显然应该恢复到某个合理的值以减少 DNS 的负载。

即使现在可能为时已晚，我还是切换了$TTL 3600 （如果我们需要进行多次更改直到一切正常）。

www-new 和 build-new 已经存在指向新服务器。

我现在切换了 doc.libelektra.org。 @Mistreat将修复发布。 我会看看 www-new.libelektra.org

https://build-new.libelektra.org/和https://www-new.libelektra.org/home现在应该可以工作了。

我现在将更改所有 DNS 条目。

所有 DNS 条目都已更改。

不幸的是，certbot 失败，因为它似乎与旧服务器对话，但这似乎只影响下载和社区（较少使用的 URL）。

所以希望在周末期间/之后，每个人都能看到更新的 DNS 名称。

@Mistreat请更新所有工件的发布：也适用于网站。 请创建一个 PR 以确保一切正常。

旧的构建服务器现已关闭。

我需要重新启动新服务器（添加了新内核和网桥）。

服务器使用 Linux pve 5.0.21-5-pve 再次启动。

我安排了对所有 PR 的重新扫描。

由于 pve 中的错误配置/错误（/etc/network/interfaces 被 GUI 删除？），服务器离线。

错误是网络设备的重命名（由我在 GUI 中的操作引起）导致内核 OOPS：

Nov 23 21:32:08 pve kernel: [ 1682.138250] veth4d0199f: renamed from eth0
Nov 23 21:32:19 pve kernel: [ 1693.378374]  __x64_sys_newlstat+0x16/0x20
Nov 23 21:32:19 pve kernel: [ 1693.378380] Code: Bad RIP value.
Nov 23 21:32:19 pve kernel: [ 1693.378382] RDX: 00007fa58b238e20 RSI: 00007fa58b238e20 RDI: 00007fa58ba50d24
Nov 23 21:32:19 pve kernel: [ 1693.378383] R13: 0000000000000294 R14: 00007fa58ba50cc8 R15: 00007ffe65c2b158
Nov 23 21:34:20 pve kernel: [ 1814.210370]  request_wait_answer+0x133/0x210
Nov 23 21:34:20 pve kernel: [ 1814.210374]  fuse_simple_request+0xdd/0x1a0
Nov 23 21:34:20 pve kernel: [ 1814.210378]  ? fuse_permission+0xcf/0x150
Nov 23 21:34:20 pve kernel: [ 1814.210381]  path_lookupat.isra.47+0x6d/0x220
Nov 23 21:34:20 pve kernel: [ 1814.210385]  ? strncpy_from_user+0x57/0x1c0
Nov 23 21:34:20 pve kernel: [ 1814.210388]  __do_sys_newlstat+0x3d/0x70
Nov 23 21:34:20 pve kernel: [ 1814.210392]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

服务器应该重新启动并运行。

但是，以前的问题仍然存在（短语不起作用＃3268）

@Mistreat大师似乎也不再自动构建，我现在手动触发它。

我正在收集 #3268 中的紧急错误。 如果您还可以测试一切是否如 doc/BUILDSERVER.md 中所述那样工作，那就太好了。

jenkins 不会在没有任何给定原因的情况下构建：
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

另一个构建错误： https :

感谢您的举报！

@Mistreat你能不能安装 Naginator+Plugin #2967 已经讨论过很多次了？ （请在更改 Jenkins 之前制作快照。）

hetzner-jenkins1 : 超出磁盘配额

@Mistreat你能不能安装 Naginator+Plugin #2967 已经讨论过很多次了？ （请在更改 Jenkins 之前制作快照。）

今天要做

hetzner-jenkins1：超出磁盘配额

@mpranj当hetzner-jenkins1关闭时，我添加了新的VM作为构建代理。

我通过运行docker system prune -a清理了 hetzner-jenkins1 上的一些空间并再次启用它。

似乎又出现了一个问题，即docker system prune -f没有清理很多东西。 这次存储驱动程序不是btrfs而是vfs 。 ：使困惑：

当 hetzner-jenkins1 关闭时，我添加了新的 VM 作为构建代理。

现在的想法是我们不再使用容器，而只使用虚拟机。

我通过运行 docker system prune -a 清理了 hetzner-jenkins1 上的一些空间并再次启用它。

非常感谢！ 你也可以在那里做一个cronjob吗？ （在虚拟机上，而不是在容器上）。

在那里做一个cronjob？

完毕。

@Mistreat你能不能安装 Naginator+Plugin #2967 已经讨论过很多次了？ （请在更改 Jenkins 之前制作快照。）

如果我们想要 naginator 插件，我们必须从管道转移到自由式工作。 我要寻找替代品。

在 VM jenkinsNode3VM上构建当前失败。 他们无法 docker pull：

unexpected EOF
script returned exit code 1

我暂时禁用它，直到有人可以解决问题。

[cronjob] 完成。

谢谢！

如果我们想要 naginator 插件，我们必须从管道转移到自由式工作。 我要寻找替代品。

是的好主意。 也许最好在我们的 Jenkinsfile 中简单地编写代码。 因此，如果有问题的构建作业/阶段失败，则会重试。 这些 docker pull 至少尝试了两次，因为这是最常见的问题之一。

在 VM jenkinsNode3VM 上构建当前失败。 他们无法 docker pull：

@Mistreat请解决这个问题。

在 VM jenkinsNode3VM 上构建当前失败。 他们无法 docker pull

我修复了无法拉取的docker镜像。

非常感谢！ 如果你写出错误的地方以及你如何修复它，这总是有帮助的。

我不知道出了什么问题，我在代理上手动构建了图像。 由于代理无法拉动它。

至于 Dockerfile (scripts/docker/debian/stretch)我的Visual Code说它最后有 2 行空行，但vim说它只有一个。 我不知道它是否必须做一些上面的错误，也许只是我的VS 。

似乎我们的 docker 注册表有问题（#3316 docker pull 失败， unexpected EOF ）。

由于发布后尘埃落定并且没有进行任何构建，我建议停止一切并尝试完全清除注册表。 之后，所有图像都应该干净利落地重建。 我会在开始之前备份注册表数据只是为了确保，但我希望一个干净的开始可以消除我们遇到的一些错误。

在我开始之前，我会等待评论是否有任何反对意见。

我认为这是一个问题

（脚本/docker/debian/stretch）

图像，因为它是唯一失败的。

我再次手动构建了它，但注册表中的图像肯定有问题。

Jenkins 报告：jenkinsNode3VM（离线）

如果您可以设置某种监控方式， @Mistreat会很棒。

a7 （因此v2和i7 ）下跌。 我联系了管理员。

编辑 markus2330：再次启动

由于 TU Wien 计划于 2020 年 7 月 8 日停电，我们的管理员计划在前一天（7.7 星期二）关闭所有构建服务器。 在此期间构建将非常缓慢，因此请仅在紧急情况下当天推送。

除 i7 外，服务器再次在线。 我通知了管理员。

昨天晚上又发生了一次停电（计划外），因此所有构建服务器现在都关闭了。 管理员正在处理它。

30 分钟后编辑：包括 i7 在内的所有内容再次启动：火箭：

@markus2330似乎 v2 和 i7 最近失去了互联网访问权限（可能是在停电期间？）。 您是否知道我们应该进行任何配置更改，因为接口是静态配置的？

我不知道有什么变化，只知道在这两次停电（一次计划中，一次意外）后，计算机又重新打开了。

但是你是对的，我也看到他们这两个（但不是 a7）不再有互联网连接，尽管他们可以访问。 我问过我们的管理员。

也许我们会断开他们与 Jenkins 的连接，直到这个问题得到解决？

感谢您联系管理员！ 我断开了 i7 和 v2 的连接，直到问题得到解决。 （无论如何，构建都不起作用，因为它们无法拉取 docker 图像）

大约一周前，有人对路由器进行了一些更改。 该人已收到通知，并希望尽快修复。

让我们暂时让它们断开连接。

Internet 问题现已解决，我还在这些机器上安装了安全更新。

@mpranj你

谢谢@markus2330。

所有节点现在都重新联机。

我为最新的 PVE 内核重新启动了构建服务器。 詹金斯应该很快就会起来。

我搬家了

• [ ] 如果构建失败，则发送电子邮件更可靠
• [] 没有 Jenkins 用户的 Docker 镜像
• [] centOS/fedora/arch docker 镜像
• [] centOS 软件包
• [] freebsd/openbsd/solaris 构建代理

到#3519 并链接到上面的#3519。

@robaerd现在也可以访问 a7/v2/i7，并且可以在遇到问题时联系管理员。

只是构建时间的快速报告（主管道libelektra ）：

• 启用a7 ： 2h 29m 24s
• 禁用a7 ： 1h 35m 45s

为什么 Jenkins 显示它已关闭？ 总是提前在这里阅读会很好:wink:

由于完整的系统备份和文件系统从 btrfs 到 ext4 的重新格式化，Jenkins 将被关闭。

詹金斯又起来了

Jenkins CI 将于今天欧洲中部时间 11:15 左右下线进行维护。

我们将执行一些备份和清理任务，并尝试提高a7 。

维护结束后会再次通知。

Jenkins CI 和所有构建服务器再次启动。 a7现在应该表现得更好，但存储容量较小。

如果您遇到任何错误，请报告。

Jenkins CI 和构建代理将离线进行短暂的维护/更新。

编辑：更新完成。

服务器已关闭，我正在调查。

服务器又起来了。

关于原因的官方声明：“相邻服务器中的 PSU 存在问题，导致服务器关闭；现已更正。”

a7的 ssd 已满，导致其上的所有构建都失败。

我会尽量腾出一些空间。 现在从 jenkins 断开a7构建代理是否安全？

感谢您的调查！

我会尽量腾出一些空间。 现在从 jenkins 断开 a7 构建代理是否安全？

当然。 相反，如果它使所有构建失败，保持连接将是不安全的。

运行docker system prune -a再次清理了大约 50% 的空间。 也许我们需要调整现有的 cronjob 来添加-a标志？

詹金斯之家也使用了大量空间。

主构建（带有 deb 包和网站构建的完整管道）不知何故仍然失败，即使一切看起来都是绿色的。 有任何想法吗？

在文件elektra_0.9.3.orig.tar.gz上将焦点 deb 包上传到community失败。 这可能是文件的权限问题。 我现在将从目录中删除它，并在下次运行时重新创建它。

不知何故，如果 sshPublisher 失败，它不会将舞台设置为红色。

也许我们需要调整现有的 cronjob 来添加 -a 标志？

你有什么理由不这样做吗？ 如果没有，听起来是个好主意。

Jenkins CI 和a7上的注册表将脱机以将瞭望塔映像迁移到新版本。 应该只需要几分钟。

编辑：更新完成，Jenkins CI 再次启动

詹金斯和特工将暂时停止更新。

编辑：一切都已更新，并再次启动和运行。 我需要更正a7使用 Debian 拉伸 docker 软件包而不是 buster 的问题。 我也清理了一些空间。

构建失败，因为a7上没有空间。

构建基础设施将在几分钟内不可用以进行维护。

构建基础设施再次可用。