Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I created a service in my Ubuntu instance by adding it to systemd like:
sudo systemctl enable myservice.service
Created symlink /etc/systemd/system/multi-user.target.wants/myservice.service → /etc/systemd/system/myservice.service.
the setting inside my myservice.service are:
[Unit]
Description=myserviceService
[Service]
Restart=always
Type=simple
ExecStart=/home/myservice-app/core/core
[Install]
WantedBy=multi-user.target
This is the error when I check status:
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: myservice.service: Main process exited, code=exited, status=1/FAILURE
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: myservice.service: Failed with result 'exit-code'.
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: myservice.service: Scheduled restart job, restart counter is at 5.
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: Stopped myserviceService.
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: myservice.service: Start request repeated too quickly.
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: myservice.service: Failed with result 'exit-code'.
Feb 02 06:51:16 myservice-ubuntu-app systemd[1]: Failed to start myservice Service.
What am I doing wrong? The service runs properly in foreground with no errors, its just the service that struggles to run.
If your Go program is able to start normally (meaning not as a service, but manually from command line), then check if this is a policy issue.
For instance, a SELinux policy could prevent your Go binary to start if it is not installed in a system path (like /usr/local/bin).
Or the service definition uses relative instead of absolute paths (same here).
Or with the wrong user.
Related
When I logged in to my VM (Ubuntu 18.04) for second time, its showing error:
# systemctl status puppetserver.service
puppetserver.service - puppetserver Service Loaded: loaded
(/lib/systemd/system/puppetserver.service; enabled; vendor preset: enabled)
**Active**: failed (Result: exit-code) since Wed 2019-10-02 11:42:52 UTC; 2min 31s ago
Process: 23034
ExecStart=/opt/puppetlabs/server/apps/puppetserver/bin/puppetserver
start (code=exited, status=1/FAILURE)
Oct 02 11:42:52 puppet-master systemd[1]: puppetserver.service:
Control process exited, code=exited status=1 Oct 02 11:42:52
puppet-master systemd[1]: puppetserver.service: Failed with result
'exit-code'. Oct 02 11:42:52 puppet-master systemd[1]: Failed to start
puppetserver Service. Oct 02 11:42:52 puppet-master systemd[1]:
puppetserver.service: Service hold-off time over, scheduling restart.
Oct 02 11:42:52 puppet-master systemd[1]: puppetserver.service:
Scheduled restart job, restart counter is at 5. Oct 02 11:42:52
puppet-master systemd[1]: Stopped puppetserver Service. Oct 02
11:42:52 puppet-master systemd[1]: puppetserver.service: Start request
repeated too quickly. Oct 02 11:42:52 puppet-master systemd[1]:
puppetserver.service: Failed with result 'exit-code'. Oct 02 11:42:52
puppet-master systemd[1]: Failed to start puppetserver Service.
Is there a way to identify the issue?
To troubleshoot more, you can run:
journalctl -xe -u puppetserver
And also check the /var/log/puppetlabs/puppetserver/puppetserver.log file for more info, but based on the error message:
Start request repeated too quickly
It seems that you didn't have patience to restart (as it can take few minutes).
The best to restart I recommend to you:
systemctl restart puppet*
systemctl restart puppet pxp-agent
In this way, the services manage the dependency between all puppet* services.
Note: Server Fault, part of Stack Exchange (includes Stack Overflow) provides support for managing information technology systems in a business environment.
I have a service file that refuses to actually start the service specified in the ExecStart directive.
If I run exactly the same command from the terminal prompt, everything works as expected.
I have checked all permissions on files etc. but nothing I do will launch the program.
Here is my service file:
[Unit]
Description=Start pjsip Pjsua client in background
After=network.target
[Service]
Type=simple
RestartSec=3
ExecStart=/usr/bin/screen -dmS Pjsua /usr/local/sbin/Pjsua --config-file /usr/local/sbin/pjsua.cfg
[Install]
WantedBy=multi-user.target
and here is the output from the log file:
May 06 20:27:07 vring systemd[1]: pjsip.service: Trying to enqueue job pjsip.service/start/replace
May 06 20:27:07 vring systemd[1]: pjsip.service: Installed new job pjsip.service/start as 2553
May 06 20:27:07 vring systemd[1]: pjsip.service: Enqueued job pjsip.service/start as 2553
May 06 20:27:07 vring systemd[1]: pjsip.service: About to execute: /usr/bin/screen -dmS Pjsua /usr/local/sbin/Pjsua --confif-file /usr/local/sbin/pjsua.cfg
May 06 20:27:07 vring systemd[1]: pjsip.service: Forked /usr/bin/screen as 11355
May 06 20:27:07 vring systemd[1]: pjsip.service: Changed dead -> running
May 06 20:27:07 vring systemd[1]: pjsip.service: Job pjsip.service/start finished, result=done
May 06 20:27:07 vring systemd[1]: Started Start pjsip Pjsua client in background.
May 06 20:27:07 vring systemd[1]: pjsip.service: Child 11355 belongs to pjsip.service
May 06 20:27:07 vring systemd[1]: pjsip.service: Main process exited, code=exited, status=0/SUCCESS
May 06 20:27:07 vring systemd[1]: pjsip.service: Changed running -> stop-sigterm
May 06 20:27:07 vring systemd[1]: pjsip.service: Child 11356 belongs to pjsip.service
May 06 20:27:07 vring systemd[1]: pjsip.service: cgroup is empty
May 06 20:27:07 vring systemd[1]: pjsip.service: Changed stop-sigterm -> dead
May 06 20:27:07 vring systemd[1]: pjsip.service: Collecting.
From the above it appears as though the process has exited and I cannot understand why as it has to be commanded to do so.
If I run the command specified for ExecStart from the command line it all works perfectly. The program stays alive until I actually command it to shut down.
This problem has been driving me nuts for most of a day and I am no closer to a resolution.
Any pointers as to what I may be doing wrong would be very much appreciated.
I have solved the problem!!!
Because the system forks off the screen command I needed to change the service type to 'forking'.
It all works perfectly now.
Often it's the stupid things that catch you out!
After I installed couchdb， I could get the welcome information
$ curl localhost:5984
{"couchdb":"Welcome","version":"2.1.2","features":["scheduler"],"vendor":{"name":"The Apache Software Foundation"}}
But I can't check the status by systemctl
$ systemctl status couchdb.service
● couchdb.service
Loaded: not-found (Reason: No such file or directory)
Active: failed (Result: start-limit-hit) since 一 2018-12-03 14:52:14 CST; 6min ago
Main PID: 30946 (code=killed, signal=USR2)
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Unit entered failed state.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Failed with result 'signal'.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Service hold-off time over, scheduling restart.
12月 03 14:52:14 gpuhuawei systemd[1]: Stopped Apache CouchDB.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Start request repeated too quickly.
12月 03 14:52:14 gpuhuawei systemd[1]: Failed to start Apache CouchDB.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Unit entered failed state.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Failed with result 'start-limit-hit'.
12月 03 14:53:53 gpuhuawei systemd[1]: Stopped Apache CouchDB.
12月 03 14:53:53 gpuhuawei systemd[1]: Stopped Apache CouchDB.
When I run couchdb by command line, I got
$ couchdb
{"init terminating in do_boot",{{badmatch,{error,{bad_return,{{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,{error,eacces}}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,56}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,273}]}]}}}}}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
[1] 2288 user-defined signal 2 couchdb
My work enviroment
$ uname -a
Linux gpuhuawei 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
This is a bit late, but the "start-limit-hit" message is a red herring. I have seen something very similar with a Moodle installation using MySQL and it's actually saying that you (or the service start process) have tried to restart the database too many times or too soon after a failed attempt to start. Basically, this start-limit-hit message is saying "stop trying to do the same thing and expecting different results".
The actual issue will be further up in the syslog. Unhelpfully, service status does not return enough lines of the error messages to actually see what is wrong. Try a service start, and go and look in the actual syslog, and you will see the series of start attempts and a line just above each one hopefully will tell you the actual issue. In my case here, you can see that the problem is the mount point containing the database is missing - thanks, Azure. For one attempt of service start, it tries to start 5 times in quick succession, failing each time because the data dir was not mounted, and on the sixth it fails with the start-limit-hit.
Always back up your data/ and etc/ directories prior to upgrading CouchDB.
We recommend that you overwrite your etc/default.ini file with the version provided by the new release. New defaults sometimes contain mandatory changes to enable default functionality. Always places your customization in etc/local.ini or any etc/local.d/*.ini file.
(I was followed this and it worked)
https://docs.couchdb.org/en/3.0.0/install/upgrading.html
Trying to create a start up script for my nodejs app which runs on port 3000.
Issue: The node-app.server script is not working and I think it's because ExecStart pathway is wrong. When I go to the server IP in Chrome nothing shows.
The node app was created with npm generator, and I normally use npm start to start the app. I've added path to bin/wwww, here:
[Unit]
Description=tweetMonster twtiter server - making your environment variables rad
Documentation=https://example.com
After=network.target
[Service]
Environment=NODE_PORT=3000
Type=simple
User=ubuntu
ExecStart=/home/ubuntu/twitter-server/bin/www.js
Restart=on-failure
[Install]
WantedBy=multi-user.target
My app is running on Ubuntu 18 at /home/ubuntu/twitter-server . And if do ls:
/twitter-server$ ls
app.js node_modules package.json routes
bin package-lock.json public views
Please help!
ERROR TERMINAL:
Nov 01 05:40:25 ip-172-31-22-207 systemd[1]: node-app.service: Main process exited, code=exited, status=203/EXEC
Nov 01 05:40:25 ip-172-31-22-207 systemd[1]: node-app.service: Failed with result 'exit-code'.
Nov 01 05:40:26 ip-172-31-22-207 systemd[1]: node-app.service: Service hold-off time over, scheduling restart.
Nov 01 05:40:26 ip-172-31-22-207 systemd[1]: node-app.service: Scheduled restart job, restart counter is at 5.
Nov 01 05:40:26 ip-172-31-22-207 systemd[1]: Stopped hello_env.js - making your environment variables rad.
Nov 01 05:40:26 ip-172-31-22-207 systemd[1]: node-app.service: Start request repeated too quickly.
Nov 01 05:40:26 ip-172-31-22-207 systemd[1]: node-app.service: Failed with result 'exit-code'.
Nov 01 05:40:26 ip-172-31-22-207 systemd[1]: Failed to start hello_env.js - making your environment variables rad.
Nov 01 06:20:11 ip-172-31-22-207 systemd[1]: /etc/systemd/system/node-app.service:10: Executable path is not absolute: "node /home/ubuntu/twitter-server/bin/www.js"
Nov 01 06:24:35 ip-172-31-22-207 systemd[1]: /etc/systemd/system/node-app.service:10: Executable path is not absolute: "node /home/ubuntu/twitter-server/bin/www.js"
root#ip-172-31-22-207:/etc/systemd/system#
There are 2 issues with your service config.
First, wrap the value of Environment with double quotes:
Environment="NODE_PORT=3000"
Second,
You need to use node to run the ExecStart script. /home/ubuntu/twitter-server/bin/www.js is no command in itself.
Do,
ExecStart=/bin/bash -c '$$(which node) /home/ubuntu/twitter-server/bin/www.js'
I recommend this package (service-systemd) for a simple program
Sometimes you just want an "old style" daemon for simple services.
Sometimes you have to deploy in small devices (like a RaspberryPi) and you can't use Docker and all the band.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
here is my problem. I have CentOS and java process running on it. Java process is operated by the start/stop script. It creates a .pid file of java instance too.
My unit file is looking like:
[Unit]
After=syslog.target network.target
Description=Someservice
[Service]
User=xxxuser
Type=forking
WorkingDirectory=/srv/apps/someservice
ExecStart=/srv/apps/someservice/server.sh start
ExecStop=/srv/apps/someservice/server.sh stop
PIDFile=/srv/apps/someservice/application.pid
TimeoutStartSec=0
[Install]
WantedBy=multi-user.target
When I call stop function, script terminates java process with SIGTERM and returns 0 code:
kill $OPT_FORCEKILL `cat $PID_FILE`
<...>
return 0
After that, if I check the status of my unit, I get something like that (status=143):
● someservice.service - Someservice
Loaded: loaded (/usr/lib/systemd/system/someservice.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-08-30 09:17:40 EEST; 4s ago
Process: 48365 ExecStop=/srv/apps/someservice/server.sh stop (code=exited, status=0/SUCCESS)
Main PID: 46115 (code=exited, status=143)
Aug 29 17:10:02 whatever.domain.com systemd[1]: Starting Someservice...
Aug 29 17:10:02 whatever.domain.com systemd[1]: PID file /srv/apps/someservice/application.pid not readable (yet?) after start.
Aug 29 17:10:04 whatever.domain.com systemd[1]: Started Someservice.
Aug 30 09:17:39 whatever.domain.com systemd[1]: Stopping Someservice...
Aug 30 09:17:39 whatever.domain.com server.sh[48365]: Stopping someservice - PID [46115]
Aug 30 09:17:40 whatever.domain.com systemd[1]: someservice.service: main process exited, code=exited, status=143/n/a
Aug 30 09:17:40 whatever.domain.com systemd[1]: Stopped Someservice.
Aug 30 09:17:40 whatever.domain.com systemd[1]: Unit someservice.service entered failed state.
Aug 30 09:17:40 whatever.domain.com systemd[1]: someservice.service failed.
When I haven't got the return value in my start/stop script, it acts absolutely the same.
Adding into the unit file something like:
[Service]
SuccessExitStatus=143
is not good idea for me. Why the systemctl acting so and doesn't show me normal service state?
When I try to modify my start/stop script and instead of return 0 I put return 10 it acts the same, but I can see that exit 10 is passed.
Here is an example:
● someservice.service - Someservice
Loaded: loaded (/usr/lib/systemd/system/someservice.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-08-30 09:36:22 EEST; 5s ago
Process: 48460 ExecStop=/srv/apps/someservice/server.sh stop (code=exited, status=10)
Process: 48424 ExecStart=/srv/apps/someservice/server.sh start (code=exited, status=0/SUCCESS)
Main PID: 48430 (code=exited, status=143)
Aug 30 09:36:11 whatever.domain.com systemd[1]: Starting Someservice...
Aug 30 09:36:11 whatever.domain.com systemd[1]: PID file /srv/apps/someservice/application.pid not readable (yet?) after start.
Aug 30 09:36:13 whatever.domain.com systemd[1]: Started Someservice.
Aug 30 09:36:17 whatever.domain.com systemd[1]: Stopping Someservice...
Aug 30 09:36:17 whatever.domain.com server.sh[48460]: Stopping someservice - PID [48430]
Aug 30 09:36:21 whatever.domain.com systemd[1]: someservice.service: main process exited, code=exited, status=143/n/a
Aug 30 09:36:22 whatever.domain.com systemd[1]: someservice.service: control process exited, code=exited status=10
Aug 30 09:36:22 whatever.domain.com systemd[1]: Stopped Someservice.
Aug 30 09:36:22 whatever.domain.com systemd[1]: Unit someservice.service entered failed state.
Aug 30 09:36:22 whatever.domain.com systemd[1]: someservice.service failed.
From the journalctl log I can see that systemctl firstly returns the status=143 and then my return value of 10. So i guess that my mistake is somewhere in start/stop script (because error code 143 is passed before function returns 0)?
You should be able to suppress this by adding the exit code into the unit file as a "success" exit status:
[Service]
SuccessExitStatus=143
source