Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

A question came up on SO 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:

  1. Bad. Bad. Bad. Never do this.
  2. Not a recommended practice.
  3. OK, with caveats.
  4. Legacy dogma.
  5. Totally fine.

It would be great to know any nightmare scenarios, or if this rule is written in some sysadmin's blood.

share|improve this question

4 Answers 4

up vote 8 down vote accepted

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.

share|improve this answer
1  
I'm going with this answer. The point is that Python isn't necessary and isn't standard, and as such it can create an extra point of debugging uncertainty and extra point of failure. In reference to the original SO question, I gather that such scripts can launch daemons, but they shouldn't be the actual daemons. –  mjhm Nov 11 '10 at 4:02

I don't see a problem with it, if you know, for sure, that the Python interpreter will be available when the init.d script is being run. This, to me, indicates that you're looking at something being done relatively late in a multi-user (or "graphic console") run-level.

However... This means that a specific version of the Python interpreter MAY be vital for your boot sequence and this is one more thng you need to check at upgrades.

I guess this means I'm saying "3. OK, with caveats".

share|improve this answer
4  
+1. Exactly what I was writing. The only "problems" here would be making sure you conform to LSB, (e.g. providing necessary functions) and making sure the python interpreter you need is available at runtime (and not broken.) –  Sam Halicke Nov 10 '10 at 17:48
3  
Available at runtime may be complicated if the user has elected to have /usr on a separate partition. It will be important that your script run after /usr is mounted since python is typically installed in /usr. –  Zoredache Nov 10 '10 at 17:50
    
@Zoredache - Ayup. Typically, you know that "has happened" when you're late in the "multi-user" RC sequence. –  Vatine Nov 12 '10 at 13:48

I agree with "3. OK, with caveats," but for different reasons. My experience on Solaris was that they had an OS copy of Perl for some of their internal programs. The shell script was nothing more than the shell to get the Perl to kick off. Did the startup script have to be written in sh? No, but it improved maintainability for the administrator. And the init script did nothing more complicated that stuff like daemon --start or daemon --stop. If you did this, then regular users could start your tool in unprivileged mode, if that makes sense in the context of your program. And they wouldn't need to have all sorts of complicated settings to finesse.

Modern Linux distributions, even those still using init.d, have a large collection of pre-built functions meant to make it easy to manage daemons. Graphical boot processes routinely leverage those functions to keep the pretty logo up unless one of the startup scripts begins spewing errors. Your Python code (or any other language) may not play well with those schemes.

If you don't care about aesthetics or maintainability, your init script can be written however you want. I've seen lots of admins, who can't even cut and paste properly, completely ignore command line arguments and they just start the daemon. No shutdown, status, or restart. It was immature, but their code still ran.

share|improve this answer

I say between #1-2. The LSB directs you this way.. and from a Sys-Admin (non dev role) the job req's dictate sh/bash knowledge, NOT dev-level (or even light understanding) of python, PHP or perl. That's for the LAMP stack, not for the system init scripts.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.