0

I had a service I was trying to run this way but it was slightly a large python program. I took a step back and built a dead simple python program to see if I can get it to run. It fails when I try to connect via telnet to this socket running. Below are the .socket, .service and .py files....

testPy.socket

[Unit]
Description=Socket to TESTPY for connection
PartOf=testPy.service

[Socket]
ListenStream=30001

[Install]
WantedBy=sockets.target

testPy.service

[Unit]
Description=TEST PY
After=network.target testPy.socket
Requires=testPy.socket
[Service]
ExecStart=/home/workers/miniconda2/bin/python /home/workers/testPy.py
StandardInput=socket
[Install]
WantedBy=default.target

testPy.py

import sys

END_OF_LINE = '\r\n'
while(1):
        input = sys.stdin.readline()
        buffer = input.strip()
        if not buffer:
                sys.stdout.write("OKAY DUDE")
                sys.stdout.flush()
                continue
        if buffer in ['quit', 'QUIT']:
                break
        sys.stdout.write('\n' + buffer + END_OF_LINE)
        sys.stdout.flush()

now if I run this in a command line, it runs fine. I can type quit and it exits out of the loop,echos anything back..

If I say:

systemctl start testPy.socket

and then type:

telnet localhost 30001

it connects a bit then drops it. Then various statuses are (to me ) non descriptive:

systemctl status testPy.socket

● testPy.socket - Socket to TESTPY for connection
   Loaded: loaded (/etc/systemd/system/testPy.socket; disabled; vendor preset: disabled)
   Active: failed (Result: service-failed-permanent) since Thu 2021-03-11 13:59:54 EST; 11min ago
   Listen: [::]:30001 (Stream)

Mar 11 13:59:42 dhcp-093.apo.nmsu.edu systemd[1]: Listening on Socket to TESTPY for connection.
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: Unit testPy.socket entered failed state.

systemctl status testPy.service

● testPy.service - TEST PY
   Loaded: loaded (/etc/systemd/system/testPy.service; disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Thu 2021-03-11 13:59:54 EST; 12min ago
  Process: 2087 ExecStart=/home/workers/miniconda2/bin/python /home/workers/testPy.py (code=exited, status=1/FAILURE)
 Main PID: 2087 (code=exited, status=1/FAILURE)

Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: Started TEST PY.
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: testPy.service: main process exited, code=exited, status=1/FAILURE
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: Unit testPy.service entered failed state.
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: testPy.service failed.
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: start request repeated too quickly for testPy.service
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: Failed to start TEST PY.
Mar 11 13:59:54 dhcp-093.apo.nmsu.edu systemd[1]: testPy.service failed.

I believe if I can get this simple test to work, I can get the larger .py file I need to run as it works essentially the same. I have a service and socket built for that, with generally the same errors. Though the systemctl status kosmos.service gives a failed still but says the main PID status=0/success so that is odd.

It says a start limit is the fail, but if the service as simple as the one here has to start and start and start that means something else is wrong, guessing a config in my socket or service file but not sure what. I was hoping I could have my python not change at all from listening sys.stdin.readline etc, and just the lines it read were from a connection made on that port (30001) from another machine. I thought that is what all this socket stuff does just this (all this came about because it used to run on an older machine with xinetd)

Codejoy
  • 107
  • 5
  • 17

1 Answers1

1

I'm assuming you've done the systemctl enable testPy.socket and systemctl start testPy.socket steps? And one thing I found, which I don't really understand yet, is that testPy.service is not accepted as a file name; systemd seems to want testPy@.service.

tsc_chazz
  • 905
  • 3
  • 14
  • I believe the enable is only for it to start up on restart? Also I think the @.service is when the Accept=true, though I could be wrong. I am unsure what the Accept=true really means but I could try that as well to cross it off the list. I think what is getting me is that to me this 'should' work but just isn't – Codejoy Mar 11 '21 at 20:28
  • Leaving my above comment because I am totally confused. But... I went ahead and di the testPy@.service, and it failed on an authentication agent? I put in the .socket [socket] the accept=true and this all "seems" to work. I am flumuxored... – Codejoy Mar 11 '21 at 20:33
  • `accept=yes` or `accept=true` says that a new instance of the executable should be started for each connection made. The default, `accept=no`, says that you start the program on first invocation but then every new connection gets handed to the started invocation. I think that conflicts with `StandardInput=socket`, which would cause it to fail. – tsc_chazz Mar 11 '21 at 20:40
  • That makes sense to me, though it confuses me then when a connection is broken does the instance take itself down or does it at up indefinitely ultimately causing the system to crash? Sorry I am like Happy Gilmore and am a software developer playing sysadmin today. – Codejoy Mar 11 '21 at 20:41
  • That would depend on how the service is written. When the other end of the connection drops, the service will start getting zero-length responses to its network reads; it should then cleanly terminate itself. Likewise, it should terminate itself when its job is done. – tsc_chazz Mar 11 '21 at 20:48
  • Like how the python code is written or the definition in the @.service file? – Codejoy Mar 11 '21 at 21:27
  • That'll be the Python code. (Or C code, or however you're writing your service handler.) – tsc_chazz Mar 11 '21 at 21:29
  • Ahh okay, I realized I cannot ps aux | grep python to see how many instances of that py file are running, is there another way where I can see to make sure the instances are not getting out of hand? – Codejoy Mar 11 '21 at 22:53
  • 1
    Unfortunately I don't know of one. – tsc_chazz Mar 11 '21 at 23:01