* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [001029 18:54]:
> Maybe some upgrades should just be labelled "reboot recommended"?
It will be a sad day when this happens. :( I think it is a strong
selling point when I tell my MS friends, tired of rebooting after
installing a new web browser, that one can
>
> On this topic, I'm trying to get Oracle working. Since as we all know libc6
> 2.2 is "perfectly compatible" it ought to work :) In reality it doesn't work
> so I'm trying to get it to use the old libc6. Someone on this list claimed you
> could have the two installed simultaneously but it doesn
On Sun, Oct 29, 2000 at 09:56:22PM -0500, [EMAIL PROTECTED] wrote:
> On Sun, Oct 29, 2000 at 09:04:54PM -0500, Ben Collins wrote:
>
> qmail(-src) can be added to the list too. Somehow it kept sucking
> up disk space that I could not find. Kill and restart freed
> and fixed that.
>
> I don't kno
Ben Collins <[EMAIL PROTECTED]> writes:
> > We need to find a way to not require the restarts. Perhaps the nss modules
> > could provide the old nss functions as versioned 2.0 symbols?
> >
> > (Sigh, this would all go away if people just bumped sonames when they had
> > to.)
>
> This isn't a
On Sun, Oct 29, 2000 at 09:04:54PM -0500, Ben Collins wrote:
qmail(-src) can be added to the list too. Somehow it kept sucking
up disk space that I could not find. Kill and restart freed
and fixed that.
I don't know a lot about shared libs. My understanding is that
as long as something is usin
On Sun, Oct 29, 2000 at 07:27:23PM -0500, Greg Stark wrote:
>
> Chris Waters <[EMAIL PROTECTED]> writes:
>
> > On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
> >
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here
Chris Waters <[EMAIL PROTECTED]> writes:
> On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
>
> > Ok, I'm tired of having to track all services that might need to be
> > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > to require all packages that need thi
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need this to declare a new reply in it's init
> > > script. It's very simple, I check your init script like thi
> >
> > E.g.:
> > objdump -T $( readlink -f /proc/$PID/exe ) | egrep 'symbol1|symbol2'
> >
> > The processes to restart could be taken from ps AND /etc/init.d/*.
>
> How would it know that it is a service as opposed to a running "ls" or
> cronjob? How would it know how to restart simple ex
On Wed, Oct 18, 2000 at 01:21:06PM -0700, [EMAIL PROTECTED] wrote:
> >
> > > we haven't a script to find out whether a daemon is running yet, but
> > > we should introduce one and fixate this in the policy).
> >
> > Yes, this would seem to be the only sane approach. (Other than
> > discarding fi
On Tue, 17 Oct 2000, Chris Waters wrote:
> On Tue, Oct 17, 2000 at 12:31:18PM +0200, Roland Rosenfeld wrote:
> > On Mon, 16 Oct 2000, Chris Waters wrote:
>
> > > set $(runlevel) # $2 is now current runlevel
> > > name=service
> > > rcfile=/etc/rc$2.d/S??$name
>
> > > test -f $rcfile &
On Tue, 17 Oct 2000 at 12:54, Chris Waters wrote about "Re: All services...":
> > IMHO libc should handle its various incompatibilies itself, because
> > its a problem in libc, not in the daemon packages.
>
> I almost agree with you, but I think that trying to get libc to track
> all the packages
On Tue, 17 Oct 2000 at 12:29, Chris Waters wrote about "Re: All services...":
> it. The init.d scripts are for starting and stopping daemons, not for
> reporting on their linkage. Note that I didn't say "smaller", I said,
> "cleaner" and "less confusing".
Excuse me if I don't understand things
On Tue, 17 Oct 2000, Roland Rosenfeld wrote:
> daemon is running yet, but we should introduce one and fixate this in
> the policy).
I'm on it. The code is ready and tested (for rc?.d, but I'll code the
file-rc version if the thing is accepted -- and it WAS designed to work with
whatever rc scheme
On Tue, Oct 17, 2000 at 12:31:18PM +0200, Roland Rosenfeld wrote:
> On Mon, 16 Oct 2000, Chris Waters wrote:
> > set $(runlevel) # $2 is now current runlevel
> > name=service
> > rcfile=/etc/rc$2.d/S??$name
> > test -f $rcfile && $rcfile restart
> > Simple, cleaner, more elegant, more o
On Mon, Oct 16, 2000 at 08:09:24PM -0400, Ben Collins wrote:
> > Gooping up poor innocent init.d scripts, and confusing our poor
> > innocent users, is a Bad Idea(tm). A separate set of scripts in a
> > separate directory, or possibly a list managed with some simple perl
> > tools, is much cleaner
On Tue, 17 Oct 2000 at 11:20, Colin Watson wrote about "Re: All services...":
> around anyway. When people are upgrading from potato to (stable) woody,
> libc6 will often need to know what services to restart before the new init
> scripts are unpacked.
potato -> woody will be an issue because the
On 17 Oct 2000 at 06:36, Itai Zukerman wrote about "Re: All services that...":
> Why should we assume that only daemons from Debian packages will need
> to be restarted?
We're not. But we can't be expected to know about them as well. (not to
mention interacting with them!)
--
Brock Rozen
>
> IMHO libc should handle its various incompatibilies itself, because
> its a problem in libc, not in the daemon packages.
>
Then most packages will not be restarted and things will continue to be
broken. Libc6 cannot be expected to know about all of these daemons, nor
will it. The list will a
On Mon, 16 Oct 2000, Chris Waters wrote:
> Then each affected package could have a file in /etc/nss-restart along
> the lines of:
> set $(runlevel) # $2 is now current runlevel
> name=service
> rcfile=/etc/rc$2.d/S??$name
> test -f $rcfile && $rcfile restart
> Simple, cleaner, more ele
> [...]
> When people are upgrading from potato to (stable) woody,
> libc6 will often need to know what services to restart before the new init
> scripts are unpacked.
Again, is there any way to detect which running services need to be
restarted, and then to *warn* the sysadmin that maybe they oug
Anthony Towns wrote:
>On Mon, Oct 16, 2000 at 05:50:09PM -0400, Matt Zimmerman wrote:
>> The checks required to do it this way would probably change between glibc
>> releases. It would be much nicer to have a method that would work forever.
>
>Won't that just mean that the init scripts for variou
On Mon, Oct 16, 2000 at 04:27:49PM -0700, Chris Waters wrote:
> Then each affected package could have a file in /etc/nss-restart along
> the lines of:
>
> set $(runlevel) # $2 is now current runlevel
> name=service
> rcfile=/etc/rc$2.d/S??$name
insert:
rcSfile=/etc/rcS.d/S??$name
> tes
Hi,
Howbout need-libc6-restart (there is a restart already, I think. Even if
not, just restart can be misinterpreted by people using the script.)
Or why not just restart -all- services? I can envision too many little
branches in the code if we add one every time someone doesn't want to
do the le
** On Oct 17, Ben Collins scribbled:
> On Mon, Oct 16, 2000 at 06:39:02PM -0300, Nicol?s Lichtmaier wrote:
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need
> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> Ok, I'm tired of having to track all services that might need
Ben> to be restarted after a libc6 upgrade. So here's what I am
Ben> going to do. I want to require all packages that need this to
Ben> declare a new reply in i
On Mon, Oct 16, 2000 at 08:30:34PM -0400, Ben Collins wrote:
> > Surely there's some other way to work around this, ideally fixing
> > the root cause not having a zillion other packages work around obscure
> > incompatible changes in libc?
> Obviously you don't understand the reason behind this. Wh
On Mon, Oct 16, 2000 at 06:39:02PM -0300, Nicol?s Lichtmaier wrote:
> > Ok, I'm tired of having to track all services that might need to be
> > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > to require all packages that need this to declare a new reply in it's init
> >
On Tue, Oct 17, 2000 at 07:03:48AM +1000, Anthony Towns wrote:
> On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
> > Some daemons can be affected by libc upgrades. This usually
> > happens if the daemon uses functions related to NSS (username,
> > group, hostname and other
On Mon, Oct 16, 2000 at 07:04:44PM -0300, Nicol?s Lichtmaier wrote:
> > > > Ok, I'm tired of having to track all services that might need to be
> > > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > > to require all packages that need this to declare a new reply in i
> Gooping up poor innocent init.d scripts, and confusing our poor
> innocent users, is a Bad Idea(tm). A separate set of scripts in a
> separate directory, or possibly a list managed with some simple perl
> tools, is much cleaner, and much less confusing.
You call 3 extra lines (one if you write
On Mon, Oct 16, 2000 at 07:04:44PM -0300, Nicolás Lichtmaier wrote:
> > > The processes to restart could be taken from ps AND /etc/init.d/*.
> > This only works under Linux (/proc usage).
> Debian does not ship any other kernel...
People are trying to...
--
Jordi Mallach Pérez || [EMAIL PROTEC
On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
> Ok, I'm tired of having to track all services that might need to be
> restarted after a libc6 upgrade. So here's what I am going to do. I want
> to require all packages that need this to declare a new reply in it's init
> script. It's
On Mon, Oct 16, 2000 at 07:04:44PM -0300, Nicolás Lichtmaier wrote:
>
> Debian does not ship any other kernel...
Eh, so what?
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key
[
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need this to declare a new reply in it's init
> > > script. It's very simple, I check your init script like thi
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need this to declare a new reply in it's init
> > > script. It's very simple, I check your init script like thi
On Mon, Oct 16, 2000 at 05:50:09PM -0400, Matt Zimmerman wrote:
> On Mon, Oct 16, 2000 at 06:39:02PM -0300, Nicol?s Lichtmaier wrote:
> > Is it posible to detect if the service needs a restart by examining the
> > executable file?
> > E.g.:
> > objdump -T $( readlink -f /proc/$PID/exe ) | egr
On Mon, Oct 16, 2000 at 06:39:02PM -0300, Nicolás Lichtmaier wrote:
> > Ok, I'm tired of having to track all services that might need to be
> > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > to require all packages that need this to declare a new reply in it's init
> >
On Mon, Oct 16, 2000 at 06:39:02PM -0300, Nicol?s Lichtmaier wrote:
> > Ok, I'm tired of having to track all services that might need to be
> > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > to require all packages that need this to declare a new reply in it's init
>
> Ok, I'm tired of having to track all services that might need to be
> restarted after a libc6 upgrade. So here's what I am going to do. I want
> to require all packages that need this to declare a new reply in it's init
> script. It's very simple, I check your init script like this:
Is it posib
On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
> Some daemons can be affected by libc upgrades. This usually
> happens if the daemon uses functions related to NSS (username,
> group, hostname and other name lookups). Because these functions
> rely on loading mo
Ok, I'm tired of having to track all services that might need to be
restarted after a libc6 upgrade. So here's what I am going to do. I want
to require all packages that need this to declare a new reply in it's init
script. It's very simple, I check your init script like this:
check=$(/etc/in
42 matches
Mail list logo
