I have installed Apache Drill and want to start it when the machine boots up. To do this, I have created the following systemd unit in /etc/systemd/system/drill.service
[Unit]
Description=Start/Stop Apache Drill
After=syslog.target network.target
[Service]
Type=forking
User=me
Group=me
ExecStartPre==-/usr/bin/zk_up
ExecStart=/opt/apache/drill/current/bin/drillbit.sh --config /opt/apache/drill/current/conf start
ExecStop=/opt/apache/drill/current/bin/drillbit.sh stop
[Install]
WantedBy=multi-user.target
The issue is that when I issue the command systemctl start drill, the service does not start completely. It seems to hang and then times out. While the process is hung, running the command systemctl status -l drill.service shows the status as activating. This is the output of the command systemctl status -l drill.service
drill.service - Start/Stop Apache Drill
Loaded: loaded (/etc/systemd/system/drill.service; disabled; vendor preset: disabled)
Active: activating (start) since Fri 2019-10-25 07:32:24 UTC; 55s ago
Process: 10257 ExecStartPre=/usr/bin/zk_up (code=exited, status=0/SUCCESS)
Control: 10262 (drillbit.sh)
CGroup: /system.slice/drill.service
├─10262 /bin/bash /opt/apache/drill/current/bin/drillbit.sh --config /opt/apache/drill/current/conf start
├─10273 /bin/bash /opt/apache/drill/current/bin/drillbit.sh --config /opt/apache/drill/current/conf start
├─10274 find -L / -name java -type f
└─10275 head -n 1
After the process fails, I see the following message displayed
Job for drill.service failed because a timeout was exceeded. See "systemctl status drill.service" and "journalctl -xe" for details.
The command systemctl status -l drill.service after the timeout returns the following
drill.service - Start/Stop Apache Drill
Loaded: loaded (/etc/systemd/system/drill.service; disabled; vendor preset: disabled)
Active: failed (Result: timeout) since Fri 2019-10-25 07:33:54 UTC; 3min 3s ago
Process: 10262 ExecStart=/opt/apache/drill/current/bin/drillbit.sh --config /opt/apache/drill/current/conf start (code=killed, signal=TERM)
Process: 10257 ExecStartPre=/usr/bin/zk_up (code=exited, status=0/SUCCESS)
And when I run journalctl -xe, I see the following messages
Oct 25 07:39:17 drill-1 drillbit.sh[10774]: find: File system loop detected; ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sda’ is part of the same file system loop as ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda’.
Oct 25 07:39:17 drill-1 drillbit.sh[10774]: find: File system loop detected; ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem/2:0/subsystem’ is part of the same file system loop as ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem’.
Oct 25 07:39:17 drill-1 drillbit.sh[10774]: find: File system loop detected; ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem/8:0/subsystem’ is part of the same file system loop as ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem’.
Oct 25 07:39:17 drill-1 drillbit.sh[10774]: find: File system loop detected; ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem/0:38/subsystem’ is part of the same file system loop as ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem’.
Oct 25 07:39:17 drill-1 drillbit.sh[10774]: find: File system loop detected; ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi/subsystem/8:16’ is part of the same file system loop as ‘/sys/bus/cpu/devices/cpu0/node0/cpu1/driver/cpu2/firmware_node/subsystem/devices/PNP0303:00/physical_node/subsystem/devices/00:03/tty/ttyS0/subsystem/ttyS2/device/subsystem/devices/VMBUS:01/firmware_node/2dd1ce17-079e-403c-b352-a1921ee207ee/driver/b6650ff7-33bc-4840-8048-e0676786f393/subsystem/devices/00000000-0001-8899-0000-000000000000/host3/scsi_host/host3/subsystem/host2/device/target2:0:0/subsystem/devices/3:0:1:0/scsi_device/3:0:1:0/subsystem/2:0:0:0/device/block/sda/sda2/subsystem/sdb/bdi’.
Can anyone tell me why am I seeing these messages and what do I need to do to get it working?
If I run the command defined for the ExecStart parameter on my terminal itself, Apache Drill start without throwing any errors. The command /usr/bin/zk_up just checks if the zookeepers are running before I start Drill and as shown above, this command exits successfully.
When I closely looked at the output of the systemctl status -l drill.service command, I saw that the culprit that was printing the file system loop messages was the find command and that command was looking for java. I added the JAVA_HOME to the environment in the systemd file and it worked. My new systemd unit is
[Unit]
Description=Start/Stop Apache Drill
After=syslog.target network.target
[Service]
Type=forking
User=me
Group=me
Environment="JAVA_HOME=/opt/java/current"
ExecStartPre==-/usr/bin/zk_up
ExecStart=/opt/apache/drill/current/bin/drillbit.sh --config /opt/apache/drill/current/conf start
ExecStop=/opt/apache/drill/current/bin/drillbit.sh stop
[Install]
WantedBy=multi-user.target
where /opt/java/current is where my $JAVA_HOME is.
Related
Script location: /usr/bin/Startup_tc_and_agents.sh
Script content (all 3 command are on the first line in the script):
sh /home/tb/Desktop/Installed/TeamCity/bin/runAll.sh start; sh /home/tb/Desktop/Installed/TeamCity/buildAgent_2/bin/agent.sh start; sh /home/tb/Desktop/Installed/TeamCity/buildAgent_3/bin/agent.sh start;
if I run this script manually in the terminal - everthing works as expected. But if I execute it from a .service it fails?
Service location: /etc/systemd/system/TeamCity_and_agents_startup.service
Service content:
[Unit]
Description=Service that startup TeamCity and its 3 agents
After=network.target
[Service]
Type=simple
User=root
ExecStart=/usr/bin/Startup_tc_and_agents.sh
[Install]
WantedBy=multi-user.target
I have also granted permissions like:
sudo chmod -R a+rwx /usr/bin/Startup_tc_and_agents.sh
sudo chmod -R a+rwx /etc/systemd/system/TeamCity_and_agents_startup.service
I have also run these commands:
systemctl daemon-reload
systemctl enable TeamCity_and_agents_startup.service
I have also tried to add #!/bin/sh as the first line and just above the line 'ExecStart' - but it doesn't change anything.
When I run the service with: systemctl start TeamCity_and_agents_startup.service I get the error below:
TeamCity_and_agents_startup.service - Service that startup TeamCity and its 3 agents
Loaded: loaded (/etc/systemd/system/TeamCity_and_agents_startup.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2020-02-10 16:17:24 +04; 13s ago
Process: 56412 ExecStart=/usr/bin/Startup_tc_and_agents.sh (code=exited, status=203/EXEC)
Main PID: 56412 (code=exited, status=203/EXEC)
Feb 10 16:17:24 Monster systemd[1]: Started Service that startup TeamCity and its 3 agents.
Feb 10 16:17:24 Monster systemd[56412]: TeamCity_and_agents_startup.service: Failed to execute command: Exec format error
Feb 10 16:17:24 Monster systemd[56412]: TeamCity_and_agents_startup.service: Failed at step EXEC spawning /usr/bin/Startup_tc_and_agents.sh: Exec format error
Feb 10 16:17:24 Monster systemd[1]: TeamCity_and_agents_startup.service: Main process exited, code=exited, status=203/EXEC
Feb 10 16:17:24 Monster systemd[1]: TeamCity_and_agents_startup.service: Failed with result 'exit-code'.
I changed this line:
ExecStart=/usr/bin/Startup_tc_and_agents.sh
to this:
ExecStart=/bin/sh /usr/bin/Startup_tc_and_agents.sh
PS: #!/bin/sh was not necessary to include in the script in my case.
I am trying to configure my coral board to boot to the Coco object detection model using a custom systemd service. I've created the executable file, unit file and then enabled the service. The intent is for the camera feed to display to a monitor, but when I power on the board, the monitor only displays a bluish background (I assume the "home screen" of the board).
The executable file:
edgetpu_detect \
--model mobilenet_ssd...
--labels coco...
The unit file:
[Unit]
Description=systemd service.
After=weston.target
[Service]
PAMName=login
Type=simple
User=mendel
WorkingDirectory=/home/mendel
ExecStart=/bin/bash /usr/bin/test_service.sh
Restart=always
[Install]
WantedBy=multi-user.targer
Status of service after enabling and after powering on:
mendel#jumbo-tang:/etc/system$ sudo systemctl status myservice.service
myservice.service - systemd service.
Loaded: loaded (/etc/systemd/system/system/myservice.service; enabled; vendor preset
Active: active (running) since Mon 2020-01-06 03:32:03 UTC; 1s ago
Main PID: 4847 (bash)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/myservice.service
4847 /bin/bash /usr/bin/test_service.sh
Jan 06 03:32:03 jumbo-tang systemd[1]: myservice.service: Service hold-off time
Jan 06 03:32:03 jumbo-tang systemd[1]: Stopped Example systemd service..
Jan 06 03:32:03 jumbo-tang systemd[1]: Started Example systemd service..
Jan 06 03:32:03 jumbo-tang systemd[4847]: pam_unix(login:session): session opene
The executable is saved to /usr/bin, and was made executable with sudo chmod +x /usr/bin/test_service.sh
The unit file was saved to /etc/systemd/system, and was given permissions with sudo chmod 644 /etc/systemd/system/myservice.service
I'm curious to know if my executable cannot simply contain the code I'd normally use to launch a model, like I've done, or if my unit file is properly configured, or what else could be wrong I'm not thinking of.
Any help is appreciated!
I believe I've answered you via coral-support, we discussed that you're most likely just missing a couple things:
1) When starting a systemd service especially at boot, sometimes not all environment variable are loaded, in this case, you may need to add the line:
Environment=DISPLAY=:0
before ExecStart. However, I don't suspect that is is the issue, because the process does waits on weston.target, which should already waits on environment variables.
2) This one is a lot more complicated than the previous one but you misspelled
"target" in "WantedBy=multi-user.targer" (joking, of course)
I'm showing the steps here again as an example for future references.
1) create a file call detects.service with the following contents:
[Unit]
Description=systemd auto face detection service
After=weston.target
[Service]
PAMName=login
Type=simple
User=mendel
WorkingDirectory=/home/mendel
Environment=DISPLAY=:0
ExecStart=/bin/bash /usr/bin/detect_service.sh
Restart=always
[Install]
WantedBy=multi-user.target
2) mv the file /lib/systemd/system/detects.service
$ sudo mv detects.service /lib/systemd/system/detects.service
3) create a file call detect_service.sh with the following content
edgetpu_detect --model fullpath/mobilenet_ssd_v2_coco_quant_postprocess_edgetpu.tflite --label fullpath/coco_labels.txt
4) make it executable and mv it to /usr/bin
$ sudo chmod u+x detect_service.sh
$ sudo mv detect_service.sh /usr/bin
5) enable the service with systemctl
$ sudo systemctl enable detects.service
Boring details alert:
I have a systemd service file which uses a bash file to start the service. Below is the service file in question:
[Unit]
Description=A program service
[Service]
User=root
#change this to your workspace
WorkingDirectory=/data/acloud/repository/lib
#path to executable.
#executable is a bash script file I created to run the application jar file
ExecStart=/data/acloud/repository/lib/program.sh
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Below is program.sh I used in the service file above:
#!/bin/bash
sudo java -XX:+UseG1GC -Xmx1g -Xms512m -jar abc-program-0.0.1-SNAPSHOT.jar
If you are wondering why I created a single line bash script, its because I do not know where and how to put the -XX, -Xms -Xmx parameters in .service file.
Even when the service is inactive, Main PID status is shown as status=0/SUCCESS and at the end of the systemctl status command output, it says Started a program service?? Below is how its shown:
ubuntu#ip-172-**-**-***:/data/acloud/repository/lib$ sudo systemctl status program
program.service - A program service
Loaded: loaded (/etc/systemd/system/program.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2019-02-22 13:08:21 UTC; 45s ago
Process: 27711 ExecStart=/data/acloud/repository/lib/program.sh (code=exited, status=0/SUCCESS)
Main PID: 27711 (code=exited, status=0/SUCCESS)
Feb 22 13:08:21 ip-172-**-**-*** systemd[1]: Started A program service.
I believe that using bash is causing this problem as the exit codes are not manipulated in here. How do I get this to stop?
OS level: CentOS Linux release 7.4.1708
Prometheus level: 2.4.2
prometheus.service:
[Unit]
Description=Prometheus
[Service]
User=prometheus
ExecStart=/usr/local/prometheus/prometheus
[Install]
WantedBy=default.target
When I use systemctl start prometheus to start the prometheus service, it always exit the main process by itself. And the systemctl's log shows like this:
● prometheus.service - Prometheus
Loaded: loaded (/etc/systemd/system/prometheus.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2018-09-25 10:43:56 CST; 6s ago
Process: 5174 ExecStart=/usr/local/prometheus/prometheus (code=exited, status=1/FAILURE)
Main PID: 5174 (code=exited, status=1/FAILURE)
Sep 25 10:43:56 devtestserver systemd[1]: Started Prometheus.
Sep 25 10:43:56 devtestserver systemd[1]: Starting Prometheus...
Sep 25 10:43:56 devtestserver prometheus[5174]: level=info ts=2018-09-25T02:43:56.736457704Z caller=main.go:238 msg="Starting Prometheus" version="(version=2.4.2, branch=HE...13b1190a0)"
Sep 25 10:43:56 devtestserver systemd[1]: prometheus.service: main process exited, code=exited, status=1/FAILURE
Sep 25 10:43:56 devtestserver systemd[1]: Unit prometheus.service entered failed state.
Sep 25 10:43:56 devtestserver systemd[1]: prometheus.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
I have no ideas with this problem. I use the same config for the node_exporter, but node_exporter can start as normal. Please help. Thanks a lot.
You have not added configuration file i.e. prometheus.yml
Considering Service part of your prometheus.service file,
ExecStart=/usr/local/prometheus/prometheus \
--config.file /prometheus-2.26.0.linux-amd64/prometheus.yml
here, my .yml file is in /prometheus-2.26.0.linux-amd64/ location.
your might be different. Befre running check your both paths i.e. your executable file is on the path given in "ExecStart" and yml file is in --config.file
then reload your system by
systemctl daemon-reload
systemctl start prometheus
systemctl enable prometheus
then check the status using,
systemctl status prometheus
It should be active(running).
This should solve your problem. Let me know if it helped : )
There is an extra "i" at the end of WantedBy=default.target.
To get more details about services failing to start, try sudo journalctl -ex
My guess is it's either the extra "i" or Prometheus might not be able to parse your scrape rules or alerts files. It comes with "promtool" to check your configuration files and is installed in the same directory as prometheus. Your first step should be to try "promtool check config /path/to/prometheus.yml"
I encountered the same issue with Ubuntu 16.04. Turned out to be a permissions issue.
You should check that you user owns the directories in which you installed the binaries and the files inside these directories.
Where is the config file located? systemd is executed by / by default. prometheus reads the setting of ./prometheus.yml by default. Perhaps you need to add the following config option to the unit file of systemd.
[Unit]
Description=Prometheus
[Service]
User=prometheus
ExecStart=/usr/local/prometheus/prometheus --config.file /path/to/your/config
[Install]
WantedBy=default.target
This problem is caused because the data storage directory does not have permission. The default Prometheus data directory is /data.
chown -R prometheus:prometheus /data
copy and paste this in your command line:
sudo tee /etc/systemd/system/prometheus.service<<EOF
[Unit]
Description=Prometheus
Documentation=https://prometheus.io/docs/introduction/overview/
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=prometheus
Group=prometheus
ExecReload=/bin/kill -HUP \$MAINPID
ExecStart=/usr/local/bin/prometheus \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/var/lib/prometheus \
--web.console.templates=/etc/prometheus/consoles \
--web.console.libraries=/etc/prometheus/console_libraries \
--web.listen-address=0.0.0.0:9090 \
--web.external-url=
SyslogIdentifier=prometheus
Restart=always
[Install]
WantedBy=multi-user.target
EOF
I encountered similar issue in redhat/Centos.I solved it by temporarily running "sudo setenforce 0". You can also edit the /etc/selinux/config file and set the SELINUX to disabled
I'm writing a bash-script but I often face this issue.
When I try to start or stop a service I often get:
start request repeated too quickly
How can I solve this problem?
It's for example when I try to restart docker or openshift-origin master.
sudo service origin-master restart
● origin-master.service - Origin Master Service
Loaded: loaded (/usr/lib/systemd/system/origin-master.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Wed 2016-02-17 08:22:11 UTC; 44s ago
Docs: https://github.com/openshift/origin
Process: 2296 ExecStart=/usr/bin/openshift start master --config=${CONFIG_FILE} $OPTIONS (code=exited, status=255)
Main PID: 2296 (code=exited, status=255)
Feb 17 08:22:10 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: origin-master.service: main process exited, code=exited, status=255/n/a
Feb 17 08:22:10 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: Failed to start Origin Master Service.
Feb 17 08:22:10 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: Unit origin-master.service entered failed state.
Feb 17 08:22:10 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: origin-master.service failed.
Feb 17 08:22:11 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: origin-master.service holdoff time over, scheduling restart.
Feb 17 08:22:11 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: start request repeated too quickly for origin-master.service
Feb 17 08:22:11 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: Failed to start Origin Master Service.
Feb 17 08:22:11 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: Unit origin-master.service entered failed state.
Feb 17 08:22:11 ip-172-xx-xx-xx.eu-central-1.compute.internal systemd[1]: origin-master.service failed.
My script is just doing:
if [ $1 = "-u" ]
then
sudo service origin-master restart
fi
A manual restart is possible before I've executed the script. But after it it remains giving the error
This is a "feature" of systemctl. There is a parameter in the file that limits the restart frequency in seconds. Lower this while testing.
Edit the file
/etc/systemd/system/multi-user.target.wants/<your service here>
my example:
Restart=on-failure
StartLimitBurst=2
# Restart, but not more than once every 10 minutes
#StartLimitInterval=600
# Restart, but not more than once every 30s (for testing purposes)
StartLimitInterval=30
I suggest you familiarize yourself with systemd. That's what you're using under the hood when you run service. As #chepner says, the service is failing (as you can see from the second line of the log), and it's being restarted too quickly, triggering the error.
Try running journalctl -u origin-master.service to figure out why the error is happening.
Also, systemd cat origin-master.service will show you the Service Unit file that describes your service - there might be errors.
I had this problem on Ubuntu 20.4. And by adding execute permission to the ExecStart file the problem was solved.
sudo chmod +x /path/to/execfile
I have faced same issue and solved this problem like that:
if /var/log/mysql folder not exists:
sudo mkdir /var/log/mysql
and then give permission this folder:
sudo chown -R mysql:mysql /var/log/mysql
sudo systemctl stop mysql
sudo systemctl start mysql
in my case, there was a typing mistake in this file -> /etc/systemd/system/multi-user.target.wants/<your service here> so after tweaking necessary parameters, if you are still facing the same error, don't forget to check the file
In my case , is my /etc/docker/daemon.json file format error, when i make this true, run systemctl start docker the server start success.
Please try running the command :
td-agent --dry-run
This will give you the root cause.