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-11-2010, 10:37 AM
Julian Andres Klode
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
> I am so far just testing on a singe machine, but it's my firm belief
> that it's possible to have a fully functional systemd in squeeze.

Only if #579755 is solved. While testing systemd on Debian, I found
out that the option CONFIG_CGROUP_DEBUG is disabled in our kernel,
but it is needed for systemd to work.

Another problem is that systemd requires libcgroup which has to be
moved to /lib first.

--
Julian Andres Klode - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
 
Old 05-11-2010, 10:49 AM
Julien Cristau
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote:

> On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
> > I am so far just testing on a singe machine, but it's my firm belief
> > that it's possible to have a fully functional systemd in squeeze.
>
> Only if #579755 is solved. While testing systemd on Debian, I found
> out that the option CONFIG_CGROUP_DEBUG is disabled in our kernel,
> but it is needed for systemd to work.
>
config CGROUP_DEBUG
bool "Example debug cgroup subsystem"
depends on CGROUPS
default n
help
This option enables a simple cgroup subsystem that
exports useful debugging information about the cgroups
framework.

Say N if unsure.

Is it really a good idea to have init depend on such an option?
(It's also disabled in all defconfigs.)

Cheers,
Julien
 
Old 05-11-2010, 11:09 AM
Julian Andres Klode
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

On Tue, May 11, 2010 at 12:49:46PM +0200, Julien Cristau wrote:
> On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote:
>
> > On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
> > > I am so far just testing on a singe machine, but it's my firm belief
> > > that it's possible to have a fully functional systemd in squeeze.
> >
> > Only if #579755 is solved. While testing systemd on Debian, I found
> > out that the option CONFIG_CGROUP_DEBUG is disabled in our kernel,
> > but it is needed for systemd to work.
> >
> config CGROUP_DEBUG
> bool "Example debug cgroup subsystem"
> depends on CGROUPS
> default n
> help
> This option enables a simple cgroup subsystem that
> exports useful debugging information about the cgroups
> framework.
>
> Say N if unsure.
>
> Is it really a good idea to have init depend on such an option?
> (It's also disabled in all defconfigs.)

Here's what I heard from Kay Sievers:

Apr 30 16:13:27 <juliank> kay: Is there a way to get it working without this option?
Apr 30 16:13:58 <kay> no, no chance
Apr 30 16:14:18 <kay> it's one of the building blocks to track/babysit processes
Apr 30 16:17:24 <kay> it will not be "debug" some day, but always required, yes
Apr 30 16:17:57 <kay> there is otherwise no way to reliably kill a service, you need a simple "container" to kill
Apr 30 16:18:17 <kay> otherwise processes can fork faster than you can kill them
Apr 30 16:18:38 <kay> cgroups provide a race free way to kill an entire group of processes
Apr 30 16:19:13 <kay> and they can also tell you that all processes of a service died -> empty group
Apr 30 16:20:30 <juliank> kay: Does CONFIG_CGROUP_DEBUG have any impact on performance?
Apr 30 16:20:48 <kay> it should not be noticeable
Apr 30 16:21:03 <kay> only if you actually use them, and even then they are very cheap
Apr 30 16:21:20 <kay> it's not much more than a tag sticked to a process
Apr 30 16:21:38 <kay> and a way to handle the tagged things then ...

--
Julian Andres Klode - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
 
Old 05-11-2010, 11:32 AM
Tollef Fog Heen
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

]] Julian Andres Klode

| On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
| > I am so far just testing on a singe machine, but it's my firm belief
| > that it's possible to have a fully functional systemd in squeeze.
|
| Only if #579755 is solved. While testing systemd on Debian, I found
| out that the option CONFIG_CGROUP_DEBUG is disabled in our kernel,
| but it is needed for systemd to work.

Yes and no. systemd needs cgroups support and there's a strong
preference upstream for the debug cgroup as it doesn't do anything but
group processes. It can work using any of the other cgroups just fine.

| Another problem is that systemd requires libcgroup which has to be
| moved to /lib first.

I don't imagine that's much work, though. :-)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87eihioeqr.fsf@qurzaw.linpro.no">http://lists.debian.org/87eihioeqr.fsf@qurzaw.linpro.no
 
Old 05-11-2010, 04:13 PM
Luk Claes
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

On 05/11/2010 01:09 PM, Julian Andres Klode wrote:

On Tue, May 11, 2010 at 12:49:46PM +0200, Julien Cristau wrote:

On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote:


On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:



Is it really a good idea to have init depend on such an option?
(It's also disabled in all defconfigs.)


Here's what I heard from Kay Sievers:

Apr 30 16:13:27<juliank> kay: Is there a way to get it working without this option?
Apr 30 16:13:58<kay> no, no chance
Apr 30 16:14:18<kay> it's one of the building blocks to track/babysit processes
Apr 30 16:17:24<kay> it will not be "debug" some day, but always required, yes
Apr 30 16:17:57<kay> there is otherwise no way to reliably kill a service, you need a simple "container" to kill
Apr 30 16:18:17<kay> otherwise processes can fork faster than you can kill them
Apr 30 16:18:38<kay> cgroups provide a race free way to kill an entire group of processes
Apr 30 16:19:13<kay> and they can also tell you that all processes of a service died -> empty group
Apr 30 16:20:30<juliank> kay: Does CONFIG_CGROUP_DEBUG have any impact on performance?
Apr 30 16:20:48<kay> it should not be noticeable
Apr 30 16:21:03<kay> only if you actually use them, and even then they are very cheap
Apr 30 16:21:20<kay> it's not much more than a tag sticked to a process
Apr 30 16:21:38<kay> and a way to handle the tagged things then ...


This does mean that when you use something like screen, the tty it was
connected to is from then on unusable, right? As the cgroup that
contains the screen process also contains the getty and it doesn't kill
one without the other as that is in no way reliable :-)


Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BE98226.7090107@debian.org">http://lists.debian.org/4BE98226.7090107@debian.org
 
Old 05-14-2010, 09:12 AM
Scott James Remnant
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

> This does mean that when you use something like screen, the tty it was
> connected to is from then on unusable, right? As the cgroup that
> contains the screen process also contains the getty and it doesn't
> kill one without the other as that is in no way reliable :-)
>
Yes.

I investigated using cgroups in Upstart a while back, and hit the exact
same issue. There are two obvious solutions:

- allow a process to escape its cgroup (kernel patch); this is
completely insane, since cgroups are primarily used for security
containers, system policies, etc. Being able to escape your
container would be a Bad Thing

- having init actively monitor the processes in some way, and remove
them from the cgroup itself - in which case, cgroups lose their
entire appeal and you may as well use the proc connector (which is
what Upstart 0.10 will use)


Also note that Kay's assertion that there's no way to know all the
processes you need to kill is incorrect. UNIX solved this decades ago
with process groups.

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
 
Old 05-14-2010, 10:03 AM
Tollef Fog Heen
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

]] Scott James Remnant

| I investigated using cgroups in Upstart a while back, and hit the exact
| same issue. There are two obvious solutions:
|
| - allow a process to escape its cgroup (kernel patch); this is
| completely insane, since cgroups are primarily used for security
| containers, system policies, etc. Being able to escape your
| container would be a Bad Thing

Or just have per-user cgroups that a process is moved into when logging
in, see libpam-cgroup for something that does this.

In addition, killing all members in a cgroup when a service goes down is
optional, not mandatory, so the tty would be usable just fine.

[...]

| Also note that Kay's assertion that there's no way to know all the
| processes you need to kill is incorrect. UNIX solved this decades ago
| with process groups.

I believe the problem is that processes can escape and change their
process group.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ocgiajgt.fsf@qurzaw.linpro.no">http://lists.debian.org/87ocgiajgt.fsf@qurzaw.linpro.no
 
Old 05-14-2010, 01:25 PM
Scott James Remnant
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

> Or just have per-user cgroups that a process is moved into when
> logging in, see libpam-cgroup for something that does this.
>
Then getty would respawn the second you login, stealing the controlling
terminal from bash.

> In addition, killing all members in a cgroup when a service goes down is
> optional, not mandatory, so the tty would be usable just fine.
>
It's not that cgroups are used for killing all members, it's that
cgroups are used to detect when the service goes down. systemd doesn't
care about SIGCHLD so much as the cgroup becoming empty.

> I believe the problem is that processes can escape and change their
> process group.
>
systemd will need processes to be able to escape or change their
cgroup :-)

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
 
Old 05-20-2010, 10:51 PM
Russell Coker
 
Default Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

On Friday 14 May 2010 23:25:37 Scott James Remnant wrote:
> > Or just have per-user cgroups that a process is moved into when
> > logging in, see libpam-cgroup for something that does this.
> >
> >
>
> Then getty would respawn the second you login, stealing the controlling
> terminal from bash.

Why can't systemd use cgroups for monitoring daemons (the new functionality
that wasn't in any previous Linux init system) and run getty's in the
traditional manner?

It seems that cgroups offer significant benefits for some uses but not for every
use.

Also what about sshd, telnetd, etc? They can also have long-lived processes
on behalf of users that are separate from the port listening functionality of
the main daemon.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005210851.06187.russell@coker.com.au">http://lists.debian.org/201005210851.06187.russell@coker.com.au
 

Thread Tools




All times are GMT. The time now is 09:52 AM.

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