Hacker News Reader

Comment by pnut | Hacker News Reader

Hot patching is dangerous in all execution environments.

This is software engineering... Separate your dev environment from production and do a controlled deployment.

Every binary executable on a Linux system can be deleted and replaced while the running program is unaffected. Every Python script can be edited while it's running with no effect.

It comes as a surprise the first time you experience it that this rule doesn't follow with bash scripts.

Well, on unix systems unlinking a file and creating a new one is not the same as modifying the file. If a process has the old file open it will keep that open and remain running with the old file. The new file is a different file.

Is bash closing the file and reopening it, or is the editor writing back to the same filehandle I wonder?

> Every Python script can be edited while it's running with no effect.

Until your script throws an exception, at which point your backtrace will not match the code that was running at all.

It is a surprise, no doubt. On the other hand, bash scripts can contain data and be far larger than available RAM, so just slurping the whole thing up at the start doesn't really work.

That's also true of executables, but bash scrips aren't exec'ed, they are just text files that are read in by the bash executable.

> Every binary executable on a Linux system can be deleted and replaced while the running program is unaffected.

Delete and replace is different than edit in place. I don't know about Linux, but you can edit a binary on FreeBSD which is running, and it affects running copies (it's all memory mapped from the file), and that's why i use install instead of cp to update binaries (including shared libraries)

This advice is sensible if making the assumption that the script is for a production purpose.

If you're writing a shell script for some mundane task on your personal machine, knowing the possible effects of editing a running script is useful knowledge, especially when something might behave in a non-intuitive way.

But this is not hot patching, at least not if I understand correctly: changing 30 to 3 was not meant to have an effect on the running script, it was meant lower the waiting time for next time you're running the script.

This is not an unusual thing to do in other situations. I'm sure you change your code all the time while an instance of the program is running, no matter whether it's compiled or interpreted. At least I don't habitually close a stop program first before I make changes to the source code.

The example in the article shows that that's a bad idea in bash scripts because they, unlike other code, don't get read in entirely (as in, say, Python, Perl, etc.) before they get executed.

Ask yourself for a moment -- how does puppet deploy your bash long running scripts? Is there no risk that a simple, standard, dev/prod separated deploy of your rsync backup script break?

Not in Lisp. In Lisp you always do hot patching, it's a feature.

That's why I get always hit by this shell problem. Happens every other week. There's not even a lock, as I would expect.

I have enough bureaucracy in my life, hard and fast rules like this is what kills actual innovation. Sometimes you just want to run something to get it working. Software engineering isn't religion. At the end of the day the focus should be on feature development, with a slight bias towards decent process.

I agree on the innovation side, but when you have a public service or paying customers, and large Engineering teams you definitely need rules and basic environment separation is not too hard

While true, this assumes you work in a controlled environment, with a pipeline of checks and tests before things go into production; this particular article is about changing a script while it's running somewhere.

Which is probably not a good idea in the first place.

Reply on news.ycombinator.com