Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Nov 1995 17:10:33 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        chuckr@Glue.umd.edu, davidg@Root.COM
Cc:        current@freebsd.org, scrappy@hub.org
Subject:   Re: follow-up to kernel compile problem...
Message-ID:  <199511260610.RAA18250@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>>    It's not necessary to shut down to single user. It is a good idea if you do
>>> the 'make world' when the system is mostly idle, however, as unusual transient
>>> things might happen to the users during some phases of the build.
>>
>>Please, could you explain this?  How come, if I'm changing my libc, I 
>>don't have to go to single user?  I know when I did current on version 
>>1.1 it was needed, I believe you now, but I like to know why, what changed?

>   Anything that is currently using the installed libraries will continue to
>use the old version. The old libraries are unlinked before the new copy is
>installed. I think back in 1.x days that install didn't do an unlink first,
>causing it to overwrite the in-use libraries.

Actually, install always did an unlink, and installing new libraries is
only fairly safe.  The following may occur:

	install unlinks old library
		Now there is no library, so if install gets preempted
		and something gets execed, the something may fail with
		an ENOENT error.
	install starts copying new library.
		Now there is a partial library, so if install gets
		preempted and something gets execed, the something may
		find a partial library and fail with a who-knows-what
		error.
	install finishes copying new library.
		Now the rwx------ permissions may be too restrictive,
		so if installed gets prempted and something gets execed,
		the something may fail with an EACCES error.  This also
		limits the damage for partial libraries to processes
		that can read the library.
	install finishes installing new library.
		Now there are no problems.

Installing with new -C flag is much safer.  (-C is in -current but not
in 2.1).  An atomic rename() is used instead of the unlink/copy, so
there are only races for the permissions and the immutable flags.  The
permissions problems should be fixed by doing the fchown/fchmod before
the rename().  The immutability problems can't be fixed - you have to
turn off the immutable flags to do the rename(), so there must be a
window where the target is mutable.  There should be an atomic
rename_immutable() syscall to handle this problem.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511260610.RAA18250>