A question came up on StackOverflow asking about writing init.d scripts in Python. One comment indicated that these scripts should be programmed in shell, not Python. Is writing init.d scripts in Python:
- Bad. Bad. Bad. Never do this.
- Not a recommended practice.
- OK, with caveats.
- Legacy dogma.
- Totally fine.
It would be great to know any nightmare scenarios, or if this rule is written in some sysadmin's blood.
Best Answer
I'd say #2, but very close to #1 -- "Bad. Bad. Bad. Never do this." The standard, such as it is, for Linux init scripts is in the LSB, and while it never comes out and says "these are bourne shell scripts", several assumptions are made. One, that lines beginning with # are comments, happens to work out fine. More problematic is the requirement that the init script execute the commands from
/lib/lsb/init-functions"in the current environment (see shell special built-in command dot)".But more importantly, if you're doing anything really complicated here, you're doing it wrong. The init scripts should be very simple and utilitarian. They should be scripts in the classic sense, not programs. It's better to suck it up and make a simple shell script that any sysadmin can easily grok in one quick look than to make something beautiful and engineered in Python.
Another consideration to keep in mind is
systemd, which may or may not be the Future Of All System Initialization On Linux. Under systemd, initialization is done by simple configuration files rather than scripts, the idea being that all startup fits into several standard design patterns and really you should just have to pick one. If you program uses something complicated for initialization, that should go outside of the init script itself.