1

_note: the original posted question is edited and its faced has changed quite a bit!

Summary:

A python script using apshceduler fails to load as service with exit code staus1. Important to note that same script designed to run every 10 seconds using while True: (without using apscheduler to do the same task) syntax runs very well as daemon (service).

Details

I wrote a simple test.py program. It appends some a.txt file every 10 seconds with "some" string. When I try to run it as daemon service throws error code. . In itself, without using it as daemon (service), the code works fine. Also if I don't use apscheduler in writing the test.py file then the service runs smoothly.

I will put all the code here for details including the systemctl status

#!/usr/bin/env python3
import os, glob, shutil
from datetime import datetime
from apscheduler.schedulers.blocking import BlockingScheduler
sched = BlockingScheduler()
def test():
    appendFile = open(r'/home/sangharsh/code/a.txt', 'a')
    appendFile.write("Jai Bhim \n" )
    appendFile.close()
sched.add_job(test, 'interval', seconds=10)

sched.start()

Its located at /home/sangharsh/code/workingWithFiles/ To run it as daemon I create service file -

[Unit]
Description=Test Service
After=multi-user.target
Conflicts=getty@tty1.service

[Service]
Type=simple
ExecStart=/usr/bin/env python3 /home/sangharsh/code/workingWithFiles/test.py
StandardInput=tty-force

[Install]
WantedBy=multi-user.target

This file is located at /lib/systemd/system/.

I restart the daemon:

sudo systemctl daemon-reload

Then enable the test.service file -

sudo systemctl enable test.service

and to start the test.service

sudo systemctl start test.service

and to scheck the status 

sudo systemctl status test.service

The systemctl status shows:

● test.service - Test Service
   Loaded: loaded (/lib/systemd/system/test.service; enabled; vendor preset: ena
   Active: failed (Result: exit-code) since Tue 2019-07-09 22:57:31 IST; 8min ag
  Process: 4750 ExecStart=/usr/bin/env python3 /home/sangharsh/code/workingWithF
 Main PID: 4750 (code=exited, status=1/FAILURE)

Jul 09 22:57:31 sangharsh-HP-240-G4-Notebook-PC systemd[1]: Started Test Service
Jul 09 22:57:31 sangharsh-HP-240-G4-Notebook-PC systemd[1]: test.service: Main p
Jul 09 22:57:31 sangharsh-HP-240-G4-Notebook-PC systemd[1]: test.service: Failed

The output of 'sudo journalctl -xe' is as below:

Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- The unit test.service has entered the 'failed' state with result 'exit-code'.
Jul 13 02:12:23 sangharsh-HP-240-G4-Notebook-PC sudo[18333]: sangharsh : TTY=pts/0 ; PWD=/home/sangharsh ; USER=root ; COMMAND=/bin/systemctl status test.service
Jul 13 02:12:23 sangharsh-HP-240-G4-Notebook-PC sudo[18333]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 13 02:12:38 sangharsh-HP-240-G4-Notebook-PC systemd-resolved[856]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Jul 13 02:13:11 sangharsh-HP-240-G4-Notebook-PC sudo[18333]: pam_unix(sudo:session): session closed for user root
Jul 13 02:13:53 sangharsh-HP-240-G4-Notebook-PC sudo[18364]: sangharsh : TTY=pts/0 ; PWD=/home/sangharsh ; USER=root ; COMMAND=/usr/bin/pip3 install apscheduler
Jul 13 02:13:53 sangharsh-HP-240-G4-Notebook-PC sudo[18364]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 13 02:13:55 sangharsh-HP-240-G4-Notebook-PC sudo[18364]: pam_unix(sudo:session): session closed for user root
Jul 13 02:14:13 sangharsh-HP-240-G4-Notebook-PC systemd-resolved[856]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Jul 13 02:15:13 sangharsh-HP-240-G4-Notebook-PC sudo[18378]: sangharsh : TTY=pts/0 ; PWD=/home/sangharsh ; USER=root ; COMMAND=/bin/journalctl -xe
Jul 13 02:15:13 sangharsh-HP-240-G4-Notebook-PC sudo[18378]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 13 02:16:02 sangharsh-HP-240-G4-Notebook-PC sudo[18378]: pam_unix(sudo:session): session closed for user root
Jul 13 02:16:32 sangharsh-HP-240-G4-Notebook-PC sudo[18388]: sangharsh : TTY=pts/0 ; PWD=/home/sangharsh ; USER=root ; COMMAND=/bin/journalctl -xe test.service
Jul 13 02:16:32 sangharsh-HP-240-G4-Notebook-PC sudo[18388]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jul 13 02:16:32 sangharsh-HP-240-G4-Notebook-PC sudo[18388]: pam_unix(sudo:session): session closed for user root
Jul 13 02:16:44 sangharsh-HP-240-G4-Notebook-PC sudo[18390]: sangharsh : TTY=pts/0 ; PWD=/home/sangharsh ; USER=root ; COMMAND=/bin/journalctl -xe
Jul 13 02:16:44 sangharsh-HP-240-G4-Notebook-PC sudo[18390]: pam_unix(sudo:session): session opened for user root by (uid=0)
~
~

I referred this question. I tried the options but it doesn't help.

Please guide.

Some Clarifications

some clarification to avoid any confusion -

  1. I tried running the test.py script and it works fine. It can write a message to 'a.txt' file. So its successful code.
  2. I also tried another way. I tried removing 'apscheduler' and instead use while True syntax. That way I was able to run it daemon. The output of systemctl status in that case is active. After giving rwx permission to ugo for "a.txt" file, I was able to run it as service file (as said in summary above)
sangharsh
  • 61
  • 1
    (1) Does the script write to the file at all, even once? (2) If the answer to the first question is “no”, is it possible that there’s a permissions problem?  Does the directory /home/sangharsh/code exist?  Try writing to a file in /tmp.  (3) You say “if I don't use apscheduler in writing the test.py file then the service runs smoothly.”  Can you clarify that? (4) You mention a while True: syntax.  What are you talking about?  Is this the answer to question #3? … … … … … … … … … Please do not respond in comments; [edit] your question to make it clearer and more complete. – Scott - Слава Україні Jul 09 '19 at 17:37
  • The journalctl output unfortunately doesn't contain anything about the service itself anymore, just the sudo logs of you viewing the logs. Also please don't use -x when posting logs anywhere. Use journalctl -e -u test.service to fetch relevant log lines. – Wüstengecko Jul 18 '19 at 18:18

2 Answers2

2

This line in the systemd unit file is still wrong:

ExecStart=/usr/bin/env/python3 /home/sangharsh/code/workingWithFiles/test.py

I am pretty sure there is no /usr/bin/env/python3 on your system. It's the same problem as in muru's first comment.

Tomáš Pospíšek
  • 634
  • I have appended the question long back with updated error. This is the error I am getting after following the corrections suggested by @muru – sangharsh Jul 12 '19 at 08:55
  • Have I answered your question? – sangharsh Jul 12 '19 at 12:52
  • 2
  • The systemd unit in your question still contains ExecStart=/usr/bin/env/python3, which is wrong. 2. The output from systemctl status is incomplete (cut after a fixed number of characters). So we can't see the whole error message. 3. Since what's happening here is improving code bit by bit and updating bits of the question accordingly a lot of the info you are giving above is not applicable any more. So I'd suggest to scratch the whole question and include only what you have now, which helps us helping you.
    • – Tomáš Pospíšek Jul 12 '19 at 18:04
  • Done. I will re-writing the whole question – sangharsh Jul 12 '19 at 18:11
  • I have edited the question. I hope now it is much better. – sangharsh Jul 12 '19 at 18:25
  • (1) Your systemd unit now contains ExecStart=/usr/bin/env/ python3 /home/sangharsh/code/workingWithFiles/test.py which is still wrong, it should be ExecStart=/usr/bin/env python3 /home/sangharsh/code/workingWithFiles/test.py. (2) However the systemctl status output contains Process: 4750 ExecStart=/usr/bin/env python3 /home/sangharsh/code/workingWithF which is different from the unit file. So which one is correct? – Tomáš Pospíšek Jul 12 '19 at 18:43
  • (3) When systemd starts the script, it will require read/exec rights to /home/sangharsh/code/workingWithFiles/test.py. Does it have them? Alternatively put the file into /usr/local/bin? (4) The output from systemctl status in your question is still cut off, not allowing us to see the whole output... – Tomáš Pospíšek Jul 12 '19 at 18:44
  • (5) Also, the script is writing to /home/sangharsh/code/a.txt which it might not have the access rights to do. Try instead writing to /tmp/a.txt. – Tomáš Pospíšek Jul 12 '19 at 18:50
  • Let us continue this discussion in chat. – sangharsh Jul 12 '19 at 18:56