Michael Biebl <biebl@debian.org> writes:

> Am 07.03.2012 23:34, schrieb Michael Biebl:
>> On 07.03.2012 22:46, Steve Langasek wrote:
>>> On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
>>>
>>>> It's rather easy to confuse upstart's process tracking. You
>>>> explicitly have to tell upstart if a daemon forks once or twice
>>>> (expect daemon, expect fork) and if the daemon forks multiple
>>>> children upstart often doesn't get it right.
>
> [...]
>
>> Especially the dbus type is very neat. I don't think upstart supports
>> something similar like that.
>
> Reading through my message again, it seems I managed to turn that
> discussion into systemd vs upstart (again). That's something I down
> want and I'm not interested in, so I'm sorry for that and I hope we
> can just leave it at that.
>
> What I'm actually interested in, is how we can get away from sysvinit
> to something more suitable for todays needs while solving the problem
> for our non-Linux ports.

There won't be a switch in Debian to just ONE new init system. There are
too many people insisting their pet init must be the ONE. So give up on
the idea on replacing sysvinit and start thinking about being an
alternative to sysvinit. That also has the benefit that you can let the
non-linux ports figure out what they want to do themself and let them do
the work.

So step 1: Acknowledge that Debian will have to support more than one
init and sysvinit will remain for the time being.

Step 2: getting your pet init into Debian as alternative to sysvinit.

One thing discussed was having a common init description file (could be
one of the existing formats or something new) and generating sysvinit,
systemd or upstart config files from those. So think about it and record
all the information needed for each init system and come up with a
format for the common init description file. A good idea was to only
cover the most common cases and leave the too complex cases to ship
indivual configs for each init.

Then think about how to deploy them.

1) Ship init config in all formats in the package in parallel

This would be nice at least for really hard cases where the common init
description file is too hard to write. But this could generally be done
and the init configs would be generated at build time if a common init
description file exists. E.g. dh_installinit could automate this.

2) generate init config at install time

Alternatively you could ship the common init description file in the
package and generate the right init config during install. Probably the
best way for this would be to use file triggers. The package just drops
the config in /usr/share/common-init-files/ and sysvinit, upstart and/or
systemd install a trigger that then generated the right config for them.


For extra credits think about allowing multiple init system to be
co-installed. There could be an option to boot with init=sysv,
init=upstart or init=systemd. That would certainly make it simpler for
users to try out a new init.


Step 3: removing sysvinit

Then simply wait a few years for the new init system to catch on and
sysvinit supporters to die out. If you are right that your pet init is
the future then sysvinit will just fade away and can be removed.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fwdj7mh9.fsf@frosties.localnet">http://lists.debian.org/87fwdj7mh9.fsf@frosties.localnet

]] Steve Langasek

> There are also complications to using cgroups, in that suddenly any service
> that needs to be able to spawn long-running processes that outlive the
> service has to start caring about cgroups - both so that they survive the
> service being shut down from the outside, and so that the supervisor knows
> not to count these processes as evidence that the service is still running.

Yes, they need to start a new PAM session. I don't think this is
particularly surprising, but I can well imagine there's code out there
that does not do this. On the other hand, apart from login tools such
as sshd (which already use PAM), I don't think there's many services
where this is something they need. ICBW, though.

> ssh is going to be the first problem in this regard, though I'm sure there
> will be others. Has someone patched openssh to be cgroup-aware?

This is most of what libpam-systemd does. No need to patch sshd itself.

--
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: 87obs78t4g.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87obs78t4g.fsf@qurzaw.varnish-software.com

Tollef Fog Heen <tfheen@err.no> writes:
> ]] Steve Langasek

>> ssh is going to be the first problem in this regard, though I'm sure
>> there will be others. Has someone patched openssh to be cgroup-aware?

> This is most of what libpam-systemd does. No need to patch sshd itself.

Er, "UsePAM no"?

sshd has a bunch of non-PAM authentication mechanisms. It is by no means
guaranteed that everyone using sshd is using PAM. Now, we can just say
"that's broken, you're now required to use PAM," but this isn't a trivial
change. (Of course, as noted elsewhere, it may well be that systemd has
some way of dealing with this already.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87haxz7eaz.fsf@windlord.stanford.edu">http://lists.debian.org/87haxz7eaz.fsf@windlord.stanford.edu

]] Russ Allbery

> Tollef Fog Heen <tfheen@err.no> writes:
> > ]] Steve Langasek
>
> >> ssh is going to be the first problem in this regard, though I'm sure
> >> there will be others. Has someone patched openssh to be cgroup-aware?
>
> > This is most of what libpam-systemd does. No need to patch sshd itself.
>
> Er, "UsePAM no"?

That's «changing sshds configuration» which for most people is on a
completely different scale than patching the application itself. UsePAM
yes is also the default nowadays.

> sshd has a bunch of non-PAM authentication mechanisms. It is by no means
> guaranteed that everyone using sshd is using PAM. Now, we can just say
> "that's broken, you're now required to use PAM," but this isn't a trivial
> change. (Of course, as noted elsewhere, it may well be that systemd has
> some way of dealing with this already.)

You can use PAM sessions without using PAM auth, for instance if you're
using key authentication.

--
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: 87ipif8pvp.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87ipif8pvp.fsf@qurzaw.varnish-software.com

Tollef Fog Heen <tfheen@err.no> writes:
> ]] Russ Allbery

>> Er, "UsePAM no"?

> That's «changing sshds configuration» which for most people is on a
> completely different scale than patching the application itself. UsePAM
> yes is also the default nowadays.

That reduces the scope of affected users, but it doesn't eliminate the
problem. It means that anyone installing systemd needs to be aware that
they need to convert ssh to use PAM if it isn't currently, which is an
unintuitive connection.

There will be similar problems with, for example, Kerberos klogind (and
there I'm not sure it even has PAM support).

> You can use PAM sessions without using PAM auth, for instance if you're
> using key authentication.

Yes, I know. But they previously haven't done much useful for you, so
it's not unreasonable to turn it off. Turning off unused features in a
security interface is usually good practice.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fwdjexy8.fsf@windlord.stanford.edu">http://lists.debian.org/87fwdjexy8.fsf@windlord.stanford.edu

On Thu, Mar 08, 2012 at 08:11:11AM +0100, Tollef Fog Heen wrote:
> > There are also complications to using cgroups, in that suddenly any service
> > that needs to be able to spawn long-running processes that outlive the
> > service has to start caring about cgroups - both so that they survive the
> > service being shut down from the outside, and so that the supervisor knows
> > not to count these processes as evidence that the service is still running.

> Yes, they need to start a new PAM session. I don't think this is
> particularly surprising, but I can well imagine there's code out there
> that does not do this. On the other hand, apart from login tools such
> as sshd (which already use PAM), I don't think there's many services
> where this is something they need. ICBW, though.

The sshd process that supervises the user's session is not part of the pam
session. It *must* sit outside of it, to ensure proper teardown. And this
process should persist across restarts of the sshd service. So killing all
processes in the ssh service's cgroup, and relying on PAM to let user
sessions survive, would be the wrong answer.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120308194033.GB28482@virgil.dodds.net">http://lists.debian.org/20120308194033.GB28482@virgil.dodds.net

On 08.03.2012 20:40, Steve Langasek wrote:

> The sshd process that supervises the user's session is not part of the pam
> session. It *must* sit outside of it, to ensure proper teardown. And this
> process should persist across restarts of the sshd service. So killing all
> processes in the ssh service's cgroup, and relying on PAM to let user
> sessions survive, would be the wrong answer.

As has been mentioned already, the way to address this is to use
KillMode=process in sshd's service file (the default is cgroup).
This way, systemd only kills the main process on stop/restart which is
the behavaiour we want for sshd.

No mandatory PAM support in sshd is required for that.


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

OoO En cette nuit nuageuse du mercredi 07 mars 2012, vers 00:21,
Fernando Lemos <fernandotcl@gmail.com> disaitÂ*:

>> To give one particular example: systemd uses Linux-specific features to
>> accurately track all the processes started by a service, which allows
>> accurate monitoring and shutdown of processes which could otherwise
>> disassociate themselves from their parent processes via the usual
>> daemonizing trick. Â*POSIX doesn't provide features that allow this in
>> general, but Linux does. Â*(Quite possibly other OSes provide those
>> features too, but not in a standardized way.)

> By the way, upstart uses ptrace for this:

> http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/

> It's an interesting trick, and probably more portable too.

Maybe we could have an intermediate goal to patch any daemon to add an
option to not fork on start. If any daemon can be started without
forking, it seems easy to start/stop them without cgroups. This would
allow to generate a sysvinit script from systemd service description. I
don't know any daemon that does not have a flag to not fork on
start. The number of daemons to patch may be low.

This will not be as clean as using cgroups, but it won't be worst than
the actual situation.
--
Vincent Bernat ☯ http://vincent.bernat.im

printk("Entering UltraSMPenguin Mode...
");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c

On Sun, Mar 11, 2012 at 7:25 AM, Vincent Bernat <bernat@debian.org> wrote:
> OoO *En *cette nuit *nuageuse *du mercredi *07 *mars *2012, vers *00:21,
> Fernando Lemos <fernandotcl@gmail.com> disait*:
>
>>> To give one particular example: systemd uses Linux-specific features to
>>> accurately track all the processes started by a service, which allows
>>> accurate monitoring and shutdown of processes which could otherwise
>>> disassociate themselves from their parent processes via the usual
>>> daemonizing trick. *POSIX doesn't provide features that allow this in
>>> general, but Linux does. *(Quite possibly other OSes provide those
>>> features too, but not in a standardized way.)
>
>> By the way, upstart uses ptrace for this:
>
>> http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/
>
>> It's an interesting trick, and probably more portable too.
>
> Maybe we could *have an intermediate goal to patch any *daemon to add an
> option *to not *fork on *start. *If *any daemon *can be *started without
> forking, it seems *easy to start/stop them without *cgroups. *This would
> allow to generate a sysvinit *script from systemd service description. I
> don't *know *any daemon *that *does *not have *a *flag *to *not fork *on
> start. The number of daemons to patch may be low.
>
> This will not be *as clean as using cgroups, but it *won't be worst than
> the actual situation.

I don't quite understand the problem you're trying to solve. Both
upstart and systemd already handle cases where the daemon doesn't have
the option of not forking.

Regards,


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANVYNa_YSsBdAJ7DrLLnTLtob5w3sH46K0t1yuk88kepxQnuu g@mail.gmail.com">http://lists.debian.org/CANVYNa_YSsBdAJ7DrLLnTLtob5w3sH46K0t1yuk88kepxQnuu g@mail.gmail.com

OoO Vers la fin de l'après-midi du dimanche 11 mars 2012, vers 16:14,
Fernando Lemos <fernandotcl@gmail.com> disaitÂ*:

>> Maybe we could Â*have an intermediate goal to patch any Â*daemon to add an
>> option Â*to not Â*fork on Â*start. Â*If Â*any daemon Â*can be Â*started without
>> forking, it seems Â*easy to start/stop them without Â*cgroups. Â*This would
>> allow to generate a sysvinit Â*script from systemd service description. I
>> don't Â*know Â*any daemon Â*that Â*does Â*not have Â*a Â*flag Â*to Â*not fork Â*on
>> start. The number of daemons to patch may be low.
>>
>> This will not be Â*as clean as using cgroups, but it Â*won't be worst than
>> the actual situation.

> I don't quite understand the problem you're trying to solve. Both
> upstart and systemd already handle cases where the daemon doesn't have
> the option of not forking.

Yes, but systemd relies on cgroups which are not portable. If all
daemons were able to not fork, it would be easier to convert a .service
file to a classic init.d script and therefore use systemd (for example)
as default with Linux and sysvinit with autogenerated files on kFreeBSD.
--
Vincent Bernat ☯ http://vincent.bernat.im

panic ("Splunge!");
2.2.16 /usr/src/linux/drivers/scsi/psi240i.c