Apache DolphinScheduler is a distributed, decentralized big data workflow scheduling system that supports big data task scheduling. To set DolphinScheduler to start automatically upon system boot, you typically need to configure it as a system service. The following are general steps, which may vary depending on your operating system:
dolphinscheduler.service
, usually placed in the /etc/systemd/system/
directory.
[Unit]
Description=DolphinScheduler Service
After=network.target
[Service]
type=exec
ExecStart=/opt/module/dolphinscheduler/bin/start-all.sh
ExecStop=/opt/module/dolphinscheduler/bin/stop-all.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
2. Start the service, and set it to start on boot:
systemctl
command to start the service, and enable it to start on boot:
systemctl daemon-reload
systemctl start dolphinscheduler.service
systemctl enable dolphinscheduler.service
3. Verify the service status:
systemctl status dolphinscheduler.service
Create a batch file (e.g., start-dolphinscheduler.bat
) to start DolphinScheduler.
Add the command to start DolphinScheduler in the batch file.
2. Add the batch file to the Startup folder:
shell:startup
to open the Startup folder.
3. Restart Verification:
Please note that the above steps may need to be adjusted based on your specific environment and the DolphinScheduler version. Ensure you have sufficient permissions and a good understanding of system services to avoid potential service conflicts or system instability.
If the DolphinScheduler service briefly shows as green (indicating the service is running) after restarting and then changes to a non-green state (typically indicating the service is no longer running), but the related processes are still running, this may be because the service manager (systemd
) thinks the service has stopped because it does not detect a continuously running main process.
This situation usually occurs in the following cases:
Service Script Issues: If the service script (start-all.sh
) completes without keeping any process running in the background, systemd will think the service has stopped.
Incorrect Service Type Configuration: In the systemd
service file, the Type
configuration may need to be corrected. If the service is set to simple, it should be forking
or oneshot
, systemd
might think the service has stopped as soon as the script finishes executing.
Process Exit Code Issues: If the service script correctly starts all necessary processes but exits quickly (e.g., because the commands in the script finish soon), systemd
might determine the service status based on the script's exit code.
To resolve this issue, you can try the following steps:
start-all.sh
script keeps running after starting all necessary processes. If the script does not keep any process running in the background after execution, you might need to add some logic to keep it running.
Type=forking
: If your service script is a forking script, ensure you use Type=forking
in the systemd
service file. This way, systemd
will wait for the child process created by the script.
Type=notify
(if supported): If DolphinScheduler supports communication with the service manager, you can use Type=notify
. This way, the service can send status notifications to systemd
via the sd_notify()
function.
RemainAfterExit=yes
: If the processes started by the service script run independently of the script itself, you can use RemainAfterExit=yes
in the systemd
service file. This way, even if the script exits, systemd
will consider the service to be still running.systemd
and restart the service:systemctl daemon-reload
systemctl restart dolphinscheduler.service
systemd
believes the service has stopped.
Finally, the configuration works well.