Re: itp: static bins / resolving static debian issues
Justin Wells <jread@semiotek.com> writes:
> On Mon, Aug 23, 1999 at 10:51:07PM -0500, Steve Greenland wrote:
>
> > No, Craig continues to point out that statements like "Such-and-so is
> > required to use Debian as a stable server system" are opinions, not
> > technical arguments, without technical merit.
>
> It is certainly not just an opinion.
I can run a Debian system completly without static bins, I can run
Debian without bash. Its all about opinions.
People trust that on a normal Linux bash will be available (that a
general opinion), so debian will come with bash installed normaly.
On the other side, dynamic or static linking absolutely depends on the
taste of the admin. I like dynamic linking and it saved me several
times so far. Again thats an opinion. But if Debian eliminates that
opinion, that will be a bug. If you like static binaries, build static
packages to go along with the dynamic ones. You might even build a
static-base.tgz if you wish.
As to your arguments, I can use the same for dynamic binaries.
Proposition #1, 2 and 3:
Does static linking make downtime cheaper or tolerable?
> Proposition #4-- Failure of the C library can occur under Debian
Sure, but does static linking prevent that? No it doesn´t.
As soon as a new libc is released, the autobuild demons will compile
it and all static linked binaries and upload them. You type "apt-get
install upgrade" and then you have them all installed and your system
goes down.
Also static linking doesn´t prevent dpkg to remove some essential
package,s ay sash for example. If you can proof otherwise, everyone in
the world will swictch to static linking. And how does static linking
make a "rm -rf /" any less fatal?
>...
> Proof: A disk error can corrupt some files but not others, such
> as by duplicating inodes. The C library may be affected
> while leaving much of the rest of the system intact.
Do you agree that the likelyhood of a diskerror increases with the
number of blocks (on a given medium)? So reducing the number of blocks
used does decrease the risk. So dynamic linking is safer. Sure, the
diskerror might occur in the libc and thus damage the whole system,
instead of just harming some non essential program. But by doubling or
tripling the size of the essential tools you double or tripple the
risk of such an error occuring at all.
Now conside the case of a broken libc and dynamic/static linking:
static linking:
You have a broken system with 50+ broken binaries which you
must replace from the rescuedisk, extract from the base or
from an old deb file. You probably won´t find an old .deb
file on the server anymore and you might have to recompile a
lot of packages after bugfixing the libc.
dynamic linking:
You have a broken system just as well, but only one broken
lib. Copying that from the rescuedisk is easy. You can just as
well allways keep a backup of a working libc on the harddrive
and copy that back into the system.
> Proposition #5-- Most servers will survive a C library failure
> if the server is already running
Most servers will survive the installation of a broken static binary
just as well as broken dynamic lib.
Proof: The server is alread running.
> Proposition #6-- If a failure of the C library occurs, and the
> servers are still running, then on a system where
> downtime is considered unacceptable or difficult, you
> should fix the problem without a reboot if that is
> possible
Same with broken static binaries. What if cp is broken?
> Proposition #9-- Statics recovery tools are more fault tolerant
> than dynamics equivalents
>
> Proof: Dynamics typically depend on a large number of files, and
> the failure of any of those files will bring the dynamic
> binary down. For example, bash depends on:
> -- bash, libncurses.so.4 (symlink), libncurses.so.4.2,
> libdl.so.2 (symlink), libdl.so.2.1.2, libc.so.6
> (symlink), libc-2.1.2.so, ld-linux.so.2, and
> until recently on libreadline as well (2 files)
> whereas sash depends on only one file (sash). Thus there
> are eight (previously 10) files upon which bash depends,
> but only one on which sash depends.
But both the dynamic and static binary depend on exactly the same
source and if thats broekn the bin is broken, no matter if its staic
or dynamically linked. You gain or loose nothing. The chance that
dynamic linking fails but static not is 0.
The only benefit you get from static bins is that all bins are rebuild
with each lib update and unresolved symbols will be detected
automatically.
> Proposition #12-- The presence of static recovery tools will
> not pose any difficulties to ordinary use of the system
You can´t boot any longer on lowmem systems. I think thats a
difficulty.
> ------------------------------------
> Conclusion: Debian should provide static binaries
Yes, as an option. Go ahead and patch the packages to build static
versions as well. I won´t use them for the one i a million chance
where it could help but you may if you want.
> > Not only that, they are
> > opinions that many of us do not agree with based on our experience with
> > *using* Debian as a stable production server.
>
> I think I've more or less dealt with this above; though if you are
> going to state your experience, I may as well state mine: statics
> have been required to fix Debian systems a few times (and a couple
> times required a reboot since I didn't have them installed--I just
> expected they would be there already!). These were desktop machines,
> but no matter--the experience of needing statics was the same.
Did you have a set of rescue bins and libs installed in a seperate
directory or did you use a chroot enviroment to test first? No, than
its your own carelesness.
> The truth is I still don't know whether reliability and stability
> are important issues here, since several people have bluntly told
> me that live recovery is not what 99% of Debian users need and
> therefore I should go away.
They didn´t tell you to go away, they said leef us alone. Go ahead,
leef them alone, leef them experience your problems, make static bins
an option and wait for them to convert to them and thank you. Maybe
they do, maybe they don´t. Time will tell.
> > Neither Craig nor anyone
> > else that I've noticed has objected to you making optional packages to
> > do whatever you want.
>
> However I have repeadely produced arguments that this is not adequate.
> All that has been said in response to those arguments is a series of
> statements of opinions, and sometimes flames.
Dynamic bins are neccessary on lowmem systems and are far better on
normal system. Whether static bins help on high availability systems
is the admins decision.
> #1 -- People who are running important servers often don't know
> that statics are important (we live in such a world; even
> when that level of experience is present it's frequently
> junior people who do installations)
Then write adequate documentation. Change dinstall to query what type
the user wants or make those packages the default for server configs.
> #2 -- The debian policy states that anything an experienced Unix
> person expects should be provided by default, and it has
> been said on this list by others several times that it's
> obvious many experienced Unix admins expect to be able
> to recover from a failure of the C library
Any bugs in any library will also show up in the static bins, so you
gain nothing by static linking. Any update to a broken lib will also
install broken static bins.
> So there is a two pronged argument against your position:
>
> First, and especially since the cost is so low, it is wise to
> include the tools that an admin will need to recover from failure
> by default, because many such admins are effectively learning as
> they go, and when the server fails, it is too late for them to
> learn that statics were important.
>
> Second, your position is in violation of debian policy.
A rescue disk is provided, more is not needed. Maybe more is possible,
bot not required.
> > The only benefit you've shown for static binaries is for use on remotely
> > administered systems, where the admin has neither physical access nor
> > the someone on site to follow simple instructions like "put the CD
> > labeled 'Emergency use only' in the tray and hit Ctrl-Alt-Del.", and for
> > those situations where /lib is damaged but /bin isn't. I certainly don't
Why should that ever happen? Is it more likely for dpkg to remove libc
than sash? Is /bin save from errors more than /lib is? Remember, when
you use static binaries you will have /lib in /bin several
times.
> > deny those cases exist, but I strongly doubt they are even a significant
> > minority of Debian's user base. Yes, we should accomodate those needs,
> > but I see little reason to inflict it on everybody.
>
> That is not the only benefit I've shown. That's only one very large
> class of servers (downtime is a logistic difficulty for various
> reasons); there is also the additional class of servers where
> downtime is considered unacceptable (eg: NFS).
Downtime of an NFS server is hardly any problem. If you get it up
withing 15 minutes it just starts working again. No problem there even
with root-NFS. I tested that several times so far.
>...
> Maybe the problem is that I didn't make this clear enough--I think
> that a static root shell is extremely important, and will not run
> Debian as a production server until it's available by default (or
> someone convinces me why I don't need it).
It will probably never be available by default. Its normaly not needed
and its not usual. But the option is there, use it at your will.
------------------------
Conclusion:
Static bins yes, but purely as an option.
May the Source be with you.
Goswin
Reply to: