Systemd service not recognizing python library - python

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.

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

How can i resolve the start limit hit error

Hi I recently bought a Raspberry Pi 4
I am trying to program a discord bot for my server
Here is the error
pi#raspberrypi:~ $ sudo nano /lib/systemd/system/discordbot.service
pi#raspberrypi:~ $ sudo systemctl status discordbot.service
● discordbot.service - My Discord Bot Service
Loaded: loaded (/lib/systemd/system/discordbot.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit-hit) since Wed 2020-06-03 22:28:41 +08; 20min ago
Main PID: 856 (code=exited, status=0/SUCCESS)
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Service RestartSec=100ms expired, scheduling restart.
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Scheduled restart job, restart counter is at 5.
Jun 03 22:28:41 raspberrypi systemd[1]: Stopped My Discord Bot Service.
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Start request repeated too quickly.
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Failed with result 'start-limit-hit'.
Jun 03 22:28:41 raspberrypi systemd[1]: Failed to start My Discord Bot Service.
Here is the log to see my error
pi#raspberrypi:~ $ journalctl -e -u discordbot
Jun 03 22:28:41 raspberrypi systemd[1]: Started My Discord Bot Service.
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Succeeded.
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Service RestartSec=1
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Scheduled restart jo
Jun 03 22:28:41 raspberrypi systemd[1]: Stopped My Discord Bot Service.
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Start request repeat
Jun 03 22:28:41 raspberrypi systemd[1]: discordbot.service: Failed with result '
Jun 03 22:28:41 raspberrypi systemd[1]: Failed to start My Discord Bot Service.
[2]+ Stopped journalctl -e -u discordbot
Here is the code for the systemd
[Unit]
Description=My Discord Bot Service
After=network-online.target
[Service]
Type=idle
Restart=always
User=pi
ExecStart=/usr/bin/python3 /home/pi/discordbot/discordbot.py
[Install]
WantedBy=multi-user.target
I have tried to find solutions for hours but none helped
All help is appreciated :)

Troubleshooting mongodb service crash

I'm running a python program on a raspberry pi (Linux) which logs data into mongodb (using the pymongo module). I'm having trouble understanding when the mongodb service stops running or why it would ever stop.
Right now, I have my program functions set up so that if they fail to access mongodb (get pymongo connection exceptions), they try to restart the service, wait ten seconds and then re-attempt the operation. These functions are recursive like so:
def get_database_collection():
try:
# code to get document
return document
except Exception:
# code to log exception in my log files
start_mongo_service()
get_database_collection()
And this is what the start_mongo_service() function looks like:
def start_mongo_service():
try:
subprocess.call(["sudo", "service", "mongodb", "start"])
time.sleep(10)
return True
except Exception:
# code to log exception in my log files (Could not start_mongo_service)
database_logger = logging.getLogger('database_thread')
database_logger.exception("Could not start_mongo_service")
time.sleep(10)
return False
Now, I'm aware that catching all exceptions is bad practice, but I do it because I do not want my code to ever crash, and I log any exception that occurs so I can examine the code's behaviour.
So yesterday my program crashed and the error given on console was: MaximumRecursionDepth exceeded, which I'm assuming means it looped 1000 times and still couldn't escape its exception. This is what the program's log looks like:
2019-01-15 18:12:50,000 - ERROR - database_thread - Could not start_mongo_service
Traceback (most recent call last):
File "gateway-embedded-code/database.py", line 89, in update_status_collection
AttributeError: 'NoneType' object has no attribute 'update'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "pymongo/mongo_client.py", line 266, in __init__
File "pymongo/mongo_client.py", line 641, in __find_node
pymongo.errors.AutoReconnect: could not connect to localhost:27017: [Errno 110] Connection timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "gateway-embedded-code/database.py", line 35, in get_database_collection
File "pymongo/mongo_client.py", line 269, in __init__
pymongo.errors.ConnectionFailure: could not connect to localhost:27017: [Errno 110] Connection timed out
The pymongo exceptions above occurred a lot of times, I shortened them for posting here. Then I tried to look at mongodb's own logs in /var/log/mongodb and the last entry was at Jan 15 17:51:54! After that there was nothing in the logs for that day... I guess the service stopped and my program couldn't restart it either so it crashed at 18:12:50...
Tue Jan 15 17:51:54.391 [conn11125] end connection 127.0.0.1:53052 (1 connection now open)
Tue Jan 15 17:51:54.393 [initandlisten] connection accepted from 127.0.0.1:53054 #11126 (2 connections now open)
Tue Jan 15 17:51:54.408 [conn11126] end connection 127.0.0.1:53054 (1 connection now open)
Tue Jan 15 17:51:54.410 [initandlisten] connection accepted from 127.0.0.1:53056 #11127 (2 connections now open)
Wed Jan 16 04:33:04.994 [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends
Wed Jan 16 04:33:04.994 [signalProcessingThread] now exiting
Wed Jan 16 04:33:04.994 dbexit:
Wed Jan 16 04:33:04.994 [signalProcessingThread] shutdown: going to close listening sockets...
Wed Jan 16 04:33:04.994 [signalProcessingThread] closing listening socket: 9
Wed Jan 16 04:33:04.994 [signalProcessingThread] closing listening socket: 10
Wed Jan 16 04:33:04.994 [signalProcessingThread] closing listening socket: 11
Wed Jan 16 04:33:04.994 [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock
Wed Jan 16 04:33:04.994 [signalProcessingThread] shutdown: going to flush diaglog...
Wed Jan 16 04:33:04.994 [signalProcessingThread] shutdown: going to close sockets...
Wed Jan 16 04:33:04.994 [signalProcessingThread] shutdown: waiting for fs preallocator...
Wed Jan 16 04:33:04.994 [signalProcessingThread] shutdown: lock for final commit...
Wed Jan 16 04:33:04.994 [signalProcessingThread] shutdown: final commit...
Wed Jan 16 04:33:04.995 [signalProcessingThread] shutdown: closing all files...
Wed Jan 16 04:33:04.995 [conn11127] end connection 127.0.0.1:53056 (1 connection now open)
Wed Jan 16 04:33:04.997 [signalProcessingThread] closeAllFiles() finished
Wed Jan 16 04:33:04.997 [signalProcessingThread] journalCleanup...
Wed Jan 16 04:33:04.997 [signalProcessingThread] removeJournalFiles
Wed Jan 16 04:33:05.053 [conn4] end connection 127.0.0.1:56470 (0 connections now open)
Wed Jan 16 04:33:05.223 [signalProcessingThread] shutdown: removing fs lock...
Wed Jan 16 04:33:05.224 dbexit: really exiting now
***** SERVER RESTARTED *****
# Everything works fine from this point onwards
Today is Jan 16 and all Jan 16 messages were logged when I rebooted the raspberry pi, the program works completely fine now... but this issue continues to occur when I leave it running and check the next day.
My question is, why would this be happening? When does mongo service stop? Why can't I restart it with my function? Can anybody explain what can be deduced from the logs? Could unexpected power disconnects cause mongodb service to not run on startup? Please help me troubleshoot what could be happening and how I can handle it, I don't want my program to crash!
Sorry for the long post, I can provide any more details you require.
Thank you for reading.
EDIT: Just want to clarify where the AttributeError: Nonetype is coming from. Keep in mind that by collection I just mean a document in the database.
I have a function called update_status_collection():
def update_status_collection(the_update):
try:
document = get_database_collection(collection_name='status_collection')
document.update(the_update)
except Exception:
database_logger = logging.getLogger('database_thread')
database_logger.exception('Could not update_status_collection')
start_mongo_service()
update_status_collection(the_update)
Now for some reason, the get_database_collection function returns a Nonetype to the document variable and that's where the AttributeError exception is raised, because you can't update a Nonetype. Although I am curious how Nonetype is returned when get_database_collection() is recursive as well..... it's gotta return None after it's reached MaximumRecursionDepth right? That's something I have yet to look into.
UPDATE: Okay I was searching through syslogs to find something suspicious and I think I found the point linux stopped mongo, Below are syslogs for Jan 15 (/var/log/syslog):
Jan 15 12:12:07 raspberrypi systemd[1]: Stopping An object/document-oriented database...
Jan 15 12:12:08 raspberrypi systemd[1]: Stopped An object/document-oriented database.
Jan 15 12:12:08 raspberrypi rc.local[463]: [967] Failed to execute script __main__
Jan 15 12:12:11 raspberrypi systemd[1]: Started An object/document-oriented database.
Jan 15 12:12:11 raspberrypi mongod[2336]: all output going to: /var/log/mongodb/mongodb.log
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped target Timers.
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped Daily apt upgrade and clean activities.
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped target Bluetooth.
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped Daily apt download activities.
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping User Manager for UID 1000...
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped target System Time Synchronized.
Jan 15 12:14:22 raspberrypi vncserver-x11-serviced[453]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
Jan 15 12:14:22 raspberrypi vncserver-x11-serviced[453]: after 14426 requests (14426 known processed) with 0 events remaining.
Jan 15 12:14:22 raspberrypi bluetoothd[524]: Terminating
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping Bluetooth service...
Jan 15 12:14:22 raspberrypi watchdog[562]: stopping daemon (5.15)
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping Disk Manager...
Jan 15 12:14:22 raspberrypi udisksd[883]: udisks daemon version 2.1.8 exiting
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped target Sound Card.
Jan 15 12:14:22 raspberrypi bluetoothd[524]: Stopping SDP server
Jan 15 12:14:22 raspberrypi systemd[1]: Closed Load/Save RF Kill Switch Status /dev/rfkill Watch.
Jan 15 12:14:22 raspberrypi bluetoothd[524]: Exit
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping watchdog daemon...
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping Save/Restore Sound Card State...
Jan 15 12:14:22 raspberrypi systemd[1]: Unmounting RPC Pipe File System...
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping Authorization Manager...
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped Daily Cleanup of Temporary Directories.
Jan 15 12:14:22 raspberrypi systemd[1]: Stopping Session c1 of user pi.
Jan 15 12:14:22 raspberrypi systemd[1]: Stopped Getty on tty1.
Jan 15 12:14:22 raspberrypi vncserver-x11-serviced[453]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
Jan 15 12:14:28 raspberrypi systemd-modules-load[111]: Inserted module 'i2c_dev'
Jan 15 12:14:28 raspberrypi systemd[1]: Started Apply Kernel Variables.
Jan 15 12:14:28 raspberrypi fake-hwclock[112]: Tue 15 Jan 12:14:24 UTC 2019
Jan 15 12:14:28 raspberrypi systemd[1]: Time has been changed
Jan 15 12:14:28 raspberrypi systemd[1]: Started Restore / save the current clock.
Jan 15 12:14:28 raspberrypi systemd-fsck[113]: e2fsck 1.43.4 (31-Jan-2017)
Jan 15 12:14:28 raspberrypi systemd[1]: Started Create Static Device Nodes in /dev.
Jan 15 12:14:28 raspberrypi systemd[1]: Starting udev Kernel Device Manager...
Jan 15 12:14:28 raspberrypi systemd-fsck[113]: /dev/mmcblk0p2: clean, 137720/939744 files, 1384356/3809792 blocks
Jan 15 12:14:28 raspberrypi systemd[1]: Started File System Check on Root Device.
Jan 15 12:14:28 raspberrypi systemd[1]: Starting Remount Root and Kernel File Systems...
Jan 15 12:14:28 raspberrypi systemd[1]: Started Remount Root and Kernel File Systems.
Jan 15 12:14:28 raspberrypi systemd[1]: Starting Load/Save Random Seed...
Jan 15 12:14:28 raspberrypi systemd[1]: Starting udev Coldplug all Devices...
Jan 15 12:14:28 raspberrypi systemd[1]: Starting Flush Journal to Persistent Storage...
Jan 15 12:14:28 raspberrypi systemd[1]: Started Load/Save Random Seed.
Jan 15 12:14:28 raspberrypi systemd[1]: Started Flush Journal to Persistent Storage.
Jan 15 12:14:28 raspberrypi systemd[1]: Started Set the console keyboard layout.
Jan 15 12:14:28 raspberrypi systemd[1]: Reached target Local File Systems (Pre).
Jan 15 12:14:28 raspberrypi systemd[1]: Started udev Kernel Device Manager.
Jan 15 12:14:28 raspberrypi systemd[1]: Started udev Coldplug all Devices.
Jan 15 12:14:28 raspberrypi systemd[1]: Starting Show Plymouth Boot Screen...
Jan 15 12:14:28 raspberrypi systemd[1]: Found device /dev/serial1.
Jan 15 12:14:28 raspberrypi systemd[1]: Started Show Plymouth Boot Screen.
Jan 15 12:14:28 raspberrypi systemd[1]: Reached target Encrypted Volumes.
Jan 15 12:14:28 raspberrypi systemd[1]: Reached target Paths.
Jan 15 12:14:28 raspberrypi systemd[1]: Started Forward Password Requests to Plymouth Directory Watch.
Jan 15 12:14:28 raspberrypi mtp-probe: checking bus 1, device 3: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1"
Jan 15 12:14:28 raspberrypi mtp-probe: checking bus 1, device 4: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Jan 15 12:14:28 raspberrypi mtp-probe: checking bus 1, device 5: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4"
Jan 15 12:14:28 raspberrypi mtp-probe: bus: 1, device: 4 was not an MTP device
Jan 15 12:14:28 raspberrypi mtp-probe: bus: 1, device: 5 was not an MTP device
Jan 15 12:14:28 raspberrypi mtp-probe: bus: 1, device: 3 was not an MTP device
Jan 15 12:14:28 raspberrypi systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
Jan 15 12:14:28 raspberrypi systemd[1]: Reached target Sound Card.
Jan 15 12:14:28 raspberrypi systemd[1]: Found device /dev/disk/by-partuuid/f143b93d-01.
Jan 15 12:14:28 raspberrypi systemd[1]: Starting File System Check on /dev/disk/by-partuuid/f143b93d-01...
The first two lines stop the database, the third line "Failed to execute script main" is from my program! But immediately afterwards it restarts the database.... Can someone make sense of what happened? It seems a lot of services were stopped and then restarted...
This issue has now been solved, when reading my temperature sensor on the raspberry pi using SPI, spi.close() was not being called properly and as a result every spi.open() was resulting in a new spidev file being opened. There's a limit to how many files one process can open, and that limit was being reached in my case in around 6-7 hours, after which the script crashed.
It's also important to note that proper logging was not implemented in this area of the code nor were exceptions properly caught, so the exception "OSError: Too many open files" was not being caught or logged making this a very mysterious issue.
Once the exception was caught, it was an easy fix, by properly adding spi.close() every place where spi was being opened.
You can check how many files your process has opened using:
lsof -p <pid_of_your_process>
The lsof command was not installed by default on my linux distribution so I used:
sudo apt install lsof
Now the reason this is related to my pymongo connection exceptions is because in order to make a connection, the pymongo module calls open() on various things like sockets etc, which in turn opens a file. I hypothesize that my program was unable to open these files after six hours, because it had already reached the maximum number of files it could open, and therefore raised the pymongo exceptions.
Hope this helps somebody!

SystemD python task in Ubuntu 16

I am trying to execute a python3 with systemd in a ubuntu 16.
Following are the configs
[Unit]
Description=email notification server
After=multi-user.target
[Service]
WorkingDirectory=/home/ubuntu/email-noti
Restart=on-failure
ExecStart=/usr/lib/python3 /home/ubuntu/email-noti/email_reader.py
[Install]
WantedBy=multi-user.target
*please note that email_reader.py import a config file and few python3 files from /home/ubuntu/email-noti/
but it always end with following error
● email-noti.service - email notification server
Loaded: loaded (/etc/systemd/system/email-noti.service; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: exit-code) since Tue 2017-03-07 18:00:38 UTC; 6s ago
Process: 11859 ExecStart=/usr/lib/python3 /home/ubuntu/email-noti/email_reader.py (code=exited, status=203/EXEC)
Main PID: 11859 (code=exited, status=203/EXEC)
Mar 07 18:00:38 ip-172-31-24-115 systemd[1]: email-noti.service: Service hold-off time over, scheduling restart.
Mar 07 18:00:38 ip-172-31-24-115 systemd[1]: Stopped email notification server.
Mar 07 18:00:38 ip-172-31-24-115 systemd[1]: email-noti.service: Start request repeated too quickly.
Mar 07 18:00:38 ip-172-31-24-115 systemd[1]: Failed to start email notification server.
but when i manually execute the email_reader.py works totally fine.
Any help appreciated

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