FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-21-2010, 07:14 PM
Kurt Roeckx
 
Default Parallel booting enabled by default

On Fri, May 21, 2010 at 02:05:26PM +0200, Petter Reinholdtsen wrote:
> * Shutdown speed can be improved by removing scripts which only kill
> their daemon from /etc/rc[06].d/ and leaving it to the sendsigs
> script to kill all of them at the same time instead.

And they should probably also be removed from /etc/rc1.d/ in that
case because it also uses sendsigs. Lintian warns about this
as far as I know.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100521191423.GA8698@roeckx.be">http://lists.debian.org/20100521191423.GA8698@roeckx.be
 
Old 05-21-2010, 07:42 PM
Petter Reinholdtsen
 
Default Parallel booting enabled by default

[Kurt Roeckx]
> And they should probably also be removed from /etc/rc1.d/ in that
> case because it also uses sendsigs. Lintian warns about this as far
> as I know.

Perhaps. I am not quite sure how that will interact with runlevel
switching to and from runlevel 1. I am sure it is safe for runlevels
0 and 6, as it is not possible to switch away from those and back to
runlevels 1-5. It is important to make sure services are restarted

We want to make sure services stopped when switching to runlevel 1 are
started when switching back to runlevel 2.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2flhbm12g99.fsf@login1.uio.no">http://lists.debian.org/2flhbm12g99.fsf@login1.uio.no
 
Old 05-24-2010, 08:33 AM
Kurt Roeckx
 
Default Parallel booting enabled by default

On Fri, May 21, 2010 at 09:42:42PM +0200, Petter Reinholdtsen wrote:
>
> [Kurt Roeckx]
> > And they should probably also be removed from /etc/rc1.d/ in that
> > case because it also uses sendsigs. Lintian warns about this as far
> > as I know.
>
> Perhaps. I am not quite sure how that will interact with runlevel
> switching to and from runlevel 1. I am sure it is safe for runlevels
> 0 and 6, as it is not possible to switch away from those and back to
> runlevels 1-5. It is important to make sure services are restarted
>
> We want to make sure services stopped when switching to runlevel 1 are
> started when switching back to runlevel 2.

I don't see why you think that would be a problem. Either the
init script in runlevel 1 is going to stop the service, or it
gets killed. And going back to runlevel 2 should start the same
services as started otherwise in that runlevel.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100524083359.GA13758@roeckx.be">http://lists.debian.org/20100524083359.GA13758@roeckx.be
 
Old 05-24-2010, 12:58 PM
Petter Reinholdtsen
 
Default Parallel booting enabled by default

[Kurt Roeckx]
> I don't see why you think that would be a problem. Either the
> init script in runlevel 1 is going to stop the service, or it
> gets killed. And going back to runlevel 2 should start the same
> services as started otherwise in that runlevel.

The reason is that I remember some bugs with packages related to
runlevel 1, and I did not remember the details.

Now I have had time to test a bit, and believe I remember the details.
The problem is with packages starting in runlevels 1-5 and starting a
daemon that is killed by killprocs. Such setup is broken, as the
daemon will not be started again when switching away from runlevel 1
to runlevels 2-5.

I tested switching from runlevel 2 to 1 using

debug=echo PREVLEVEL=2 /etc/init.d/rc 1 | grep -v splash

I also tested with scripts missing in runlevel 1, and they are started
when switching from runlevel 1 to runlevel 2.

This is most interesting for scripts that need to run once at boot.
For scripts that do nnot need to run when booting into single user
mode (and thus should not start in rcS.d/), this setting would be most
correct:

# Default-Start: 2 3 4 5
# Default-Stop:

Runlevel 1 should be equivalent to single user, so there is no need to
start in runlevel 1, and there is no need to stop either

For scripts that start a daemon and need to do some cleanup when
stopping it, this setting would be most correct

# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6

Not sure if I managed to write this in a clear matter. I find it a
bit hard at the moment to wrap my head around all the possibilities.
There are at least the following set of transitions to consider:

rcS.d -> single user mode -> rc[2-5].d
rcS.d -> rc1.d -> single user mode -> rc[2-5].d
rcS.d -> rc1.d -> single user mode -> rc[06].d

rc[2-5].d -> rc1.d -> single user mode -> rc[2-5].d
rc[2-5].d -> rc1.d -> single user mode -> rc[06].d

Note that single user mode is not the same as runlevel 1. Runlevel 1
is just one of two ways to end up in single user mode. The other way
is booting with 's' or 'single' as a kernel argument. Also note that
rcS.d/ is not the single user runlevel (it is not used when switching
to single user after boot), and is more accurately called rc.boot in
other distributions.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2fl1vd1zca9.fsf@login1.uio.no">http://lists.debian.org/2fl1vd1zca9.fsf@login1.uio.no
 
Old 05-24-2010, 06:01 PM
Kurt Roeckx
 
Default Parallel booting enabled by default

On Mon, May 24, 2010 at 02:58:54PM +0200, Petter Reinholdtsen wrote:
>
> [Kurt Roeckx]
> > I don't see why you think that would be a problem. Either the
> > init script in runlevel 1 is going to stop the service, or it
> > gets killed. And going back to runlevel 2 should start the same
> > services as started otherwise in that runlevel.
>
> The reason is that I remember some bugs with packages related to
> runlevel 1, and I did not remember the details.
>
> Now I have had time to test a bit, and believe I remember the details.
> The problem is with packages starting in runlevels 1-5 and starting a
> daemon that is killed by killprocs. Such setup is broken, as the
> daemon will not be started again when switching away from runlevel 1
> to runlevels 2-5.

I think we're discussing 2 things here, while I was only thinking
about one of them:
- Move scripts from rcS.d to rc[1-5].d
- Removing rc[016].d/K* scripts

As far as I know, the only daemon we currently start in rcS.d
(that keeps running) is udev. udev might be something we
want to run in single user mode too, so it might make
sense to also start it in runlevel 1. killprocs is
probably going to kill it, so it would need to be restarted
after that. I think it's going to be hard to move
udev away from rcS.d, and I don't see the point.

It could make sense to move things from rcS.d to rc[1-5].d,
but for daemons it doesn't make sense to start in 1-5,
it should probably always be 2-5.

But my question was when it makes sense to stop a daemon in
runlevel 1 via the init script when you don't do it for
0 and 6. killprocs is going to stop it for runlevel 1
anyway, just like sendsigs does it for runlevel 0 and 6.

I still don't get why you think something might not be
started when going from 1 to 2-5.

> For scripts that do nnot need to run when booting into single user
> mode (and thus should not start in rcS.d/), this setting would be most
> correct:
>
> # Default-Start: 2 3 4 5
> # Default-Stop:
>
> Runlevel 1 should be equivalent to single user, so there is no need to
> start in runlevel 1, and there is no need to stop either
>
> For scripts that start a daemon and need to do some cleanup when
> stopping it, this setting would be most correct
>
> # Default-Start: 2 3 4 5
> # Default-Stop: 0 1 6

Which was kind of my point.

This doesn't make sense (for a daemon):
# Default-Start: 2 3 4 5
# Default-Stop: 1

So I'm trying to think of examples where a script that doesn't stop
a daemon might be useful to run when going to runlevel 1, but not
to 0 or 6. I guess you can probably come up with something.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100524180105.GA7499@roeckx.be">http://lists.debian.org/20100524180105.GA7499@roeckx.be
 
Old 05-24-2010, 06:34 PM
Petter Reinholdtsen
 
Default Parallel booting enabled by default

[Kurt Roeckx]
> I think we're discussing 2 things here, while I was only thinking
> about one of them:
> - Move scripts from rcS.d to rc[1-5].d
> - Removing rc[016].d/K* scripts

Could be.

> As far as I know, the only daemon we currently start in rcS.d
> (that keeps running) is udev.

There are more of them. I'm aware of portmap and some NFS related
daemons. I believe most of of them should be moved from rcS.d/ to
rc[2-5].d/, along with networking and several others.

> udev might be something we want to run in single user mode too, so
> it might make sense to also start it in runlevel 1.

I do not believe it is needed to add start symlinks in rc1.d/ for udev
as long as it isn't killed by killprocs. Not sure what the current
status is there. Both runlevel 1 and single user mode in Debian is so
broken it is hard to know where to start to make them work properly.
At the moment the only safe and sane thing to do after working in
single user mode is to reboot to recover.

> killprocs is probably going to kill it, so it would need to be
> restarted after that.

If killprocs kills it in rc1.d/, udev can not have a start symlink in
rc1.d/, as this will cause init.d/rc to not start udev when switching
from runlevel 1 to runlevel 2.

> I think it's going to be hard to move udev away from rcS.d, and I
> don't see the point.

I agree.

> It could make sense to move things from rcS.d to rc[1-5].d, but for
> daemons it doesn't make sense to start in 1-5, it should probably
> always be 2-5.

If you keep udev out of this, I agree.

> But my question was when it makes sense to stop a daemon in runlevel
> 1 via the init script when you don't do it for 0 and 6. killprocs
> is going to stop it for runlevel 1 anyway, just like sendsigs does
> it for runlevel 0 and 6.
>
> I still don't get why you think something might not be
> started when going from 1 to 2-5.

I tried to explain in my previous email, that there probably is no
such case. Either the daemon need special code to stop, and it need
to have stop symlinks in runlevels 0, 1 and 6, or it do not, and do
not need stop symlinks in any of runlevels 0, 1 and 6.

Now I believe the problem I remembered was with start symlinks in
runlevel 1, which can be problematic as the daemon will be killed by
killprocs and not start again when switching from runlevel 1 to
runlevel 2.

> This doesn't make sense (for a daemon):
> # Default-Start: 2 3 4 5
> # Default-Stop: 1
>
> So I'm trying to think of examples where a script that doesn't stop
> a daemon might be useful to run when going to runlevel 1, but not to
> 0 or 6. I guess you can probably come up with something.

I suspect you are right, that such setup do not make sense.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2flaarpxi63.fsf@login1.uio.no">http://lists.debian.org/2flaarpxi63.fsf@login1.uio.no
 

Thread Tools




All times are GMT. The time now is 09:19 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org