Conversation
When stdin links to /dev/null, which is the case for systemd service units, select() returns immediately. That causes the loop to endlessly read() 0 bytes and eats up 100% of a processor core. isatty() checks if railcontrol has a "real" stdin available. If that is not the case, do not select() and read() stdin but use the 1s delay as for silent mode.
|
Thanks! I think I also ran into this yesterday in doing testing.
I was going to look at writing a systemd service unit in the context of #19 but it sounds like you already have one. Would you mind sharing it? And from your icon I'm guessing you're looking at packaging for Debian so #24 may also interest you. |
You may also be interested in the workaround for #22 by setting WorkingDirectory= for the service to the directory that stores the database. If you wonder why railcontrol gets restarted on regular exit code, you'll find my rationale in line 29 following in https://salsa.debian.org/fuddl/railcontrol/-/blob/76a19aea37da5d54b7cdeab92ac3510482b20789/debian/README.Debian :)
What I'm looking forward to is using cmake and I'm glad Teddy has already merged your efforts on that topic 👍 |
Oh, good tip! I can take a look because I've also been running into this with testing. |
3 participants
When stdin links to /dev/null, which is the case for systemd service units, select() returns immediately. That causes the loop to endlessly read() 0 bytes and eats up 100% of a processor core.
isatty() checks if railcontrol has a "real" stdin available. If that is not the case, do not select() and read() stdin but use the 1s delay as for silent mode and avoid spinning at 100%.