I'm trying to set up uwsgi service as /etc/systemd/system/emperor.uwsgi.service
[Unit]
Description=uWSGI Emperor
After=syslog.target
[Service]
ExecStart=/root/uwsgi/uwsgi --ini /etc/uwsgi/emperor.ini
# Requires systemd version 211 or newer
RuntimeDirectory=uwsgi
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
When trying to start it, I get the following error:
ubuntu#ip-172-31-16-133:~$ sudo systemctl start emperor.uwsgi.service
Job for emperor.uwsgi.service failed because the control process exited with error code. See "systemctl status emperor.uwsgi.service" and "journalctl -xe" for details.
This is the output for when I checked the status:
ubuntu#ip-172-31-16-133:~$ sudo systemctl status emperor.uwsgi.service
● emperor.uwsgi.service - uWSGI Emperor
Loaded: loaded (/etc/systemd/system/emperor.uwsgi.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: Stopped uWSGI Emperor.
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: Starting uWSGI Emperor...
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: emperor.uwsgi.service: Main process exited, code=exited
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: Failed to start uWSGI Emperor.
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: emperor.uwsgi.service: Unit entered failed state.
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: emperor.uwsgi.service: Failed with result 'exit-code'.
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: emperor.uwsgi.service: Service hold-off time over, sche
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: Stopped uWSGI Emperor.
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: emperor.uwsgi.service: Start request repeated too quick
Jan 30 11:16:05 ip-172-31-16-133 systemd[1]: Failed to start uWSGI Emperor.
I've had similar issues. It seems systemd swallows some output when failing to start a (UWSGI) service. Here are a couple of things to check to figure out what's causing the issue:
Check systemd journal: journalctl -b -u $service
Try to run the service manually: simply run the cmdline specified after ExecStart= in the systemd service file; so in your example: /root/uwsgi/uwsgi --ini /etc/uwsgi/emperor.ini
Either of these should shed some light as to whether the service fails to start.
Related
I created /etc/systemd/system/veracrypt-automount-devices.service:
[Unit]
Description=VeraCrypt auto-mount device-hosted volumes
[Service]
Type=forking
ExecStartPre=/bin/sleep 300
ExecStart=/usr/bin/veracrypt --auto-mount=devices /media/veracrypt1
[Install]
WantedBy=multi-user.target
Then I did:
sudo systemctl daemon-reload
sudo systemctl enable veracrypt-automount-devices
sudo systemctl status veracrypt-automount-devices
● veracrypt-automount-devices.service - VeraCrypt auto-mount device-hosted volumes
Loaded: loaded (/etc/systemd/system/veracrypt-automount-devices.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Sat 2020-06-06 17:28:59 CEST; 8min ago
Process: 967 ExecStartPre=/bin/sleep 300 (code=killed, signal=TERM)
Jun 06 17:27:29 username-computername systemd[1]: Starting VeraCrypt auto-mount device-hosted volumes...
Jun 06 17:28:59 username-computername systemd[1]: veracrypt-automount-devices.service: Start-pre operation timed out. Terminating.
Jun 06 17:28:59 username-computername systemd[1]: veracrypt-automount-devices.service: Failed with result 'timeout'.
Jun 06 17:28:59 username-computername systemd[1]: Failed to start VeraCrypt auto-mount device-hosted volumes.
As you can see, it doesn't work.
If I grep syslog, here is what I find:
Jun 6 16:56:08 username-computername systemd[1]: veracrypt-automount-devices.service: Control process exited, code=exited status=1
Jun 6 16:56:08 username-computername veracrypt[969]: Enter password:
Jun 6 16:56:08 username-computername systemd[1]: veracrypt-automount-devices.service: Failed with result 'exit-code'.
Jun 6 17:28:59 username-computername systemd[1]: veracrypt-automount-devices.service: Start-pre operation timed out. Terminating.
Jun 6 17:28:59 username-computername systemd[1]: veracrypt-automount-devices.service: Failed with result 'timeout'.
Basically, what I want is to be asked for the password to decrypt the device-hosted volume after I logged in with my username and password in Linux Mint.
I found how to do it. I put the veracrypt command in ~/.profile to execute the program on login. See https://askubuntu.com/a/270050/787567.
I am running this systemd command but when I screen -ls I don't see the screen.
The status is active and seems well.
But it isn't actually running when I check.
This is the .service file
[Unit]
Description=webhookdaemon
[Service]
ExecStart=/bin/bash path/to/script
RemainAfterExit=yes
Type=forking
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
Here is the script (path/to/script)
screen -S docker-hub-daemon -d -m npm run start --prefix /root/nodeserver/
Here is the status output
webookdaemon.service - webhookdaemon
Loaded: loaded (/etc/systemd/system/webookdaemon.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2018-03-13 19:55:15 UTC; 57min ago
Main PID: 2144 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/webookdaemon.service
Mar 13 19:58:29 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 19:59:03 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:00:22 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:01:21 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:02:26 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:04:41 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:47:41 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:49:53 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:52:53 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
root#aggregate-terminal-logs-tor1-01:~#
You should not be using screen to manage services. Just use systemd directly.
Make sure that Type= is set match the behavior of the service you are lauching. I could not find references to docker-hub-daemon, so I'm not sure the appropriate value for it. See man systemd.service for the documentation for Type=.
Instead of using screen -ls to check the status of the service, use systemctl status webookdaemon.
You may also wish to update the spelling of this service to be webhoookdaemon to match the spelling in the description.
My app.service file's [Service] part is the following:-
[Service]
Type=forking
Restart=no
IgnoreSIGPIPE=no
GuessMainPID=no
ExecStart=/opt/app/appl_init.d start
ExecStop=/opt/app/appl_init.d stop
TimeoutSec=infinity
After which I installed the app, and the file is correctly copied to /usr/lib/systemd/system/app.service.
I have run systemctl daemon-reload, but it seems to have no effect on the start up time! It fails just as I run systemctl start app or systemctl reload app.service with the following error:-
Job for app.service failed because a fatal signal was delivered to the control process. See "systemctl status app.service" and "journalctl -xe" for details
Output of systemctl status app is:-
● app.service - ApplicationTest
Loaded: loaded (/opt/app/appl_init.d; enabled; vendor preset: disabled)
Active: failed (Result: signal) since Tue 2017-03-21 01:55:22 EDT; 1min 4s ago
Docs: man:app(8)
Process: 4126 ExecStart=/opt/app/appl_init.d start (code=killed, signal=KILL)
Mar 21 01:55:22 centosvm systemd[1]: Starting ApplicationTest...
Mar 21 01:55:22 centosvm systemd[1]: app.service start operation timed out. Terminating.
Mar 21 01:55:22 centosvm systemd[1]: app.service stop-final-sigterm timed out. Killing.
Mar 21 01:55:22 centosvm systemd[1]: app.service: control process exited, code=killed status=9
Mar 21 01:55:22 centosvm systemd[1]: Failed to start ApplicationTest.
Mar 21 01:55:22 centosvm systemd[1]: Unit app.service entered failed state.
Mar 21 01:55:22 centosvm systemd[1]: app.service failed.
Another queer thing that I noticed is when I run systemctl show app.service -p TimeoutSec, I don't get any result; it's blank?
I have tried doing a systemctl reboot, but still, no dice.
Of course, when I change the value to anything else like TimeoutSec=5min, then it works perfectly fine. But I really need this application to take up infinity.
Where am I going wrong?
TimeoutSec=0 fixed the problem.
Apparently, if you are using a version of systemd older than 229, you will need to use 0 instead of infinity to disable the timeout.
why my service always exited when running systemd?
if change dir manualy to var/www/enterprise/src/ and execute /var/www/env/bin/celery -A catalog.tasks beat , proccess work perfectly
root#debian-django-nginx:/var/www/enterprise/src# cat /etc/systemd/system/celerybeat.service
[Unit]
Description=celery beat
[Service]
WorkingDirectory=/var/www/enterprise/src/
Type=simple
ExecStart=/var/www/env/bin/celery -A catalog.tasks beat &
KillMode=process
TimeoutSec=300
[Install]
WantedBy=multi-user.target
root#debian-django-nginx:/var/www/enterprise/src# systemctl daemon-reload
root#debian-django-nginx:/var/www/enterprise/src# systemctl start celerybeat
root#debian-django-nginx:/var/www/enterprise/src# systemctl status celerybeat
● celerybeat.service - celery beat
Loaded: loaded (/etc/systemd/system/celerybeat.service; enabled)
Active: active (exited) since Tue 2017-02-28 15:01:52 +10; 1 weeks 0 days ago
Mar 07 14:11:55 debian-django-nginx systemd[1]: celerybeat.service lacks ExecStart setting. Refusing.
Mar 07 14:28:08 debian-django-nginx systemd[1]: Started celery beat.
Mar 07 14:39:34 debian-django-nginx systemd[1]: Started celery beat.
Mar 07 15:05:56 debian-django-nginx systemd[1]: Started celery beat.
Mar 07 15:08:46 debian-django-nginx systemd[1]: Started celery beat.
Mar 07 15:19:35 debian-django-nginx systemd[1]: Started celery beat.
Mar 07 15:33:38 debian-django-nginx systemd[1]: Started celery beat.
I have a CoreOS beta (1185.2.0) installed.
I have the following systemd service file to start calico-node:
[Unit]
Description=Calico per-host agent
Requires=network-online.target
After=network-online.target
[Service]
Slice=machine.slice
PermissionsStartOnly=true
Environment=ETCD_CA_CERT_FILE=/etc/ssl/etcd/ca.pem
Environment=ETCD_CERT_FILE=/etc/ssl/etcd/etcd1.pem
Environment=ETCD_KEY_FILE=/etc/ssl/etcd/etcd1-key.pem
Environment=CALICO_DISABLE_FILE_LOGGING=true
Environment=HOSTNAME=10.79.218.2
Environment=IP=10.79.218.2
Environment=FELIX_FELIXHOSTNAME=10.79.218.2
Environment=CALICO_NETWORKING=true
Environment=NO_DEFAULT_POOLS=true
Environment=ETCD_ENDPOINTS=https://coreos-2.tux-in.com:2379,https://coreos-3.tux-in.com:2379
ExecStartPre=/bin/mkdir /var/run/calico
ExecStart=/usr/bin/rkt run --inherit-env --stage1-from-dir=stage1-fly.aci --volume=var-run-calico,kind=host,source=/var/run/calico --volume=modules,kind=host,source=/lib/modules,readOnly=false --mount=volume=modules,target=/lib/modules --volume=dns,kind=host,source=/etc/resolv.conf,readOnly=true --volume=etcd-tls-certs,kind=host,source=/etc/ssl/etcd,readOnly=true --mount=volume=dns,target=/etc/resolv.conf --mount=volume=etcd-tls-certs,target=/etc/ssl/etcd --mount=volume=var-run-calico,target=/var/run/calico --trust-keys-from-https quay.io/calico/node:v0.22.0
KillMode=mixed
Restart=always
TimeoutStartSec=0
[Install]
WantedBy=multi-user.target
welp.. the systemd fails with:
● calico-node.service - Calico per-host agent
Loaded: loaded (/etc/systemd/system/calico-node.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit-hit) since Tue 2016-10-25 04:51:15 UTC; 9min ago
Process: 1970 ExecStart=/usr/bin/rkt run --inherit-env --stage1-from-dir=stage1-fly.aci --volume=var-run-calico,kind=host,source=/var/
Process: 4307 ExecStartPre=/bin/mkdir /var/run/calico (code=exited, status=1/FAILURE)
Main PID: 1970 (code=exited, status=1/FAILURE)
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: Failed to start Calico per-host agent.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: calico-node.service: Unit entered failed state.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: calico-node.service: Failed with result 'exit-code'.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: calico-node.service: Service hold-off time over, scheduling restart.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: Stopped Calico per-host agent.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: calico-node.service: Start request repeated too quickly.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: Failed to start Calico per-host agent.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: calico-node.service: Unit entered failed state.
Oct 25 04:51:15 coreos-2.tux-in.com systemd[1]: calico-node.service: Failed with result 'start-limit-hit'.
I tried setting the environment variables on terminal and running the rkt command and I got the error message
image: using image from file /usr/lib/rkt/stage1-images/stage1-fly.aci
run: open /usr/lib/rkt/stage1-images/stage1-fly.aci.asc: no such file or directory
I think that error may relate to the following configuration file at /etc/rkt/paths.d/paths.json
{
"rktKind": "paths",
"rktVersion": "v1",
"stage1-images": "/usr/lib/rkt/stage1-images"
}
I need the paths configuration file later on for kubernetes.
any ideas? the asc file really doesn't exist there.
/usr/lib is a dynamic link to /usr/lib64. rkt configured there not to search for certificates for container images at /usr/lib64 and not /usr/lib.
it seems that by default this configuration is already set properly, so just removing the file /etc/rkt/paths.d/paths.json resolves the issue.
full answer at https://github.com/coreos/rkt/issues/3320