vấn đề khởi động dịch vụ systemd

Question

Đây là lần đầu tiên tôi sử dụng systemd và một chút không chắc chắn về điều gì đó.

Tôi đã có một dịch vụ mà tôi đã thiết lập (đối với geoserver chạy dưới tomcat):

[Unit] 
Description=Geoserver 
After=network.target 

[Service] 
Type=oneshot 
ExecStart=/usr/local/geoserver/bin/startup-optis.sh 
ExecStop=/usr/local/geoserver/bin/shutdown-optis.sh 
User=geoserver 

[Install] 
WantedBy=multi-user.target 

Các khởi động kịch bản thực hiện một exec để chạy java/tomcat. Bắt đầu dịch vụ từ dòng lệnh xuất hiện để hoạt động:

sudo systemctl start geoserver 

Tuy nhiên lệnh này không trả lại cho đến khi tôi ctrl-c, điều này có vẻ không đúng với tôi. Quá trình java vẫn chạy sau đó mặc dù và hoạt động bình thường. Tôi không muốn khởi động lại hộp để kiểm tra điều này trong trường hợp điều này sẽ gây ra vấn đề trong init và nó là một máy từ xa và nó sẽ là một nỗi đau để có được một ai đó để giải quyết nó.

Answer 1

Bạn cần phải thiết lập đúng "Loại" trong phần "Dịch vụ":

[Service] 
... 
Type=simple 
... 

Loại

Cấu hình quá trình khởi động kiểu cho đơn vị dịch vụ này. Một trong những đơn giản, forking, oneshot, dbus, thông báo hoặc nhàn rỗi.

Nếu được đặt thành đơn giản (mặc định nếu không phải là Type = hay BusName =, nhưng ExecStart = được chỉ định), thì quá trình được cấu hình với ExecStart = là quy trình chính của dịch vụ. Trong chế độ này, nếu quy trình cung cấp chức năng cho các quy trình khác trên hệ thống, các kênh truyền thông của nó sẽ được cài đặt trước khi daemon được khởi động (ví dụ: ổ cắm được thiết lập bởi systemd, thông qua kích hoạt ổ cắm), như systemd bắt đầu theo dõi các đơn vị.

Nếu được đặt thành forking, dự kiến ​​quá trình được định cấu hình với ExecStart = sẽ gọi fork() là một phần khởi động của nó. Quá trình của phụ huynh dự kiến ​​sẽ thoát khi khởi động xong và tất cả các kênh truyền thông đều được thiết lập. Đứa trẻ tiếp tục chạy như một quá trình daemon chính . Đây là hành vi của các daemon UNIX truyền thống. Nếu cài đặt này được sử dụng, bạn cũng nên sử dụng tùy chọn PIDFile = , để systemd có thể xác định quy trình chính của daemon. systemd sẽ tiến hành bắt đầu các đơn vị tiếp theo ngay sau khi thoát khỏi quá trình cha mẹ .

Hành vi của oneshot tương tự như đơn giản; tuy nhiên, dự kiến ​​ quy trình phải thoát trước khi systemd khởi động các đơn vị tiếp theo. RemainAfterExit = đặc biệt hữu ích cho loại dịch vụ này. Điều này là mặc định ngụ ý nếu không phải là Type = hoặc ExecStart = được chỉ định.

Hành vi của dbus tương tự như đơn giản; tuy nhiên, dự kiến ​​rằng daemon sẽ lấy tên trên xe buýt D-Bus, như được định cấu hình bởi BusName =. systemd sẽ tiến hành bắt đầu các đơn vị tiếp theo sau khi mua tên xe buýt D-Bus . Các đơn vị dịch vụ với tùy chọn này được định cấu hình hoàn toàn phụ thuộc vào đơn vị dbus.socket. Loại này là mặc định nếu BusName = được chỉ định.

Hành vi của thông báo tương tự như đơn giản; tuy nhiên, dự kiến ​​rằng daemon sẽ gửi thông báo qua sd_notify (3) hoặc một cuộc gọi tương đương khi nó kết thúc khởi động. systemd sẽ tiến hành với các đơn vị bắt đầu theo dõi sau khi thông báo này đã được gửi . Nếu tùy chọn này được sử dụng, NotifyAccess = (xem bên dưới) nên được đặt để mở quyền truy cập vào ổ cắm thông báo do systemd cung cấp. Nếu NotifyAccess = không được đặt, nó sẽ được đặt ngầm thành chính. Lưu ý rằng hiện tại Loại = thông báo sẽ không hoạt động nếu được sử dụng kết hợp với PrivateNetwork = yes.

Hành vi của nhàn rỗi rất giống với đơn giản; tuy nhiên, việc thực thi thực tế của nhị phân dịch vụ bị trì hoãn cho đến khi tất cả công việc được gửi đi. có thể được sử dụng để tránh xen kẽ đầu ra của dịch vụ vỏ với đầu ra trạng thái trên bảng điều khiển.