Process in rc.local does not seem to run -- where to see?

ubuntu startup-scripts rc.local

5,916

Solution 1

Redirect the output of your script to a file in rc.local e.g.

/path/to/yourscript >/tmp/script.out 2>&1

which should capture the stdout and stderr from yourscript.

Solution 2

In order to log all the output to a file, i.e., add the following to all your commands in rc.local:

>> /var/log/rc.local.log 2>&1

This will collect both stdout and stderr to /var/log/rc.local.log

then you should be able to know what happened.

5,916

Tom Harrison Jr

Make it work, make it beautiful, make it fast. We tend to skip the last two even if we somehow achieve the first. Corollary: Code first, optimize later. (a.k.a Premature optimization). What's built in here is this: please write code you can observe, measure and test as it works. We are all sure of the things that are slow, optimal, and want to try the stuff that is new and cool. But in real life, which is to say in real software, and as time passes these "rules" change. Don't take some dictum, some claim, or some rule of thumb to be the truth. Instead, code in the simplest, most obvious, most readable way first: get it to work, first and foremost. Simplicity is king. But make sure you can know (or learn) the difference between simple and simplistic. Simplicity is bad when it is simplistic -- simplicity is a virtue, being overly simple (simplistic) is bad, and evidence of intellectual laziness. You need to write code that measures itself. Good code is inherently introspective. Rails exemplifies this, with built-in timings of major phases. You're not a bad person if your first few passes at coding turn out to be over-simplifications of a problem (on the contrary: try to simplify!). But when you find your model of the requirement is less than needed, keep looking for a way to make it simple. Simple is not slow, bad, or dumb: simple is artful. You'll find that a joy of software development in the modern age is that things that are known to be slow (databases, interpreted languages, IO, etc.) are often not the bottleneck. In real code, it's usually just code that does what it needs in a silly way that makes for badness. If you can measure timings, and profile your code, you can find and fix what needs fixing, and leave the perfectly simple and elegant code alone. It's funny, for all of the beautiful code and optimized code I have seen, it's usually the beautiful code that performs best. There's something about truly understanding the problem that is necessary to make code beautiful -- it's surprising and wonderful that this depth of understanding tends to coincide with, hence obviate the need for optimization. But sometimes, beautiful code doesn't perform. And then, you may need to optimize. Look for the simplest and most obvious optimizations first -- a missing index, a repeated query or method, a thing that is expensive to do that is requested often is a candidate for caching. Don't cache unless you see you need it. Don't thread unless you need it. Don't denormalize data unless you must. Don't build fancy subsystems because it seems evident that they will be needed to scale. And above all: don't be lazy (even if that's the fastest way to get it to work). Complexity is the enemy. Simplicity is the art of making something complex look easy. Software engineering is art. Make it work, make it beautiful, make it fast.

Updated on September 18, 2022

Comments

Tom Harrison Jr almost 2 years
I want to run a process in rc.local (Ubuntu Natty) but I am having trouble determining if it has run. I added
```
/bin/sleep 10
/usr/bin/killall PassengerWatchdog
/bin/echo "Killall returned with code $?"
```
The file has the execute bit set. The script starts with #!/bin/sh I would expect the echo to go to /var/log/boot.log

This is obviously just a hack to see if I can fix a problem. How can I tell if the script executed?