Failed to execute command: Permission denied Ubuntu [closed] - python

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 3 days ago.
Improve this question
My first attempt to web, i made site, bought server, domain etc.
But i can't put it on server because of this error
Chmod doesn't work for me. Or maybe i use it incorrectly but i don't think so
*Traceback:*
Feb 17 17:43:00 vds2389469 systemd[1]: Started Gunicorn instance to serve makeitshort.
Feb 17 17:43:00 vds2389469 systemd[622]: makeitshort.service: Failed to execute command: Permission denied
Feb 17 17:43:00 vds2389469 systemd[622]: makeitshort.service: Failed at step EXEC spawning /home/makeitshortsys/makeitshort/venv/bin/gunicorn: Permission denied
Feb 17 17:43:00 vds2389469 systemd[1]: makeitshort.service: Main process exited, code=exited, status=203/EXEC
Feb 17 17:43:00 vds2389469 systemd[1]: makeitshort.service: Failed with result 'exit-code'.
*Service File:*
[Unit]
Description=Gunicorn instance to serve makeitshort
After=network.target
[Service]
User=makeitshortsys
Group=www-data
WorkingDirectory=/home/makeitshortsys/makeitshort
Envirovement="PATH=/home/makeitshortsys/makeitshort/venv/bin"
ExecStart=/home/makeitshortsys/makeitshort/venv/bin/gunicorn --workers 3 --bind unix:makeitshort.sock -m 007 wsgi:app
[Install]
WantedBy=multi-user.target
*File permission:*
-rwxrwxrwx 1 root root 393 Feb 17 14:31 makeitshort.service
*User i used in service id:*
uid=1001(makeitshortsys) gid=1001(makeitshortsys) groups=1001(makeitshortsys),27(sudo)
I was expecting it's gonna work, but it's not
I tried use chmod on it but it didn't worked
I searched in web answer for my question but there wasn't familiar problem if i'm wrong just leave me the link

Related

Trying to run a service using systemd after startup

I have listed below the steps as I entered them. I cannot get the Pi (Raspbian GNU/Linux Buster (10)) to launch alarm.service after startup. When I log into the Pi and launch alarm.service manually from the GUI it works, as does the script it runs -- (The script is written to loop) Only problem is I can't get alarm.service to launch automatically without the GUI. Be great to have it launch last after all other services are up and running.
1. sudo nano /home/pi/alarm_service.py - (fyi: this script runs nicely when i launch it manually from command prompt after pi has booted and i am logged in)
2. sudo nano /etc/systemd/system/alarm.service
[Unit]
Description=Alarm Service
After=multi-user.target
Conflicts=getty#tty1.service
[Service]
Type=simple
ExecStart=/home/pi/alarm_service.py
StandardInput=tty-force
[Install]
WantedBy=multi-user.target
3. sudo chmod 644 /etc/systemd/system/alarm.service
4. sudo systemctl daemon-reload
5. sudo systemctl enable alarm.service
6. sudo systemctl start alarm.service
Error log:
alarm.service - Alarm service Loaded: loaded (/etc/systemd/system/alarm.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2021-05-14 18:57:24 AEST; 1min 18s ago Process: 501 ExecStart=/home/pi/alarm_service.py (code=exited, status=1/FAILURE) Main PID: 501 (code=exited, status=1/FAILURE)
May 14 18:57:24 raspberrypi alarm_service.py[501]: File "/usr/local/lib/python2.7/dist-packages/paho/mqtt/client.py", line 10 May 14 18:57:24 raspberrypi alarm_service.py[501]: sock = self._create_socket_connection() May 14 18:57:24 raspberrypi alarm_service.py[501]: File "/usr/local/lib/python2.7/dist-packages/paho/mqtt/client.py", line 35 May 14 18:57:24 raspberrypi alarm_service.py[501]: return socket.create_connection(addr, source_address=source, timeout=sel May 14 18:57:24 raspberrypi alarm_service.py[501]: File "/usr/lib/python2.7/socket.py", line 575, in create_connection May 14 18:57:24 raspberrypi alarm_service.py[501]: raise err May 14 18:57:24 raspberrypi alarm_service.py[501]: socket.error: [Errno 101] Network is unreachable May 14 18:57:24 raspberrypi systemd[1]: alarm.service: Main process exited, code=exited, status=1/FAILURE May 14 18:57:24 raspberrypi systemd[1]: alarm.service: Failed with result 'exit-code'. May 14 18:57:24 raspberrypi systemd[1]: Failed to start Alarm service.
The principle I follow is to make the environment that systemd creates for the script to run as similar to what I use to develop it as possible.
For the sake of testing I just ran shutdown -r now on a VM where I do this exact thing. On boot, voila.
$ systemctl status mypython
● mypython.service
Loaded: ...etc.
The file I have set is
less /etc/systemd/system/multi-user.target.wants/mypython.service
Content
[Unit]
Description=mypython
[Service]
WorkingDirectory=/home/me
ExecStart=/usr/bin/python3 /home/me/mypython.py ./config.yaml
Restart=always
RestartSec=5
User=me
Group=me
[Install]
WantedBy=multi-user.target

'Main process exited' error Gunicorn systemd file

I follow this article to deploy my Django project. I created gunicorn.service file in /etc/systemd/system/gunicorn.service with this configuration:
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=azizbek
Group=www-data
WorkingDirectory=/home/admin/respositories/ninersComingSoon
ExecStart=/root/.local/share/virtualenvs/ninersComingSoon-_UZsUc5R/bin/gunicorn --access-logfile - --workers 3 --bind unix:/home/admin/repositories/ninersComingSoon/niners.sock ninersComingSoon.wsgi:application
[Install]
WantedBy=multi-user.target
Location of my project is /home/admin/respositories/ninersComingSoon
And when I run
systemctl start gunicorn
systemctl enable gunicorn
it must create niners.sock file inside the project directory but it doesn't.
Then I typed this command to figure out what I did wrong.
journalctl -u gunicorn
And the result was
Dec 05 02:05:26 server.niners.uz systemd[1]: Started gunicorn daemon.
Dec 05 02:05:26 server.niners.uz systemd[1]: gunicorn.service: Main process exited, code=exited, status=203/EXEC
Dec 05 02:05:26 server.niners.uz systemd[1]: gunicorn.service: Unit entered failed state.
Dec 05 02:05:26 server.niners.uz systemd[1]: gunicorn.service: Failed with result 'exit-code'.
So can you help me to solve this problem?
The problem was in WorkingDirectory. There was an incorrect path. There should be .../repositories/... instead of .../respositories/...

Systemd service not recognizing python library

I'm trying to run a python discord bot when my Raspberry Pi starts up. To do this, I've used a systemd service:
[Unit]
Description=Testing
[Service]
Type=idle
WorkingDirectory=/home/pi
ExecStart=/usr/bin/python3 /home/pi/discord/bug.py
[Install]
WantedBy=multi-user.target
I have done several test using simpler python programs before, and it all works fine. When trying to run the discord bot, it throws an error at the import statement. For testing I run:
sudo systemctl start bugstart
sudo systemctl status bugstart
The output of the status is the following:
bugstart.service - Testing
Loaded: loaded (/lib/systemd/system/bugstart.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-08-12 02:08:47 UTC; 1s ago
Process: 1039 ExecStart=/usr/bin/python3 /home/pi/discord/bug.py (code=exited, status=1/FAILURE)
Main PID: 1039 (code=exited, status=1/FAILURE)
Aug 12 02:08:46 raspberrypi systemd[1]: Started Testing.
Aug 12 02:08:47 raspberrypi python3[1039]: Traceback (most recent call last):
Aug 12 02:08:47 raspberrypi python3[1039]: File "/home/pi/discord/bug.py", line 1, in <module>
Aug 12 02:08:47 raspberrypi python3[1039]: import discord
Aug 12 02:08:47 raspberrypi python3[1039]: ImportError: No module named 'discord'
Aug 12 02:08:47 raspberrypi systemd[1]: bugstart.service: Main process exited, code=exited, status=1/FAILURE
Aug 12 02:08:47 raspberrypi systemd[1]: bugstart.service: Unit entered failed state.
Aug 12 02:08:47 raspberrypi systemd[1]: bugstart.service: Failed with result 'exit-code'.
I found out that the commands are run as root, so I figured it might be that the library hand't been installed on root, but I tried importing discord in the command line shell and it worked fine.

systemd execstart python daemon dynamically using virtualenv from environment variable

I have Python script with works as a systemd daemon in CentOS 7. The daemon gets executed by the version of python I created in a virtualenv. I am trying to tweak the script to be able to set the virtualenv path in an environment variable so I can easily switch to a different virtualenv by changing paths via the one variable and restarting the service. I have created my systemd scripts to be able to initialize multiple instances of the daemon and this works great. When I try to use an environment variable to point to my python parser things break. Here is what I have so far.
/etc/systemd/system/pipeline-remove#.service:
[Unit]
Description=pipeline remove tickets worker instances as a service, instance %i
Requires=pipeline-remove.service
Before=pipeline-remove.service
BindsTo=pipeline-remove.service
[Service]
PermissionsStartOnly=true
Type=idle
User=root
ExecStart=/path/to/venv/bin/python /pipeline/python/daemons/remove_tickets.py
Restart=always
TimeoutStartSec=10
RestartSec=10
[Install]
WantedBy=pipeline-remove.service
/etc/systemd/system/pipeline-remove.service (to start all instances):
[Unit]
Description=manages pipeline remove tickets worker instances as a service, instance
[Service]
Type=oneshot
ExecStart=/usr/bin/sh /usr/bin/pipeline-remove-start.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
pipeline-remove-start.sh:
#!/bin/bash
systemctl start pipeline-remove#{1..2}
This works great for me, but things break when I try to set the python dir the following way:
/etc/profile.d/pipeline_envvars.sh:
PIPELINE_VIRTUALENV=/path/to/venv
/etc/systemd/system/pipeline-remove#.service:
[Unit]
Description=pipeline remove tickets worker instances as a service, instance %i
Requires=pipeline-remove.service
Before=pipeline-remove.service
BindsTo=pipeline-remove.service
[Service]
PermissionsStartOnly=true
Type=idle
User=root
EnvironmentFile=/etc/profile.d/pipeline_envvars.sh
ExecStart=/${PIPELINE_VIRTUALENV}/bin/python /pipeline/python/daemons/remove_tickets.py
Restart=always
TimeoutStartSec=10
RestartSec=10
[Install]
WantedBy=pipeline-remove.service
I then try to start it:
sudo systemctl daemon-reload
sudo systemctl restart pipeline-remove#{1..1}
sudo systemctl status pipeline-remove#{1..1}
The status shows the following exit code 203 which means executable not found:
● pipeline-remove#1.service - pipeline remove tickets worker instances as a service, instance 1
Loaded: loaded (/etc/systemd/system/pipeline-remove#.service; disabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since Fri 2018-01-26 15:04:50 UTC; 6s ago
Process: 11716 ExecStart=/${PIPELINE_VIRTUALENV}/bin/python /pipeline/python/daemons/remove_tickets.py (code=exited, status=203/EXEC)
Main PID: 11716 (code=exited, status=203/EXEC)
Jan 26 15:04:50 dev systemd[1]: pipeline-remove#1.service: main process exited, code=exited, status=203/EXEC
Jan 26 15:04:50 dev systemd[1]: Unit pipeline-remove#1.service entered failed state.
Jan 26 15:04:50 dev systemd[1]: pipeline-remove#1.service failed.
Found the exec code here. Also found this in syslog, /var/log/messages:
Jan 26 15:07:13 dev systemd: Starting pipeline remove tickets worker instances as a service, instance 1...
Jan 26 15:07:13 dev systemd: Failed at step EXEC spawning /${PIPELINE_VIRTUALENV}/bin/python: No such file or directory
Jan 26 15:07:13 dev systemd: pipeline-remove#1.service: main process exited, code=exited, status=203/EXEC
Jan 26 15:07:13 dev systemd: Unit pipeline-remove#1.service entered failed state.
Jan 26 15:07:13 dev systemd: pipeline-remove#1.service failed.
Jan 26 15:07:23 dev systemd: pipeline-remove#1.service holdoff time over, scheduling restart.
Jan 26 15:07:23 dev systemd: Started pipeline remove tickets worker instances as a service, instance 1.
When I try to drop the leading / in ExecStart I get a relative path error even though my env var does contain an absolute path:
Failed to start pipeline-remove#1.service: Unit is not loaded properly:
Invalid argument.
See system logs and 'systemctl status pipeline-remove#1.service' for
details.
And status shows the following:
vagrant#dev:~$ sudo systemctl status pipeline-remove#{1..1}
● pipeline-remove#1.service - pipeline remove tickets worker instances as a service, instance 1
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)
Jan 26 15:11:39 dev systemd[1]: pipeline-remove#1.service failed.
Jan 26 15:11:42 dev systemd[1]: Stopped pipeline remove tickets worker instances as a service, instance 1.
Jan 26 15:11:42 dev systemd[1]: [/etc/systemd/system/pipeline-remove#.service:12] Executable path is not absolute, ignoring: ${PIPELINE_VIRTUALENV}/bin/python /pipel...e_tickets.py
Jan 26 15:11:42 dev systemd[1]: pipeline-remove#1.service lacks both ExecStart= and ExecStop= setting. Refusing.
I used this guide to help me get started but now I'm stuck. How can I get my python daemon to come up while setting the python executable path from an environment variable?
After some more reading, I stumbled on the answer here. The problem is the first argument of ExecStart must be a literal:
ExecStart= Commands with their arguments that are executed when this
service is started. For each of the specified commands, the first
argument must be an absolute and literal path to an executable.
Reading on further on ExecStart it says:
Variables whose value is not known at expansion time are treated as
empty strings. Note that the first argument (i.e. the program to
execute) may not be a variable.
I also ended up stumbling across this answer which looks like the same problem. In the end this is what worked: wrapping the entire thing with shell to run:
[Unit]
Description=pipeline remove tickets worker instances as a service, instance %i
Requires=pipeline-remove.service
Before=pipeline-remove.service
BindsTo=pipeline-remove.service
[Service]
PermissionsStartOnly=true
Type=idle
User=root
EnvironmentFile=/etc/profile.d/pipeline_envvars.sh
ExecStart=/bin/sh -c '${PIPELINE_VIRTUALENV}/bin/python /pipeline/python/daemons/remove_tickets.py'
Restart=always
TimeoutStartSec=10
RestartSec=10
[Install]
WantedBy=pipeline-remove.service
So ExecStart=/bin/sh -c '<your command>' saves the day, I can now specify the python interpreter path for my environment variable. Will leave the answer up, hopefully, saves others some time.

Starting bottle web server through systemd?

I am trying to start a bottle web app I wrote using systemd. I made the file /etc/systemd/user/bottle.service with the following contents:
[Unit]
Description=Bottled fax service
After=syslog.target
[Service]
Type=simple
User=fax
Group=fax
WorkingDirectory=/home/fax/bottlefax/
ExecStart=/usr/bin/env python3 server.py
StandardOutput=syslog
StandardError=syslog
Restart=always
RestartSec=2
[Install]
WantedBy=bottle.target
However, when I try to start it, it fails and this is printed in journalctl:
Jun 10 17:33:31 nano systemd[1]: Started Bottled fax service.
Jun 10 17:33:31 nano systemd[1]: Starting Bottled fax service...
Jun 10 17:33:31 nano systemd[2380]: Failed at step GROUP spawning /usr/bin/env: No such process
Jun 10 17:33:31 nano systemd[1]: bottle.service: main process exited, code=exited, status=216/GROUP
Jun 10 17:33:31 nano systemd[1]: Unit bottle.service entered failed state.
Jun 10 17:33:31 nano systemd[1]: bottle.service failed.
How should I fix this?
Edit:
Changing to /usr/bin/python3 as others have suggested results in the same error (changed file though):
Jun 10 18:43:48 nano systemd[1]: Started Bottled fax service.
Jun 10 18:43:48 nano systemd[1]: Starting Bottled fax service...
Jun 10 18:43:48 nano systemd[2579]: Failed at step GROUP spawning /usr/bin/python3: No such process
Jun 10 18:43:48 nano systemd[1]: bottle.service: main process exited, code=exited, status=216/GROUP
Jun 10 18:43:48 nano systemd[1]: Unit bottle.service entered failed state.
Jun 10 18:43:48 nano systemd[1]: bottle.service failed.
I would have commented but I can't :/
Have you tried something like with an absolute path ?
ExecStart=/usr/bin/python3 /path/to/your/server.py
That's the only issue I can see here.
Another possible cause of this error, is if you have created a system user by running adduser --system, and have not created the associated group.

Categories

Resources