Fail to start while using socket-activated mode

[KazamaSion]

System: Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux
systemd ver: 241 (241)

By using udptunnel-(client|server).(service|socket) with nearly its original version, I tried to start udptunnel-(client|server).socket.

• The systmed files of client and server are on different VMs.
• The only change I did is deleting the line ListenStream=[::]:443.

At this time, the status was ok. They were active.

Then, I executed the command mtr -T 127.0.0.1 -P 443 on the server VM, and I executed the journalctl -xe after then. I paste the critical log here:

-- Automatic restarting of the unit udptunnel-server.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
systemd[1]: Stopped udptunnel server.
-- Subject: Unit udptunnel-server.service has finished shutting down
-- Defined-By: systemd
-- 
-- Unit udptunnel-server.service has finished shutting down.
systemd[1]: Failed to set devices.allow on /system.slice/udptunnel-server.service: Operation not permitted
systemd[1]: Failed to set devices.allow on /system.slice/udptunnel-server.service: Operation not permitted
systemd[1]: Starting udptunnel server...
-- Subject: Unit udptunnel-server.service has begun start-up
-- Defined-By: systemd

-- Unit udptunnel-server.service has begun starting up.
udptunnel[29419]: Expected 2 argument(s)!
udptunnel[29419]: Usage: udptunnel [OPTION]... [[SOURCE:]PORT] DESTINATION:PORT
udptunnel[29419]: -s    --server         listen for TCP connections
udptunnel[29419]: -i    --inetd          expect to be started by inetd
......
udptunnel[29419]: SOURCE:PORT must not be specified when using inetd or socket activation.
udptunnel[29419]: If the -s option is used then the program will listen on SOURCE:PORT for TCP
udptunnel[29419]: connections and relay the encapsulated packets with UDP to DESTINATION:PORT.
udptunnel[29419]: Otherwise it will listen on SOURCE:PORT for UDP packets and encapsulate
udptunnel[29419]: them in a TCP connection to DESTINATION:PORT.
systemd[1]: udptunnel-server.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
systemd[1]: udptunnel-server.service: Failed with result 'exit-code'.
systemd[1]: Failed to start udptunnel server.
-- Subject: Unit udptunnel-server.service has failed
-- Defined-By: systemd


-- Unit udptunnel-server.service has finished shutting down.
systemd[1]: udptunnel-server.service: Start request repeated too quickly.
systemd[1]: udptunnel-server.service: Failed with result 'exit-code'.
systemd[1]: Failed to start udptunnel server.
-- Subject: Unit udptunnel-server.service has failed
-- Defined-By: systemd
-- 
-- Unit udptunnel-server.service has failed.
-- 
-- The result is RESULT.
systemd[1]: udptunnel-server.socket: Failed with result 'service-start-limit-hit'.

The situation for the client VM was nearly the same. I suppose I do not need to duplicate it.

Trying to search what exactly happened for hours but failed.

[20051615]

Same exact situation here: using nearly identical configuration as what is given in /examples and udptunnel (both server and client) fail to start, reporting "expected 2 arguments".

However, giving up on socket-activation altogether and directly using udptunnel [-s] SOURCE:PORT DEST:PORT from commandline will work just fine.

If it helps at all, just assume socket-activation is broken and avoid using it.

[frubi]

The udptunnel provided as package in Debian is a completely different tool. It's using the source from http://www1.cs.columbia.edu/~lennox/udptunnel/