インフラ」カテゴリーアーカイブ

whoisをaptで入れたかっただけなのにnfsが止まっているだけで固まったっぽい

sudo apt install whois

入っていなかったので気軽にぽちっとな。といったところ

Fetched 51.7 kB in 3s (20.5 kB/s)
Selecting previously unselected package whois.
(Reading database ... 84374 files and directories currently installed.)
Preparing to unpack .../whois_5.5.22_amd64.deb ...
Unpacking whois (5.5.22) ...
Setting up whois (5.5.22) ...
Processing triggers for man-db (2.12.0-4build2) ...

ここいらで固まった。

root     2325613 2325562  0 11:19 pts/2    00:00:00 sudo apt install whois
root 2325619 2325613 0 11:19 pts/3 00:00:00 sudo apt install whois
root 2325620 2325619 0 11:19 pts/3 00:00:00 apt install whois
root 2325694 2325620 0 11:19 pts/3 00:00:00 apt install whois
root 2325709 2325694 0 11:19 pts/3 00:00:00 sh -c -- test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke -m u || t
root 2325710 2325709 0 11:19 pts/3 00:00:00 /usr/bin/perl /usr/sbin/needrestart -m u

pid 2325710で動いていないっぽいので

yoshitake@epeasv01:~$ sudo cat /proc/2325710/stack
[<0>] rpc_wait_bit_killable+0x11/0x90 [sunrpc]
[<0>] __rpc_execute+0x121/0x340 [sunrpc]
[<0>] rpc_execute+0xda/0x110 [sunrpc]
[<0>] rpc_run_task+0x12e/0x190 [sunrpc]
[<0>] nfs4_do_call_sync+0x6b/0xc0 [nfsv4]
[<0>] _nfs4_proc_getattr+0x13b/0x180 [nfsv4]
[<0>] nfs4_proc_getattr+0x6e/0x110 [nfsv4]
[<0>] __nfs_revalidate_inode+0xd7/0x3c0 [nfs]
[<0>] nfs_access_get_cached+0x1da/0x280 [nfs]
[<0>] nfs_do_access+0x63/0x290 [nfs]
[<0>] nfs_permission+0x9a/0x1f0 [nfs]
[<0>] inode_permission+0xff/0x1b0
[<0>] link_path_walk.part.0.constprop.0+0x130/0x3c0
[<0>] path_lookupat+0x3e/0x1b0
[<0>] filename_lookup+0xe4/0x200
[<0>] user_path_at_empty+0x3e/0x70
[<0>] do_readlinkat+0x6d/0x140
[<0>] __x64_sys_readlink+0x1e/0x30
[<0>] x64_sys_call+0x1c24/0x25c0
[<0>] do_syscall_64+0x7f/0x180
[<0>] entry_SYSCALL_64_after_hwframe+0x78/0x80

スタックトレース中を見たらrpc_wait_bit_killableとかいっている。nfsが何やらともいっている。

直接の原因はnfsのrpc呼び出しが待ち状態でエンドレス待機中の模様。

身に覚えがあるといえば自動再接続設定しているnfsホストが停止中なのこと。これのせいかな?

という事で調べる

とりあえずcronからバックアップしているのでpsしたら終わっていないやつらが大量に待機中。

sudo systemctl stop cron

だと、待機中のrsyncプロセスは実行中のまま。(それはそう)ということで様子をみながら手動でpid指定でぺちぺちkill。と思ったが途中で面倒になったのでまとめてpkill。

消えないプロセスいたのでkill -9

作業が終わって、apt installが固まっていたコンソールを見たら処理が完了していた。きちんと見ていないのでいつ処理が再度走り出したかは未確認

とりあえず、cron止めておいた。nfsホストがお亡くなりなので直さなくては。

docker composeで作っていたzabbixをバージョンアップして再構築しようとしたら色々はまったときのメモ

mysqlのlatestイメージとzabbix-server-mysql:alpine-7.0-latestの組み合わせだとDBの権限が足りなくて初期構築のsqlが実行されない

docker compose を初回起動するとおおよそ以下のようなエラーが出た

ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

zabbixサーバー(zabbix-server-mysql)からdbに初期構築のsqlを実行しようとするが、バイナリログを使用しているときには特別に権限が必要らしい。意図的にはバイナリログを有効にしていないしDockerのmysqlだと通常無効と調べている途中で見たが実際にできたDBを覗くとバイナリログが有効になっている。

mysql> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+

my.cnfカスタマイズしている影響の可能性もあるけど、下のコマンドで素の引っ張りたてイメージでもバイナリログ有効になっていた。

 docker run -it --name test-wolrd-mysql -e MYSQL_ROOT_PASSWORD=mysql -d mysql

このへんから呼ばれるcreate.sql.gzの中身で呼ばれているっぽい。qz自体はzabbixのものでたぶんここらへんでつくられている模様。(ちゃんと見ていない)zabbix-serverの/usr/share/doc/zabbix-server-mysql/create.sql.gzを見ようとしたけど長いので見るのやめた。何か制約にかかるトリガーとかを作っているのだと思う。

対処法

my.confに以下を追加

[mysqld]
log_bin_trust_function_creators = 1

制約回避の設定。他にも回避策の指定は色々あるらしい。

zabbix-agentとのバージョン違い?

zabbix-server-1 | 197:20240929:102940.592 unknown request received from “192.168.xxx.yyy“: [active check heartbeat]

みたいなメッセージがzabbix-serverのログに出ていて、zabbixのGUIのエージェント死活監視の色が緑にならず灰色のままだった。データ自体は取れている模様。

対処法

エージェントとサーバのバージョンを合わせた。(他にもいろいろやっていた中だったのでたまたまの可能性もなくはない)

zabbiz-agentでサーバ側のipを指定する必要があるがdocker composeの素の状態だと変わってしまう

zabbix agent(/etc/zabbix/zabbix_agentd.conf)でServer,ServerActiveにzabbixサーバのIPを指定する必要があるがcompose内で明確に指定しないとipが変わってしまうので接続できなくなる時がある。

対処法

ipを固定すればよい。

まずはdocker-compose.ymlで、下みたいにカスタムネットワーク作ってIP指定する。

services->zabbix-server->networks->zabbix2hostでの利用指定とnetworks->zabbix2hostでのネットワーク作成。

services:
  zabbix-server:
    build: ./server
    cap_add:
      - NET_ADMIN
    restart: always
    depends_on:
      - db
    volumes:
      - "./data/zabbix:/var/lib/zabbix"
    environment:
      DB_SERVER_HOST: db
      MYSQL_USER: ほげ
      MYSQL_PASSWORD: ふが
    ports:
      - "10051:10051"
    networks:
      zabbix2host:
        ipv4_address: 192.168.100.2
      default: {}

networks:
  zabbix2host:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.100.0/24

zabbix2hostとdefaultの二つのネットワークに所属しているのでルーティング設定も必要。(zabbix-serverで使うネットワークが一つならおそらく不要)

dockerイメージでip route を使うがdocker-compose.ymlでcap_add:NET_ADMINの権限を付与していないと使えないはず。(もしくはprivileged指定)

docker起動時にルーティングをするようにentrypointとなるシェルを作成。

#!/bin/sh
# route2はdocker fileにてインストール済み
#向き先 host gwはcomposeで作成したネットワークのもの 
sudo ip route add 192.168.1.2 via 192.168.100.1

exec docker-entrypoint.sh "$@"

192.168.1.2(zabbix-agentが実際に動いているdockerのホストIP)は192.168.1.2(zabbix-agentが実際に動いているdockerのホストIP)は192.168.1.2(zabbix-agentが実際に動いているdockerのホストIP)は作ったネットワーク(192.168.100.1)を使う設定。

ルーティングだけ追加したら、元々のエントリーのdocker-entrypoint.shを呼び出し元のパラメータ付きでコール

で、Dockerファイルも作成

FROM zabbix/zabbix-server-mysql:alpine-7.0-latest

# 元イメージでユーザーがzabbix(1997になっているので一旦切り替え)
USER 0
COPY add-route-entrypoint.sh /usr/local/bin/add-route-entrypoint.sh
RUN chmod +x /usr/local/bin/add-route-entrypoint.sh && apk add --no-cache iproute2 && apk add --no-cache sudo && echo "zabbix ALL=(ALL) NOPASSWD: /sbin/ip" >> /etc/sudoers
USER 1997

ENTRYPOINT ["add-route-entrypoint.sh"]
CMD ["/usr/sbin/zabbix_server", "--foreground", "-c", "/etc/zabbix/zabbix_server.conf"]

alpineだとiproute2もないのでapk(alpineのapt相当)でインストール。sudoも使うのでインストール、シェル実行時にパスワードがいいらないように/etc/sudoersも編集。

あとは作ったadd-route-entrypoint.shをエントリーポイントにして、zabbix/zabbix-server-mysql:alpine-7.0-latestと同じCMDをつけて呼び出し。(ENTRYPOINT付けたらベースイメージのCMDがクリアされていた。引き継がれる気がしていたけどどこか間違っている?)

netplanのgateway4がdeprecatedになっていた

sudo vi /etc/netplan/50-cloud-init.yaml
network:
    ethernets:
        enp2s0:
            dhcp4: false
            addresses:
              - 192.168.1.5/24
            gateway4: 192.168.1.1
            nameservers:
              addresses:
                - 8.8.8.8
                - 8.8.4.4
    version: 2

からの

sudo netplan try

** (process:991): WARNING **: 08:38:09.630: gateway4 has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.

と怒られた。

gateway4がdeprecated(非推奨)になってrouteを使えとのこと

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 192.168.1.100/24
      routes:
        - to: 0.0.0.0/0
          via: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

Dockerがhostのネットワークを使っている場合routingがこのto設定の影響を受けるので要注意

Ubuntuを24にメジャーアップグレードしたらZabbix-agentがなくなったので再インストール

以前インストールしていた(こちら)zabbix-agentがUbuntuのメジャーアップグレードのタイミングでなくなっていた。再度インストールしなおしたときの手順。

zabbixのレポジトリ再インストール

wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1%2Bubuntu24.04_all.deb
sudo dpkg -i zabbix-release_6.4-1+ubuntu24.04_all.deb

からのaptインストール

sudo apt update
sudo apt install zabbix-agent

/etc/zabbix/zabbix_agentd.confのServer,ServerActive,Hostnameを監視サーバのドメインに書き換え

Server=kanshi.epea.co.jp
ServerActive=kanshi.epea.co.jp
Hostname=kanshi.epea.co.jp

サービス登録

sudo systemctl start zabbix-agent
sudo systemctl enable zabbix-agent

上記で動いたっぽい

Found orphan containers

docker-composeを新たに作成して実行したところ以下のワーニングが出た。

WARNING: Found orphan containers (proxy_letsencrypt-nginx-proxy-companion_1, nginx-proxy) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.

こちらにあるように他のdocker-composeとの名前重複が原因。

]新しいdocker-composeだとドキュメントによると以下のようにname要素(top level element)が存在し名前重複を避けられるそう。ただ、一時期バグがあって使えない時期もある模様。

対応していないと思われる私の環境では以下のエラー

ERROR: The Compose file './docker-compose.yml' is invalid because:
Invalid top-level property "name". Valid top-level sections for this Compose file are: version, services, networks, volumes, secrets, configs, and extensions starting with "x-".

現在の環境は長く使わない予定なので他の暫定対処を選択する。

環境変数にCOMPOSE_PROJECT_NAMEを指定しても同じ効果があるそうなので。docker-compose.ymlと同じディレクトリに.envを以下内容で作成。

COMPOSE_PROJECT_NAME=momoyama_shop

そしてdocker-compose buildをすると以下のように指定したcompose_project_nameを持つイメージが作成された。

Building front
Step 1/2 : FROM nginx
---> 92b11f67642b
Step 2/2 : RUN echo 'server_tokens off;\n' > /etc/nginx/conf.d/my_default.conf
---> Using cache
---> 597e7dfaab23

Successfully built 597e7dfaab23
Successfully tagged momoyama_shop_front:latest

CentOS7でyumのDB再構成

とあるパッケージを入れようとすると、エラー: db5 エラー (5) (dbcursor->c_get において): 入力/出力エラーです。といわれた

どうもyumで使っているrpmのDBが壊れたらしい。

DBファイルがある/var/lib/rpmに移動しDBファイルを一応バックアップとったうえで削除し、DBのrebuild実行。

むぅ。パッケージ名の整合性チェックは通った

が、試しにパッケージ名を読み込みなおしてみた

その後sudo rpm –rebuilddbで動いた。

整合性チェックはツール上では通ってたけどそこでかからないレベルでおかしくなってたのかな?

c_getで引っかかってしまったってことはbit単位ぐらいでおかしくなってそうだし。(いつも通り細かくは追わない)

Ubuntu 22.04.4にzabbix-agentをインストール(apt-get)

2024/09/19追記

ubuntsu24にアップデートした際にzabbix用のレポジトリがなくてupdateできなかった。もしかしたら下記のインストール手順の前にapt用のレポジトリの設定がいるかも。設定方法は以下のイメージ。debファイルのバージョン部分に関してはこちらの公式ページを見て適宜インストールするOS情報で書き換え

wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1%2Bubuntu24.04_all.deb
sudo dpkg -i zabbix-release_6.4-1+ubuntu24.04_all.deb

バージョン

エージェントを入れるサーバー側の作業

インストール(インストール時のログは下の方に張り付けておいた)

とりあえず起動(同じくログは下の方に張り付けておいた)

設定開始前のファイル退避

/etc/zabbix/zabbix_agentd.confのServerとHostnameを編集して(hostname設定したけど使わないかも)

サービス再起動

必要ならエージェント側のポートのファイヤウォールを開ける

本体サーバー側の作業

すでにある前提で、Webの画面からログイン

Configration->Hostsから右上の”Create host”ボタンを選択

name任意、group任意、inrterfaceはアージェントのサーバの値、必要ならテンプレートを指定。

しばらく待っていると通信できてたらConfigrationのhostsに生えてきた追加したhostのAvailability->ZBXが緑になる。

ログ関係

インストール時ログ

起動設定時ログ

Jenkinsのshh-agentがつながらない

一気にすべてをアップデートしたので何が原因かわからないけどshh-agentがつながらなくなっている。

DockerのJenkinsからその中のssh-agentを使うというめんどくさそうな構成

これから細かく調べるが

FATAL: [ssh-agent] Could not find specified credentials
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider

(スタックトレースは長くなるので下のほうに張り付け)

本来だと以下みたいになる

[ssh-agent] Using credentials (credentials名) 
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent]   Exec ssh-agent (binary ssh-agent on a remote machine)
$ docker exec 80f7594988d50d5a190f788b4ffab62d8902fb594ebfffe3c282f6ace8ee88ba ssh-agent

死んでいるのはこの辺の処理

SSHAgentの拡張ポイント使っているプラグインがないか、あるけどfactory.isSupported(launcher, listener)のとこでダメっぽい。

こいつかな?ssh-agentがキルできないと(≒すでに生きていないと)いけない判定がある

よくみたら0か1ならよかった。

あまりにもわからないからプラグインにログ入れてみたらstatus が126といっている。

ログの埋め方はこちら

[ssh-agent] Looking for ssh-agent implementation...
[Loaded]   Exec ssh-agent (binary ssh-agent on a remote machine)
status: 126

こちらをみると実効権限がないと。

[Loaded]   Exec ssh-agent (binary ssh-agent on a remote machine)
OCI runtime exec failed: exec failed: unable to start container process: exec: "ssh-agent": executable file not found in $PATH: unknown
status: 126

さらにログ埋めたらうえ

そしてさらにさまよったら、ssh-agent入れなきゃいけないのはjenkinsファイルに書いてあるimageなことにやっと気づいた。ブログ書きながらやったけどただのポカミスだ。。。

pipeline {
	agent {
		docker {
			image 'kyoshitake/maven'

長くなった元々のスタックトレース

Also: org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: 594109d1-aaf2-4c19-97c1-539affc618f2 java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider. at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.initRemoteAgent(SSHAgentStepExecution.java:176) at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.start(SSHAgentStepExecution.java:64) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:323) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:196) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:124) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1225) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:180) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:163) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:178) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:182) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17) at org.jenkinsci.plugins.workflow.cps.LoggingInvoker.methodCall(LoggingInvoker.java:105) at WorkflowScript.run(WorkflowScript:18) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.delegateAndExecute(ModelInterpreter.groovy:137) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.executeSingleStage(ModelInterpreter.groovy:666) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.catchRequiredContextForNode(ModelInterpreter.groovy:395) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.catchRequiredContextForNode(ModelInterpreter.groovy:393) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.executeSingleStage(ModelInterpreter.groovy:665) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:288) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.toolsBlock(ModelInterpreter.groovy:544) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.toolsBlock(ModelInterpreter.groovy:543) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:276) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:443) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:442) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:275) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withCredentialsBlock(ModelInterpreter.groovy:481) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withCredentialsBlock(ModelInterpreter.groovy:480) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:274) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inDeclarativeAgent(ModelInterpreter.groovy:586) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inDeclarativeAgent(ModelInterpreter.groovy:585) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:272) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.stageInput(ModelInterpreter.groovy:356) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.stageInput(ModelInterpreter.groovy:355) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:261) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inWrappers(ModelInterpreter.groovy:618) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inWrappers(ModelInterpreter.groovy:617) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:259) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:443) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:442) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:254) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:90) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:116) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:85) at jdk.internal.reflect.GeneratedMethodAccessor167.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46) at com.cloudbees.groovy.cps.Next.step(Next.java:83) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:152) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:146) at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:136) at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:275) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:146) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:187) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:423) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:331) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:295) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:97) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68) at jenkins.util.ErrorLoggingExecutorService.lambda$wrap$0(ErrorLoggingExecutorService.java:51) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Finished: FAILURE

「chan_shutdown_read: channel 1: shutdown() failed for fd 7 [i0 o0]: Not a socket」と怒られる

chan_shutdown_read: channel 1: shutdown() failed for fd 7 [i0 o0]: Not a socket

ubustsuのlinuxサーバ(VPS)からgithubにつなげようとしたら上記メッセージが出てうまくいかなかった。

※2024/3/15手順追記

環境

サーバ

  • Ubuntu 22.04.4 LTS \n \l
  • OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

操作端末

  • Windows11

原因

おそらくこちらにあるWindows側でのssh-agentが悪さしているよう。

事象的にはWindows側のssh-agentがForwardAgent yes設定にてカギをもってサーバに入っているけどそいつが見れなくなって要るっぽい

きちんと直すならばこちらの対応でいけたそう

対処

Windows側のssh-agentの問題らしいのでベータに変えたら解消したっぽい。(細かい原因追っていないのでちょっと怪しい)

手順としては管理者権限のPowerShellで以下を順次実施

インストール済みOPENSSHの削除

Microsoft.OpenSSH.Betaのインストール

※2024/3/15手順追記

1週間ほどしたらvscodeターミナルからsshが通らなくなっていた。パスを確認したところ昔のC:\Windows\system32\OpenSSHを指していて、今のC:\Program Files\OpenSSHを指していない。

個人用環境変数にC:\Program Files\OpenSSHを追加した。

細かいところで、1週間ぐらいたって通らなくなったのでWindowsアップデート等で書き換わった可能性もある。C:\Windows\system32\OpenSSHはシステム全体の環境変数に入っていたので、そちらがまた書き換わる可能性を考え個人用の環境変数の方に入れてみた。(どれだけ効果あるかや本当にWindowsUpdate絡みか確認していない。またおかしくなったらこれみて思い出す)

自宅用通知マシン作成(1)

店の予約が入ったときすぐ気づきたいとか、店から自宅に呼び出しかけたりとか細々としたとこ改善したいので自宅用通知マシンを作成開始する。

第一段階としては、店に予約が入ったときにすぐ気づけるように予約が入ったら通知としてLEDを光らせる機能をつくる。

予約が入ったらじゃらんとかアソビューから通知メールが飛んでくる。数分以内に気づけたら十分なので、自宅側の通知マシンから定期的に通知メールがあるか確認する方式にする。

ちなみにメールサーバは自前(VPS)でpostfix&dovecotなのでそっちで一部処理しておく。自宅側の端末はESP8266(ESP-WROOM-02)で作成する。秋月で現在420円するので今ならESP-WROOM-32とほとんど値段変わらないのでそっち使ってもよい。(200円台の時に買ったのが数10個余っているので消費もかねて)

全体構成

  1. VPS上メールサーバのdovecotに予約メールが入ったときに、表題をみてメールを指定フォルダに振り分け。使用ツールはseive
  2. メールサーバ上にpythonで立てた未読予約メールカウント返却APIを準備。(最前面はnginx)
  3. espからAPIを定期的に呼び出し、未読の予約メールがあったらLEDを光らせて通知する。(既読にするのはPC上のメーラーで)

メールサーバサイド

seiveの設定

seiveで予約メールが届いた際に指定フォルダ(今回はINBOX.ジム.予約)に振り分け。(seiveのインストールは手順まとめていない。)

予約メールはとりあえず件名で判断。設定ファイルは以下。件名がXXだったらYYフォルダに振り分ける。

APIの準備

以前書いていた。こちら

APIのサービス化

/etc/systemd/system/mailapi.service作成

※ ~/apiをベースパスにしていたけどgit cloneの時のパスがずれたので後ほど~/yobidashi/server/apiに変更

一応メールアカウントとパスワードは外部から読み出しに(/home/yoshitake/api/mailapi.conf)

サービスに登録