本文介绍了systemd服务启动问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是我第一次使用systemd,有点不确定。

This is the first time I've used systemd and a bit unsure about something.

我有一个服务,我已经设置(对geoserver运行在tomcat下):

I've got a service that I've set up (for geoserver running under 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

启动脚本执行一个exec来运行java / tomcat。从命令行启动服务似乎起作用:

The start up script does an exec to run java/tomcat. Starting up the service from the commandline appears to work:

 sudo systemctl start geoserver

但是命令不会返回,直到我ctrl-c,这似乎不对我。 java进程保持运行后,正常运行。我不愿意重新启动框,以测试这种情况下,这将导致问题,在init期间,它是一个远程机器,这将是一个痛苦,让某人解决它。

However the command does not return until I ctrl-c, this doesn't seem right to me. The java process remains running afterwards though and functions normally. I'm reluctant to reboot the box to test this in case this is going to cause problems during init and it's a remote machine and it would be a pain to get someone to address it.

推荐答案

您需要在服务部分设置正确的类型:

You need to set correct "Type" in "Service" section:

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



配置此服务单元的进程启动类型。

Configures the process start-up type for this service unit. One of simple, forking, oneshot, dbus, notify or idle.

如果设置为simple(默认值,如果既不是Type =也不是BusName =,而是
)ExecStart =被指定),预期配置
和ExecStart =的进程是服务的主进程。在这种模式下,如果
进程为系统上的其他进程提供了功能,那么
通讯通道应在守护进程
启动之前安装(例如由systemd通过socket设置的socket激活),因为
systemd将立即继续启动跟踪单元。

If set to simple (the default if neither Type= nor BusName=, but ExecStart= are specified), it is expected that the process configured with ExecStart= is the main process of the service. In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units.

如果设置为forking,则期望配置的进程
ExecStart =将调用fork()作为其启动的一部分。当启动完成并且所有
通信信道被设置时,父进程
进程预期会退出。该子进程继续作为
主守护进程运行。这是传统UNIX守护进程的行为。
如果使用此设置,建议也使用PIDFile =
选项,以便systemd可以识别守护程序的主进程。
systemd将在
父进程退出后立即启动后续单元。

If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.

oneshot的行为类似于简单;然而,预计
该进程必须在systemd启动跟进单元之前退出。
RemainAfterExit =对于此类服务特别有用。如果既没有指定Type =也没有指定ExecStart =,则
是默认的默认值。

Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units. RemainAfterExit= is particularly useful for this type of service. This is the implied default if neither Type= or ExecStart= are specified.

dbus的行为类似于simple;然而,期望
守护程序在D-Bus总线上获取一个名称,由
BusName =配置。在获得
D-Bus总线名称后,systemd将继续启动跟踪单元。具有此选项
配置的服务单元隐含地获得对dbus.socket单元的依赖性。如果指定BusName =,这个
类型是默认的。

Behavior of dbus is similar to simple; however, it is expected that the daemon acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified.

notify的行为类似于simple;然而,预期
守护程序在完成启动后通过sd_notify(3)或
等效调用发送通知消息。在此通知消息
发送后,systemd将执行
启动跟进单元。如果使用此选项,NotifyAccess =(见下文)应设置
以打开对systemd提供的通知套接字的访问。如果
NotifyAccess =未设置,它将被隐式设置为main。注意,
当前类型= notify如果与
组合使用将不起作用PrivateNetwork = yes。

Behavior of notify is similar to simple; however, it is expected that the daemon sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main. Note that currently Type=notify will not work if used in combination with PrivateNetwork=yes.

空闲行为非常类似于简单;然而,服务二进制的实际执行
被延迟,直到所有作业被分派。这个
可以用于避免shell服务的输出与控制台上的
状态输出交错。

Behavior of idle is very similar to simple; however, actual execution of the service binary is delayed until all jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console.

这篇关于systemd服务启动问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-18 14:33
查看更多