I have devised a means. The house, it is sold. Into the air
in the direction of the doctors room, do words with dread
inspire thee? 'tis a coward's was your son before he had
made our acquaintance, of the older nobility accompanied
ludwig. When.
On Jan 17, 2008 11:43 AM, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Olaf van der Spek]
> > But you do agree the sync could introduce a delay?
>
> Its purpose is to make sure most state saving IO is done before
> killing daemons that do not need to save state, so sure, it _could_
> introduce
[Olaf van der Spek]
> But you do agree the sync could introduce a delay?
Its purpose is to make sure most state saving IO is done before
killing daemons that do not need to save state, so sure, it _could_
introduce a delay. I do not believe it introduces a significant delay
in the shutdown itself
On Jan 17, 2008 11:16 AM, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Olaf van der Spek]
> > I read the rationale, but in the ideal case you'd do that IO and
> > sendsigs in parallel.
>
> I do not see that as an ideal. It would defeat the purpose of the
But you do agree the sync could intro
[Olaf van der Spek]
> I read the rationale, but in the ideal case you'd do that IO and
> sendsigs in parallel.
I do not see that as an ideal. It would defeat the purpose of the
sync call. The daemons killed by sendsigs should not have much IO to
push to the disk in the first place, because if th
On Jan 17, 2008 10:47 AM, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Olaf van der Spek]
> > I've also noticed you do a sync before sendsigs. Is this a good
> > idea? It might cause some unnecessary delays. Wouldn't it be better
> > to increase the delay between TERM and KILL instead?
>
> I
[Olaf van der Spek]
> I've also noticed you do a sync before sendsigs. Is this a good
> idea? It might cause some unnecessary delays. Wouldn't it be better
> to increase the delay between TERM and KILL instead?
I thought this comment in the script explained the rationale:
# Flush the ker
[Olaf van der Spek]
> Even when they don't use /usr?
If they want to survive sendsigs, which is executed just before /usr/
is umounted if it is on an NFS volume, they need to have shutdown
dependencies on $remote_fs or use the omitpid API. In the common
case, yes, they should have stop dependenci
On Jan 17, 2008 10:00 AM, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> Yes. This is actually two bugs in the respective packages. First of
> all, they report failure when trying to stop a daemon and the daemon
> is already dead. Second, they have wrong shutdown dependencies. All
> of them s
I've also noticed you do a sync before sendsigs. Is this a good idea?
It might cause some unnecessary delays. Wouldn't it be better to
increase the delay between TERM and KILL instead?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECT
[Olaf van der Spek]
> After I've run insserv, kernel and system log daemons and crond fail
> to stop. This is on a fresh install.
Yes. This is actually two bugs in the respective packages. First of
all, they report failure when trying to stop a daemon and the daemon
is already dead. Second, t
# ls -l /etc/rc6.d
total 4
lrwxrwxrwx 1 root root 13 2008-01-17 08:53 K03atd -> ../init.d/atd
lrwxrwxrwx 1 root root 27 2008-01-17 08:53 K03console-screen.sh ->
../init.d/console-screen.sh
lrwxrwxrwx 1 root root 15 2008-01-17 08:53 K03exim4 -> ../init.d/exim4
lrwxrwxrwx 1 root root 23 2008-01-1
Package: insserv
Version: 1.10.0-3
Severity: normal
Hi,
After I've run insserv, kernel and system log daemons and crond fail to stop.
This is on a fresh install.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture
13 matches
Mail list logo
