Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

fundchannel reports 'Owning subdaemon openingd died (62208)' on peer disconnect after WIRE_OPEN_CHANNEL

Đang mở
  • Có gì không ổn?
#9,108 8 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
c
Lĩnh vực
api, backend, networking

Hướng nghiên cứu

Theo dõi fundchannel_start qua openingd sau WIRE_OPEN_CHANNEL, tập trung vào status_peer_connection_lost và việc xử lý wait-status của tiến trình cha. Tái hiện việc peer ngắt kết nối bằng lệnh lightning-cli và các log được cung cấp; hoàn tất khi RPC báo cáo thông báo mất kết nối với peer thay vì wait-status dạng số của subdaemon, đồng thời giữ nguyên hành vi ERROR từ xa hiện có.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Issue and Steps to Reproduce

When attempting to open a channel to a peer, fundchannel fails with the low-level error:

{
   "code": -1,
   "message": "Owning subdaemon openingd died (62208)",
   "data": {
      "id": "0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e",
      "method": "fundchannel_start"
   }
}

Command used:

lightning-cli --lightning-dir=/home/vp/.lightning-experimental/lightning -k \
  fundchannel \
  id=0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e@164.92.106.32:9735 \
  amount=all \
  announce=true

The relevant logs show that the connection succeeds, openingd sends WIRE_OPEN_CHANNEL, and then the peer connection is lost while waiting for accept_channel:

2026-05-04 23:06:40.354373 plugin-spenderp mfc 8, dest 0: connect 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e.
2026-05-04 23:06:40.830696 connectd Connected out, starting crypto
2026-05-04 23:06:41.248657 connectd peer_out WIRE_INIT
2026-05-04 23:06:41.318478 connectd peer_in WIRE_INIT
2026-05-04 23:06:41.319001 plugin-spenderp mfc 8, dest 0: connect done.
2026-05-04 23:06:41.371062 plugin-spenderp mfc 8, dest 0: fundchannel_start 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e.
2026-05-04 23:06:41.402490 openingd-chan#55 pid 921769, msgfd 95
2026-05-04 23:06:41.403137 openingd-chan#55 funder_channel_start
2026-05-04 23:06:41.403180 openingd-chan#55 Setting their reserve to 128171sat
2026-05-04 23:06:41.403217 openingd-chan#55 peer_out WIRE_OPEN_CHANNEL
2026-05-04 23:06:41.403254 openingd-chan#55 billboard: Funding channel start: offered, now waiting for accept_channel
2026-05-04 23:06:41.986147 openingd-chan#55 Peer connection lost
2026-05-04 23:06:41.986161 chan#55 Owning subdaemon openingd died (62208)
2026-05-04 23:06:41.986173 lightningd peer_disconnected
2026-05-04 23:06:42.026250 plugin-spenderp mfc 8, dest 0: failed! fundchannel_start 0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e: {"code":-1,"message":"Owning subdaemon openingd died (62208)"}.

There is no peer_in WIRE_ERROR in this attempt. So this seems to be a remote disconnect after our open_channel, but the RPC error returned to the user is the internal wait status / subdaemon death:

Owning subdaemon openingd died (62208)

This is confusing because it looks like openingd crashed, while the logs indicate the controlled exit path for peer connection loss.

A previous attempt with announce=false against another peer gave a clean remote error:

They sent ERROR channel ...: private channels are not accepted

So the issue here is not that every peer policy rejection is opaque; this specific case is a disconnect/EOF surfaced as a subdaemon death.

Expected behavior: fundchannel should surface something like:

Peer connection lost while waiting for accept_channel

or:

Peer disconnected during fundchannel_start after WIRE_OPEN_CHANNEL

rather than:

Owning subdaemon openingd died (62208)

I think 62208 is the parent-visible wait status for an exit status of 243 (0xf3), i.e. the status_peer_connection_lost path, but this leaks an implementation detail to the RPC user.

getinfo output

I am running an experimental build. From the current tree:

git describe: v26.04.1-50-ga7f9aae9f
commit: a7f9aae9f
branch: claude/epic-black

lightningd --version from this checkout prints:

v25.09

I can provide the full exported logs if useful.

Ngôn ngữ chính
C
Star
3.1k
Fork
1k
Merge trung bình
4 ngày 2 giờ
Pull request đã merge (30 ngày)
45

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ElementsProject/lightning

Tất cả issue của ElementsProject/lightning

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.