5 ms·

Hot patching is dangerous in all execution environments. This is software engineering... Separate your dev environment from production and do a controlled depl

by pnut 6y ago

Hot patching is dangerous in all execution environments. This is software engineering... Separate your dev environment from production and do a controlled deployment.

arthurcolle 6y ago
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.
- spicyramen 6y ago
  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
- Cthulhu_ 6y ago
  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.
kleiba 6y ago
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.
rkangel 6y ago
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.
- clort 6y ago
  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?
- glandium 6y ago
  > 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.
- downerending 6y ago
  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.
- toast0 6y ago
  > 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)
FlyingAvatar 6y ago
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.
rurban 6y ago
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.
jldugger 6y ago
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?

by pnut 6y ago

Hot patching is dangerous in all execution environments. This is software engineering... Separate your dev environment from production and do a controlled deployment.

arthurcolle 6y ago

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.

spicyramen 6y ago
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
Cthulhu_ 6y ago
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.

kleiba 6y ago

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.

rkangel 6y ago

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.

clort 6y ago
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?
glandium 6y ago
> 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.
downerending 6y ago
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.
toast0 6y ago
> 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)

FlyingAvatar 6y ago

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.

rurban 6y ago

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.

jldugger 6y ago

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?