Điểm:2

Lỗi khi chạy systemd với tư cách người dùng - Không thể kết nối với xe buýt: $DBUS_SESSION_BUS_ADDRESS và $XDG_RUNTIME_DIR không được xác định

lá cờ sr

Tôi có một tập lệnh đang chạy với quyền root và đang cố gắng thiết lập một dịch vụ người dùng để chạy trình nền IPFS. Vấn đề là tôi cần kích hoạt dịch vụ với tư cách là người dùng chứ không phải là người chủ. Nó thường hoạt động sau khi khởi động lại nhưng tôi muốn tránh điều đó nếu có thể.

Tập lệnh dịch vụ được đặt tại ~/.config/systemd/user/ipfs.service

Nó chứa:

[Đơn vị]
Mô tả=IPFS daemon

[Dịch vụ]
# Môi trường="IPFS_PATH=/data/ipfs" # đường dẫn tùy chọn tới thư mục init ipfs nếu không phải là mặc định (\$HOME/.ipfs)
ExecStart=/usr/local/bin/ipfs daemon
Khởi động lại = khi thất bại

[Cài đặt]
WantedBy=default.target

(Tôi lấy mã này từ đây: https://github.com/ipfs/go-ipfs/tree/master/misc )

Nếu tôi chạy các lệnh này với tư cách là người dùng thì nó hoạt động chính xác:

systemctl --user kích hoạt ipfs
systemctl --user bắt đầu ipfs

Vấn đề là tập lệnh của tôi đang chạy với quyền root và tôi không thể tìm ra cách để tập lệnh này chạy với tư cách người dùng. Tôi đã thử điều này cho đến nay:

    # Cho phép kéo dài để IPFS có thể chạy khi khởi động
    trình kéo dài kích hoạt loginctl $USER_ACCOUNT

    # Cho phép dịch vụ chạy khi khởi động
    sudo -u $USER_ACCOUNT systemctl --user kích hoạt ipfs

    # Bắt đầu dịch vụ ngay bây giờ
    sudo -u $USER_ACCOUNT systemctl --user bắt đầu ipfs

Rất tiếc, dịch vụ này không khởi động và khi tôi nhận được thông báo lỗi này:

Không thể kết nối với xe buýt: $DBUS_SESSION_BUS_ADDRESS và $XDG_RUNTIME_DIR không được xác định (cân nhắc sử dụng [email protected] --user để kết nối với xe buýt của người dùng khác)

Khi tập lệnh kết thúc và tôi khởi động lại, dịch vụ sẽ bắt đầu tốt nhưng tôi muốn tránh người dùng phải khởi động lại nếu có thể. Bất kỳ trợ giúp sẽ được đánh giá cao.

Nate T avatar
lá cờ it
Có vấn đề nơi kịch bản chạy? Nếu câu trả lời là không, hãy thử chạy từ một TTY khác. Đôi khi, điều này sẽ hoạt động khi có vẻ như nó không nên. SystemD nên có sẵn từ bất cứ đâu. Nó là một shell đăng nhập, vì vậy env. yêu cầu sẽ khác nhau. Thành thật mà nói, tôi không biết liệu nó có hoạt động hay không, nhưng tôi tò mò.
lá cờ cn
Trong https://github.com/eriksjolund/user-systemd-service-actions-workflow/blob/main/.github/workflows/demo.yml#L18, tôi phải thêm `sleep 1` và ` `XDG_RUNTIME_DIR=/ chạy/người dùng/$UID`. Nếu bạn đang chạy bằng quyền root, bạn cũng có thể thử `systemd-run --quiet --machine= $USER_ACCOUNT@ --user --collect --pipe --wait systemctl --user enable ipfs`
Điểm:0
lá cờ us

Các biến này là người dùng cụ thể. Chúng được đặt bởi phiên bản người dùng của systemd khi người dùng đăng nhập. Nếu tập lệnh của bạn chạy dưới dạng dịch vụ hệ thống thì tất nhiên tập lệnh đó không có quyền truy cập vào biến này cho một người dùng cụ thể.

Nếu bạn dùng systemctl --user --global kích hoạt sau đó dịch vụ sẽ được kích hoạt cho tất cả người dùng.

Nate T avatar
lá cờ it
systemd không chỉ là một tệp nhị phân trong thư mục bin. Đó là một hệ thống chữ nghĩa. Không có trường hợp người dùng cụ thể.
lá cờ us
Có hai quy trình systemd. Cái đầu tiên được chạy dưới dạng /sbin/init và bắt đầu các dịch vụ toàn cầu. Cái thứ hai được khởi chạy khi người dùng đăng nhập và bắt đầu dịch vụ người dùng. Hai biến được đề cập ở đây được thiết lập bởi quy trình thứ hai.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.