Discussion:
[HEADS-UP] systemd for F14 - the next steps
(too old to reply)
Lennart Poettering
2010-07-14 01:24:06 UTC
Permalink
Heya,

as many of you probably know systemd got accepted as feature for F-14 by
FESCO a few weeks back.

https://fedoraproject.org/wiki/Features/systemd

And in case you want to read up what systemd actually is, here's the
blog post that introduced it (only slightly out-of-date, we have however
advanced a bit since then):

http://0pointer.de/blog/projects/systemd.html

Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide. So far it does
not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
want to notify everybody that I am planning to do this change very soon
now (tomorrow?). Then, systemd will be pulled in onto your rawhide
system and is used exclusively for booting (so far, you can still choose
between it and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.

At this point the following packages in rawhide have been updated to
provide socket based activation [Hint: in case you are wondering, socket
activation is one of the amazing things in systemd, see the original
announcement for details]: dbus, udev, avahi, rtkit. Before F14 I want
to at least add rpcbind and rsyslog to this list for socket based
activation, and most likely cups. For rpcbind/rsyslog the patches have
been submitted upstream, and even have partly been merged already).

It would be great if we could ship native unit files (as replacement for
the current sysvinit scripts) for as many packages in Fedora as we can
for F14, and in particular for all those services that are installed by
default. [Hint: unit files is the systemd term for files describing
services (i.e. daemons) and other objects systemd starts and
maintains]. I have prepared native unit files for the majority of
services of the default install, and will now post them on bugzilla
piece by piece for inclusion in the rpms. Ideally, those unit files are
shipped upstream, but they can be added in the rpms too. Unit files are
usually very short for normal services and should be easy to write
(i.e. you don't have to think about dependencies or any complexities
like that at all in most cases, unless you want to do fancy stuff
involving early boot or late shut down). Unit files should be written
for daemons that currently install SysV init scripts and also (and this
matters!) for all services currently started via D-Bus bus
activation. Writing native unit files enables the radical form of
parallelization that systemd employs. Units without native unit files,
i.e. only SysV or D-Bus service files, will only benefit from very
minimal parallelization.

Note that neither patching in socket based activation, nor shipping
native unit files will break services in a non-systemd boot up. In order
to keep our options open to possibly revert things before F14 we
explciitly made sure not to break compatibility with non-systemd
boots. i.e. the socket actviation patches become NOPs if systemd is not
running and the native unit files are ignored, so that only sysv init
scripts matter. Also note that even in the case that we do roll back to
upstart before the release of F14 this work won't be in vain, as work
that has been done has been done and will then becom euseful when we
adopt systemd in the next cycle. I want to stress though that at this
point in time I see no reason to assume that we shouldn't make it for
F14.

So, here's my call for help, in order to make this all a big success:

a) if you maintain a package which includes a daemon/service from the
default install, expect a proposed unit file in bugzilla soon. Would be
awesome if you could check it and add it to your RPM. Even better would
be if you get it merged upstream. I have unit files the majority of
these services. Ping me on irc (#systemd on fdo, I'm 'mezcalero'), if
you wonder whether yours is one of them, and if you have questions.

b) if you maintain a package which includes a daemon/service from
outside the default install, it would be awesome if you could ship
native unit files too, even though I don't have any ready for
you. Writing unit files is not difficult, and should be well documented
in the man pages. In particular have a look daemon(7),
i.e. http://0pointer.de/public/systemd-man/daemon.html and related man
pages. A good example for a systemd-enabled RPM for a D-Bus service is
rtkit. You might want to check it out and its .spec file:
http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?view=markup
A good example for a systemd-enabled RPM for a service that currently
installs a SysV init script, checkout Avahi and its .spec file:
http://cvs.fedoraproject.org/viewvc/devel/avahi/avahi.spec?view=markup
Some package could use the native unit love more than others. For
example, I have seen terrible things done to daemonize
processes and drop privs in pure shell (the bittorrent packages as one
example). Packages like that could really benefit from native unit
files which make this much easier and nicer and cleaner.

c) if you are the developer of a package that could benefit from socket
activation, please consider patching it for it. How that works is
documented in the man pages:
http://0pointer.de/public/systemd-man/daemon.html and
http://0pointer.de/public/systemd-man/sd-daemon.html and related, see
http://0pointer.de/public/systemd-man/ for the full list.

d) There's one thing that is not directly related to systemd but which
I'd really like to see done at the same time: moving /var/lock and
/var/run to tmpfs, like suse and ubuntu already did it. The changes
necessary should be small, but probably in a non-trivial number of
packages: each mention of /var/run in the .spec files needs to be
%ghosted. Also, some minimal changes to rc.sysinit need to be done, so
that the dirs are mounted (this could be done by systemd too, in case we
get the sysinit split hhoyer started to work on done before
F14). Finally, there might be a few packages which start to act confused
if their directories beneath /var/run is go away on reboot. But these
problems should already have been fixed by the Ubuntuans and Suses of
this world for us. It would be really great if somebody would volunteer
for this and go through the packages to add %ghost everywhere and ensure
otherwise this works out. The ubuntu and suse folks might have some
docs around with more ideas about this.

e) play around with systemd, test it!

f) contribute to our work! We always are happy about people contributing
code or docs, or even artwork (we could use a logo... ;-)).

And again, if anybody has a question, many systemd folks are around on
#systemd on fdo, and particularly me, mezcalero. So if you have
questions, ask us there, or right here on this thread.

There are a couple of bugs that still need to be fixed in other
packages than systemd, before F14:

https://bugzilla.redhat.com/show_bug.cgi?id=614245
https://bugzilla.redhat.com/show_bug.cgi?id=612789
https://bugzilla.redhat.com/show_bug.cgi?id=612728
https://bugzilla.redhat.com/show_bug.cgi?id=612712

That said, things should already work really well in rawhide right now,
and you should have no trouble bringing up and down the system with
systemd using its sysv compatibility logic to execute the existing SysV
init scripts. Please try it out and report back. Note that you still
need to pass "init=/bin/systemd" on the kernel command line, until the
point I make the change i mentioned above.

A short FAQ:

1) Q: If I patch my service for systemd socket activation, will this break
things for people not using systemd?

A: No, it won't.

2) Q: If I ship native systemd unit files, will this break things for
people not using systemd?

A: No, it won't.

3) Q: Will things become miraculously fast by booting with systemd?

A: No, it won't. When you boot with only SysV services
(i.e. utilizing the systemd SysV compatiblity logic to its max),
things should become only very little faster, as only very minimal
parallelization is employed then. And even if you have added native
service files for every single service, you won't make a slow
machine a supercomputer. Speeding up the boot requires a lot of
work everyhwere, and it is not sufficient to parallelize only
daemon bootup. i.e. rc.sysinit needs more parallelization too, and
is currently a single linear monolithic script. That said, on SSD
things should be noticably faster (though don't expect too much),
on rotating media things are not as rosy, simply because the Linux
IO scheduler cannot fully
keep up with with the increased parallelization and readahead is not a
solution for this, but more of a kinda futile attempt to fix this
without touching the kernel. Stuff like Jens Axboe's fcache sound
like a better solution, and even a bit like the approaches MS and
Apple took in this area.

Let me stress here however that I would like to see people judge
systemd not by its mere speed. Please see the full set of features
(again, read the initial blog post for details and maybe even the
man pages). It is our main objective to do things right. One part
of "doing it right" is "doing it fast", but it's far from the only
thing.

4) Q: If I don't care about systemd and don't update my packages, will
things stop working for me in F14?

A: No, they will continue to work. Since systemd's SysV compatiblity is quite
extensive things should just continue to work just fine.

5) Q: Why systemd? Isn't Upstart awesome too?

A: Well, opinions on that matter, see my original blog story for
details. Suffice to say that I am not exactly the only one who
thinks this way.

6) Q: LSB/SysV init scripts are standardized in the LSB! Why are you
breaking with that standard?

A: Well, actually we aren't. systemd provides compatibility with SysV
to a very large degree, we even have support for various
distribution extensions. The vast majority of init scripts should
continue to work in systemd just fine, even though they might work
even better with native unit files.

In the long run we actually hope to minimize differences between
distros with this, by establishing common hooks services should
use and asking everybody to use those hooks and ship their service
files in their upstream packages. The idea is that the systemd
unit file is automatically a lot more portable and
distribution-independent then the init scripts ever were.

7) Q: Are the other distros switching too?

A: Well, they are not as fast, but it looks very much like it. I have
been working very closely with Kay Sievers from Suse to integrate
systemd equally well into the OpenSuse semantics, and it will
enter their distro as soon as their development cycle
reopens. Debian, Gentoo, ArchLinux have packages in their
archives, but it's not the default there (yet?). I guess at least
for Debian/Gentoo it is very hard to make decisions about dfaults
like this. Meego has someone working on this, but I have
not followed that closely. And there are some smaller distros
which have adopted it too, and I know at least one (Pardus) that
plans to make it the default in the next release. And regarding
Ubuntu I leave it to you figuring out what is going on (Hint: you
might want to check out for what company the main developer of
Upstart -- which systemd replaces -- works for...). And never
forget that Fedora is of course the leader in development, so it
should be us who lead here... ;-)

And if you have any further questions, talk to us on IRC! Or reply to
this thread!

And also, don't forget to check the (extensive I believe) body of
documentation we now have, it might already answer your question. In
particular the blog story I already mentioned way too often:

http://0pointer.de/blog/projects/systemd.html

It's quite a novel I fear, but full of interesting stuff. And then there is the set of man pages:

http://0pointer.de/public/systemd-man/

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tomasz Torcz
2010-07-14 06:09:24 UTC
Permalink
Post by Lennart Poettering
4) Q: If I don't care about systemd and don't update my packages, will
things stop working for me in F14?
A: No, they will continue to work. Since systemd's SysV compatiblity is quite
extensive things should just continue to work just fine.
I'm maintain a package (hdapsd) which is started on-demand (when hardware appears)
by upstart. As so, I ship no SysV script, only minimal upstart job description
activated by hardware addition. In F12 I used to ship a custom udev rule, but
it became unnecessary with upstart 0.6.
Now, your FAQ only talks about keeping compatibility with SysV scripts, which I
don't have. There's no mention of compatibility with upstart jobs. What should
I do? Skip this altogether and move daemon startup to new udev rule (like, I believe,
blue does)?
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg at chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 238 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100714/e645eb6d/attachment-0001.bin
Lennart Poettering
2010-07-14 12:44:45 UTC
Permalink
Post by Tomasz Torcz
Post by Lennart Poettering
4) Q: If I don't care about systemd and don't update my packages, will
things stop working for me in F14?
A: No, they will continue to work. Since systemd's SysV compatiblity is quite
extensive things should just continue to work just fine.
I'm maintain a package (hdapsd) which is started on-demand (when hardware appears)
by upstart. As so, I ship no SysV script, only minimal upstart job description
activated by hardware addition. In F12 I used to ship a custom udev rule, but
it became unnecessary with upstart 0.6.
The number of packages currently using Upstart jobs should be very minimal,
which is why I haven't mentioned it in the mail. However, here's how to
cover your case best:

Every device in the udev tree that is tagged with "systemd" appears as
device unit in systemd. Like any other units device units may have
dependencies on any other kind of units, for example service units. For
device units those dependencies may also be configured directly with the
udev rules file.

You would hence write a small udev fragment which does this:

SUBSYSTEM=="block", KERNEL=="sd*", TAG="systemd", ENV{SYSTEMD_WANTS}="hdapsd@%k.service"

(and actually, given that block devices are tagged anyway by a rule we
ship along systemd you could even shorten that and skip the double
tagging. But I left it in above, just to show how it works.)

And then you place as service file hdapsd at .service in
/lib/systemd/system which is then instantiated for each block device,
very much like your current upstart job. See the getty configuration for
an example how to write and use instantiated service files in systemd.

That said, I am a bit puzzled about hdapsd though, since to my knowledge
the kernel does the head parking anyway since kernel 2.6.28 and hence
the package should be obsolete, or isn't it?
Post by Tomasz Torcz
Now, your FAQ only talks about keeping compatibility with SysV
scripts, which I don't have. There's no mention of compatibility with
upstart jobs. What should I do? Skip this altogether and move daemon
startup to new udev rule (like, I believe, blue does)?
No, indeed we do not provide compatibility with upstart jobs.

The bluetooth case we handle a bit differently than what I suggested to
you above: every bluetooth device in the udev tree has a "wants"
dependency on 'bluetooth.target', and 'bluetoothd.service' will then be
pulled in by that. i.e. there is an indirection in place here via the
target unit bluetooth.target, which allows other folks to easily hook in
other stuff into bluetooth by simply placing a dependency from
bluetooth.target onto their service instead of having to write an udev
rule. (and in case you are wondering, in systemd terms 'target units'
are a bit like classic sysvinit runlevels, i.e. can be used to group
multiple services in an easy way, except that you may have multiple
target units actvie, while runlevels you could only have one at a time.)

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tomasz Torcz
2010-07-14 13:00:27 UTC
Permalink
On Wed, Jul 14, 2010 at 02:44:45PM +0200, Lennart Poettering wrote:

Thanks for the explanation, I will modify my package accordingly.
Post by Lennart Poettering
That said, I am a bit puzzled about hdapsd though, since to my knowledge
the kernel does the head parking anyway since kernel 2.6.28 and hence
the package should be obsolete, or isn't it?
Since 2.6.28 kernel provides a way for userspace to park device. hdapsd
reads the accelerometer data from kernel, decides if laptop is falling
and signal kernel to park hdd. It is a connector between accelerometer
and /sys/block/.../unload_heads.
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg at chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Hans de Goede
2010-07-14 08:11:31 UTC
Permalink
Hi,
Post by Lennart Poettering
Heya,
<snip snip>
Post by Lennart Poettering
b) if you maintain a package which includes a daemon/service from
outside the default install, it would be awesome if you could ship
native unit files too, even though I don't have any ready for
you. Writing unit files is not difficult
I'm involved in maintaining the initscripts for iscsi-intiator-utils.
I'm not sure if iscsi-intiator-utils is part of the default install,
but lots of people have it installed as libvirt requires it.

iscsi-initiator-utils comes with 2 initscripts. 1 to start iscsid and
1 to login to iscsi nodes configured in the iscsi database
(/var/lib/iscsi):
http://cvs.fedoraproject.org/viewvc/devel/iscsi-initiator-utils/iscsid.init?view=markup
http://cvs.fedoraproject.org/viewvc/devel/iscsi-initiator-utils/iscsidevs.init?view=markup

iscsid is a semi-regular daemon, yet its initscript is special as it
only starts iscsid when needed. Socket based activation is out of the question as iscsid
is a userspace kernel support daemon. Which needs to be started ASAP,
so that it is ready to do error recovery when the kernel needs it.

However we do not want to always start it, only when iscsi targets are in use.
So the bash iscsid script has this "beauty" :

# FIXME this has a false positive for root on nfs
root_is_iscsi() {
rootopts=$(awk '{ if ($1 !~ /^[ \t]*#/ && $2 == "/") { print $4; }}' /etc/mtab)
[[ "$rootopts" =~ "_netdev" ]]
}

force_start() {
echo -n $"Starting $prog: "
modprobe -q iscsi_tcp
modprobe -q ib_iser
modprobe -q cxgb3i
modprobe -q bnx2i
modprobe -q be2iscsi
daemon $prog
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}

use_discoveryd() {
grep -qrs "discovery.sendtargets.use_discoveryd = Yes" /var/lib/iscsi/send_targets
if [ $? -eq 0 ] ; then
return 0
fi

grep -qrs "discovery.isns.use_discoveryd = Yes" /var/lib/iscsi/isns
if [ $? -eq 0 ] ; then
return 0
fi

return 1
}

start() {
[ -x $exec ] || exit 5
[ -f $config ] || exit 6

# only start if nodes are setup to startup automatically, root is iscsi,
# or if iscsid is managing the sessions.
grep -qrs "node.startup = automatic" /var/lib/iscsi/nodes
if [ $? -eq 0 ] || root_is_iscsi || use_discoveryd ; then
force_start
return $?
fi

return 0
}

And the iscsi (note no d) script has similar (albeit simpler) magic
to decide if it should try to login to any nodes.

So the question is how to deal with stuff like this in systemd.
I'm thinking myself that maybe the solution here is to just keep
using systemv style initscripts here, but I'm not sure.

Thanks & Regards,

Hans
Colin Walters
2010-07-14 15:08:56 UTC
Permalink
Post by Hans de Goede
iscsid is a semi-regular daemon, yet its initscript is special as it
only starts iscsid when needed. Socket based activation is out of the question as iscsid
is a userspace kernel support daemon. Which needs to be started ASAP,
so that it is ready to do error recovery when the kernel needs it.
However we do not want to always start it, only when iscsi targets are in use.
Move the code into the daemon, and have it exit() if it's not needed?
Lennart Poettering
2010-07-14 15:43:30 UTC
Permalink
Post by Hans de Goede
iscsi-initiator-utils comes with 2 initscripts. 1 to start iscsid and
1 to login to iscsi nodes configured in the iscsi database
http://cvs.fedoraproject.org/viewvc/devel/iscsi-initiator-utils/iscsid.init?view=markup
http://cvs.fedoraproject.org/viewvc/devel/iscsi-initiator-utils/iscsidevs.init?view=markup
iscsid is a semi-regular daemon, yet its initscript is special as it
only starts iscsid when needed. Socket based activation is out of the question as iscsid
is a userspace kernel support daemon. Which needs to be started ASAP,
so that it is ready to do error recovery when the kernel needs it.
[...]
Post by Hans de Goede
So the question is how to deal with stuff like this in systemd.
I'm thinking myself that maybe the solution here is to just keep
using systemv style initscripts here, but I'm not sure.
Kay, Harald and I have now discussed this a little, and this is what
we'd propose:

There seem to be three problems here:

1) Your init script loads kernel modules. You could easily cover that by
placing "ExecStartPre=-/sbin/modprobq -qab iscsi_tcp ib_iser cxgb3i bnx2i
be2iscsi" in the systemd service file of iscsid. However, generally
doing stuff like that is an indication that the modules are broken and
should be fixed. i.e. Kay recently made changes to the kernel so that
you can use a macro like MODULE_ALIAS_MISCDEV in modules to make sure
modules are autoloaded when their device node is first accessed, and that
udev creates those device nodes properly in advance. If these modules
offer their services via some kind of device node a scheme like this
should be adopted. Hand-loading modules is always a bit ugly, and
automatic handling via module autoloading would be much
preferable. (Also, instead of starting modprobe 5 times, call it only
once, please. And unloading the modules when the service goes down is a
really bad idea.)

2) You parse some configuration files or similar to figure out whether
you want iscsid to be started. This we believe is just wrong. That's not
how things work on Linux. Whether you want to start a daemon on boot
should be controlled by something like chkconfig or systemd-install
(which is basically chkconfig for systemd), not via some per-daemon
configuration file switch. I mean, what iscsid is doing there would be
like if Apache (and similarly all other daemons we have) would have an
apache.conf config switch StartDaemon=yes or so, and only when that is
set apache would be started by the init script. Or in other words: the
central place where services are enabled or disabled for SysV is
/etc/rc?.d/, not your configuration files. And for systemd the
equivalent is /etc/systemd/systemd. If you add another layer for
enabling/disabling you just complicate things, and slow down things. And
the admins will hate you because they cannot figure why iscsid doesn't
start if they run /etc/init.d/iscsid start. Have a single on/off switch,
in a well known place where everybody else has it too. Don't add more
on/off switches in line there, to confuse people so that they have to
flip them all if they want something started. And don't parse
configuration files from shell, that's just evil.

3) You check mtab to figure out whether the rootdir is on iscsi. That
cannot work, as mtab is not really updated anyway, and if at all you
should look in /proc/mounts, but this won't really give your the
information either. The proper way to handle this in systemd is to start
iscsid if an iscsi block device appears. udev recognizes iscsi block
devices, and this could be used to write a simple udev rule that pulls
in iscsid.service as soon as one of those block devices appear (a simple
trick would be to match against the symlink name
/dev/disk/by-id...). And that should be all that is necessary.

So in summary, the approach would be to write a simple .service file
which loads the modules via the suggested ExecStartPre= line, and then
just executes iscsid. And then this unit is either activated at boot
time which is enabled via "systemd-install" because the admin wanted so,
or when udev notices an iscsid block device. That's a simple scheme
that should be robust, race-free and without any shell madness.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Colin Walters
2010-07-14 15:53:15 UTC
Permalink
On Wed, Jul 14, 2010 at 11:43 AM, Lennart Poettering
Post by Lennart Poettering
time which is enabled via "systemd-install" because the admin wanted so,
Does it make sense to export iscsid for administrator control? I mean
- won't things explode if it's stopped? It's more of a userspace
component of the operating system, as opposed to an add-on server that
runs on top of the OS like httpd.
Lennart Poettering
2010-07-14 17:11:06 UTC
Permalink
Post by Colin Walters
On Wed, Jul 14, 2010 at 11:43 AM, Lennart Poettering
Post by Lennart Poettering
time which is enabled via "systemd-install" because the admin wanted so,
Does it make sense to export iscsid for administrator control? I mean
- won't things explode if it's stopped? It's more of a userspace
component of the operating system, as opposed to an add-on server that
runs on top of the OS like httpd.
I think it does make sense to give the admin control, since it can
be used to browse for iscsi devices on the network, which is something
admin might or might not want.

systemd actually supports the destinction between admin-controllable and
non-admin-controllable enabling of units. For example, if you want to
make sure from within a package that a service is run during normal
runtime without giving the admin tha ability to disable it you would
just package a symlink like this:

/lib/systemd/system/multi-user.target.wants/foo.service ? /lib/systemd/system/foo.service

(along with your service file foo.service; and note that
multi-user.target is a unit which is kinda equivalent to the old
runlevel 3, and this symlink simply hooks in foo.service into that
unit).

And if you want to give the admin the control, then you would
not put any symlinks like this into the package, but instead include a
small section in the .service file which contains information about how
a service should be hooked in if it is enabled. That can look like this:

<snip>
[Install]
WantedBy=multi-user.target
</snip>

This section is then read by systemd-install, which is the admin's
command to enable or disable units. When he calls "systemd-install
enable foo.service" this would then have the effect of create a symlink
like this:

/etc/systemd/system/multi-user.target.wants/foo.service ? /lib/systemd/system/foo.service

Note the difference in the /etc vs. /lib prefix.

Or in other words:

If you have a service that should be enabled and be outside of the admin
control place a link in /lib/systemd/... and do so by simply shipping it
like that in the rpm.

If you have a service that should be enabled/disabled depending on admin
decision, then place an [Install] section in the unit file which then
allows the admin to enable this unit via 'systemd-install' and results
in symlinks in /etc/systemd/....

That all said I think if there is reasonable doubt, then I'd go the
systemd-install way, to empower the admin to do whatever he likes to do.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Bill Nottingham
2010-07-14 14:58:07 UTC
Permalink
Post by Lennart Poettering
Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide. So far it does
not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
want to notify everybody that I am planning to do this change very soon
now (tomorrow?). Then, systemd will be pulled in onto your rawhide
system and is used exclusively for booting (so far, you can still choose
between it and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.
This seems a little backwards. If we want to support both, then we need
to just leave it as 'Conflicts', and we'll just flip the default in
comps. By marking it as 'Obsoletes', you effectively make it impossible
to still boot with upstart, as it will be removed in any yum update.
Post by Lennart Poettering
d) There's one thing that is not directly related to systemd but which
I'd really like to see done at the same time: moving /var/lock and
/var/run to tmpfs, like suse and ubuntu already did it. The changes
necessary should be small, but probably in a non-trivial number of
packages: each mention of /var/run in the .spec files needs to be
%ghosted. Also, some minimal changes to rc.sysinit need to be done, so
that the dirs are mounted (this could be done by systemd too, in case we
get the sysinit split hhoyer started to work on done before
F14). Finally, there might be a few packages which start to act confused
if their directories beneath /var/run is go away on reboot. But these
problems should already have been fixed by the Ubuntuans and Suses of
this world for us. It would be really great if somebody would volunteer
for this and go through the packages to add %ghost everywhere and ensure
otherwise this works out. The ubuntu and suse folks might have some
docs around with more ideas about this.
I suspect the biggest issue here is confined daemons, as they may
not have permissions to create their own directories in /var/run or
/var/lock once they've been started. Unfortunately, it's the sort of
flag day that we really can't do unless everything in our tree is fixed.

Bill
Daniel J Walsh
2010-07-14 15:04:30 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide. So far it does
not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
want to notify everybody that I am planning to do this change very soon
now (tomorrow?). Then, systemd will be pulled in onto your rawhide
system and is used exclusively for booting (so far, you can still choose
between it and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.
This seems a little backwards. If we want to support both, then we need
to just leave it as 'Conflicts', and we'll just flip the default in
comps. By marking it as 'Obsoletes', you effectively make it impossible
to still boot with upstart, as it will be removed in any yum update.
Post by Lennart Poettering
d) There's one thing that is not directly related to systemd but which
I'd really like to see done at the same time: moving /var/lock and
/var/run to tmpfs, like suse and ubuntu already did it. The changes
necessary should be small, but probably in a non-trivial number of
packages: each mention of /var/run in the .spec files needs to be
%ghosted. Also, some minimal changes to rc.sysinit need to be done, so
that the dirs are mounted (this could be done by systemd too, in case we
get the sysinit split hhoyer started to work on done before
F14). Finally, there might be a few packages which start to act confused
if their directories beneath /var/run is go away on reboot. But these
problems should already have been fixed by the Ubuntuans and Suses of
this world for us. It would be really great if somebody would volunteer
for this and go through the packages to add %ghost everywhere and ensure
otherwise this works out. The ubuntu and suse folks might have some
docs around with more ideas about this.
I suspect the biggest issue here is confined daemons, as they may
not have permissions to create their own directories in /var/run or
/var/lock once they've been started. Unfortunately, it's the sort of
flag day that we really can't do unless everything in our tree is fixed.
Bill
Are you talking about mounting shm at /var/run and /var/lock? SELinux
should be able to handle this. But you have a big spec file problem.

rpm -qf /var/run/* | grep -v not | wc
61 61 1853

Lots of directories owned by packages.
Bill Nottingham
2010-07-14 15:14:12 UTC
Permalink
Post by Daniel J Walsh
Are you talking about mounting shm at /var/run and /var/lock? SELinux
should be able to handle this.
I mean the case where you have:

%dir /var/run/mypackage

In the world where you mount a tmpfs there, mypackage would need to create
that dir on startup. However, it's possible that mypackage is a confined
daemon that only has privleges to write to /var/run/mypackage, not to
/var/run itself to create the directory. (The same thing can just happen
with daemons that run as non-root, without SELinux being involved.)

Of course, we can wait for Val's unionfs stuff to show up upstream, and fix
it that way. But that may be considered cheating.

Bill
Lennart Poettering
2010-07-14 16:57:23 UTC
Permalink
Post by Daniel J Walsh
Post by Bill Nottingham
I suspect the biggest issue here is confined daemons, as they may
not have permissions to create their own directories in /var/run or
/var/lock once they've been started. Unfortunately, it's the sort of
flag day that we really can't do unless everything in our tree is fixed.
Bill
Are you talking about mounting shm at /var/run and /var/lock? SELinux
should be able to handle this. But you have a big spec file problem.
rpm -qf /var/run/* | grep -v not | wc
61 61 1853
Lots of directories owned by packages.
Which is precisely the reason why I was looking for somebody to champion
this (having provenpackager status would be a good idea, anyone?). The
spec files need to be updated to %ghost those /var/run dirs.

If SELinux is not a problem, the %ghost stuff should be easy. Alas
involves fixing quite a few spec files.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Kevin Fenzi
2010-07-14 15:48:05 UTC
Permalink
On Wed, 14 Jul 2010 10:58:07 -0400
Post by Bill Nottingham
Post by Lennart Poettering
Since the acceptance by FESCO it has been added to Rawhide together
with patched or updated versions of a few related packages.
However, what has not been done so far is making it the default in
Rawhide. So far it does not "Obsolete" Upstart yet, just
"Conflicts" with it. With this mail I want to notify everybody that
I am planning to do this change very soon now (tomorrow?). Then,
systemd will be pulled in onto your rawhide system and is used
exclusively for booting (so far, you can still choose between it
and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.
This seems a little backwards. If we want to support both, then we
need to just leave it as 'Conflicts', and we'll just flip the default
in comps. By marking it as 'Obsoletes', you effectively make it
impossible to still boot with upstart, as it will be removed in any
yum update.
I agree. Please don't Obsolete upstart.

Lets just flip it in comps/new installs/live media and see how it goes.

We also still have initng around, so I don't see why we should remove
upstart for those that choose to keep using it, as well as have some
way for people to get back to a booting system for debugging in case
they run into a systemd issue they cannot immediately solve.

Looking forward to playing with systemd... ;)

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100714/f35baaf5/attachment.bin
James Antill
2010-07-14 16:32:32 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide. So far it does
not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
want to notify everybody that I am planning to do this change very soon
now (tomorrow?). Then, systemd will be pulled in onto your rawhide
system and is used exclusively for booting (so far, you can still choose
between it and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.
This seems a little backwards. If we want to support both, then we need
to just leave it as 'Conflicts', and we'll just flip the default in
comps. By marking it as 'Obsoletes', you effectively make it impossible
to still boot with upstart, as it will be removed in any yum update.
But then nobody will have systemd by default, it'll requiring using
"yum shell" to manually move to it and thus. it'll get very little
testing.
I'd suggest one of two things:

1. Have systemd "Obsolete: upstart <= 0.6.5-5.fc14", and then bump the
release on upstart. This means people doing "yum update" will move to
systemd, but people will have a choice by upgrading upstart.

2. Have systemd "Obsolete: upstart <= 0.6.5-5.fc13", this means anyone
moving to rawhide _after_ will get systemd and anyone on rawhide can
also do "downgrade upstart" and then "install systemd".

...#1 seems better, assuming we want most people to be testing systemd.
Bill Nottingham
2010-07-14 16:47:36 UTC
Permalink
Post by James Antill
Post by Bill Nottingham
This seems a little backwards. If we want to support both, then we need
to just leave it as 'Conflicts', and we'll just flip the default in
comps. By marking it as 'Obsoletes', you effectively make it impossible
to still boot with upstart, as it will be removed in any yum update.
But then nobody will have systemd by default, it'll requiring using
"yum shell" to manually move to it and thus. it'll get very little
testing.
It will get testing in all new installs. If we decide to keep it for
F-14, then we can add the obsoletes.

Bill
Lennart Poettering
2010-07-14 16:54:15 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide. So far it does
not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
want to notify everybody that I am planning to do this change very soon
now (tomorrow?). Then, systemd will be pulled in onto your rawhide
system and is used exclusively for booting (so far, you can still choose
between it and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.
This seems a little backwards. If we want to support both, then we need
to just leave it as 'Conflicts', and we'll just flip the default in
comps. By marking it as 'Obsoletes', you effectively make it impossible
to still boot with upstart, as it will be removed in any yum update.
Well, I don't think we want to support both. I believe F14 should be
systemd and only systemd, but we want the option to revert to upstart
should that not work out.

I am very much interested to get upgraded systems to use systemd as
well, which is why I'd really like to go the Obsoletes way, and use a
versioned Obsoletes, so that we can switch back to upstart if we want to
by another versioned Obsoletes, but this time from upstart. (which is
exactly what James Antill proposed in his mail)

Or in other words: I'd like to make this switch for the whole distro,
not leave it to the individual machines.

So, unless there is really strong opposition to the Obsoletes approach
I'd go on and do the switch?
Post by Bill Nottingham
I suspect the biggest issue here is confined daemons, as they may
not have permissions to create their own directories in /var/run or
/var/lock once they've been started. Unfortunately, it's the sort of
flag day that we really can't do unless everything in our tree is fixed.
Well, a temporary and kind of ugly fix could be to add lines like the
following into the systemd service files for these services.

ExecStartPre=-/bin/mkdir -p -Z foo_t /var/run/foo

Or something like that. And for service which continue to use SysV
scripts something similar is easily thinkable in the init scripts.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Bill Nottingham
2010-07-14 17:01:17 UTC
Permalink
Post by Lennart Poettering
Well, I don't think we want to support both. I believe F14 should be
systemd and only systemd, but we want the option to revert to upstart
should that not work out.
I am very much interested to get upgraded systems to use systemd as
well, which is why I'd really like to go the Obsoletes way, and use a
versioned Obsoletes, so that we can switch back to upstart if we want to
by another versioned Obsoletes, but this time from upstart. (which is
exactly what James Antill proposed in his mail)
Or in other words: I'd like to make this switch for the whole distro,
not leave it to the individual machines.
So, unless there is really strong opposition to the Obsoletes approach
I'd go on and do the switch?
If we're at the... 95% coverage case, I guess. What I don't want is that
machines suddenly stop booting with no recourse other than init=/bin/bash
and manual recovery. There are some side cases that would be nice to either
have working, or documenting that they're not done yet (serial consoles,
assorted other things.)
Post by Lennart Poettering
Post by Bill Nottingham
I suspect the biggest issue here is confined daemons, as they may
not have permissions to create their own directories in /var/run or
/var/lock once they've been started. Unfortunately, it's the sort of
flag day that we really can't do unless everything in our tree is fixed.
Well, a temporary and kind of ugly fix could be to add lines like the
following into the systemd service files for these services.
ExecStartPre=-/bin/mkdir -p -Z foo_t /var/run/foo
Or something like that. And for service which continue to use SysV
scripts something similar is easily thinkable in the init scripts.
Hardcoding foo_t is bad if they ever switch policy (MLS, etc.). But
it is an option.

Bill
drago01
2010-07-14 17:07:29 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
Well, I don't think we want to support both. I believe F14 should be
systemd and only systemd, but we want the option to revert to upstart
should that not work out.
I am very much interested to get upgraded systems to use systemd as
well, which is why I'd really like to go the Obsoletes way, and use a
versioned Obsoletes, so that we can switch back to upstart if we want to
by another versioned Obsoletes, but this time from upstart. (which is
exactly what James Antill proposed in his mail)
Or in other words: I'd like to make this switch for the whole distro,
not leave it to the individual machines.
So, unless there is really strong opposition to the Obsoletes approach
I'd go on and do the switch?
If we're at the... 95% coverage case, I guess. What I don't want is that
machines suddenly stop booting with no recourse other than init=/bin/bash
and manual recovery. There are some side cases that would be nice to either
have working, or documenting that they're not done yet (serial consoles,
assorted other things.)
What about this (ugly) approach:

Make upstart require systemd and make it to be the default.
This was people running "yum update" will get systemd while still
having upstart as a fallback in case stuff breaks.

Once we decide to stick to it we could remove the requirement and add
the obsolete.
John Reiser
2010-07-14 17:16:11 UTC
Permalink
Post by Bill Nottingham
What I don't want is that
machines suddenly stop booting with no recourse other than init=/bin/bash
and manual recovery. There are some side cases that would be nice to either
have working, or documenting that they're not done yet (serial consoles,
assorted other things.)
Right this moment, rawhide+pungi+anaconda+yum cannot install from DVD.
Not having a serial console will make a bad situation worse.
--
John Reiser, jreiser at BitWagon.com
Continue reading on narkive:
Loading...