Normally [email protected] is a service template. The actual services defined by the template will be something like [email protected], i.e. the part after the @ sign will identify the serial port the service will be applied to.
Without it, the service is meaningless - trying to start it will only result in an error:
# systemctl start [email protected]
Failed to start [email protected]: Unit name [email protected] is missing the instance name.
See system logs and 'systemctl status [email protected]' for details.
I don't see how the [email protected] will be useful at all in this case.
Generally, system services like your transfer.service do not take input from the console.
It would be possible to dedicate a serial port for a particular service and allow it to both input & output through the serial port, but that only really works if the serial port is not used by anything else at the same time. In particular, such a serial port should not be in use as the system console or by any serial-getty@<port name>.service.
So, I'm a bit confused about your setup. Does your MINICOM display currently show a login: prompt on the serial port? If so, do you need it to keep doing that? If the answer is yes, then you cannot use that serial port to handle the input&output of your transfer.service, because you could not control which input would go to your service and which would go to the console prompts. The input would go to whichever process would happen to read it first, and that would be essentially unpredictable.
If the serial port is currently unused (i.e. even if you press Enter a few times in the MINICOM window, you get no output to it), you could connect your service to it by adding:
StandardInput=tty
StandardOutput=tty
TTYPath=/dev/ttyS0 # or whatever is the actual device name for the serial port
to the [Service] section of your transfer.service file. This would start the script immediately after serial ports become available, and would allow anyone accessing the serial port to immediately interact with the script, with no login needed.
If you want your /home/PARTITION/flag.sh script to run interactively when you log in, there are two standard ways to achieve that:
you could add it into your login script (usually ~/.bash_profile or ~/.profile),
or if you want to dedicate a particular user account for running that script and nothing else, you could set the script to be the default shell for that user, with sudo chsh -s /home/PARTITION/flag.sh username. If you do this, the script will be launched immediately as that user logs in, and once it ends, they will be immediately logged out and returned to the login prompt.
