8:24 p.m.
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.
1:09 a.m.
On Wed, Jul 14, 2010 at 03:24:06AM +0200, Lennart Poettering wrote:
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(a)chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
7:44 a.m.
On Wed, 14.07.10 08:09, Tomasz Torcz (tomek(a)pipebreaker.pl) wrote:
On Wed, Jul 14, 2010 at 03:24:06AM +0200, Lennart Poettering wrote:
> 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(a)%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@.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?
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.
8 a.m.
On Wed, Jul 14, 2010 at 02:44:45PM +0200, Lennart Poettering wrote:
Thanks for the explanation, I will modify my package accordingly.
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(a)chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
3:11 a.m.
Hi,
On 07/14/2010 03:24 AM, Lennart Poettering wrote:
Heya,
<snip snip>
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.in...
http://cvs.fedoraproject.org/viewvc/devel/iscsi-initiator-utils/iscsidevs...
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
10:08 a.m.
On Wed, Jul 14, 2010 at 4:11 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
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" :
Move the code into the daemon, and have it exit() if it's not needed?
10:43 a.m.
On Wed, 14.07.10 10:11, Hans de Goede (hdegoede(a)redhat.com) wrote:
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.in...
http://cvs.fedoraproject.org/viewvc/devel/iscsi-initiator-utils/iscsidevs...
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.
[...]
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.
10:53 a.m.
On Wed, Jul 14, 2010 at 11:43 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
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.
12:11 p.m.
On Wed, 14.07.10 11:53, Colin Walters (walters(a)verbum.org) wrote:
On Wed, Jul 14, 2010 at 11:43 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
>
> 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.
5:55 p.m.
New subject: Runlevel subsys re-verification via /etc/rc (was RE: [HEADS-UP] systemd for F14 - the next steps)
-----Original Message-----
From: devel-bounces(a)lists.fedoraproject.org On Behalf
Of Lennart Poettering
Sent: Wednesday, July 14, 2010 8:43 AM
To: devel(a)lists.fedoraproject.org
Subject: Re: [HEADS-UP] systemd for F14 - the next steps
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.
A little apropos, something that's been around in SysV for a while, and is also a
symptom with upstart in F13, is that the /var/lock/subsys/ state doesn't always match
what init scripts have actually started, especially if there's a reason they've
exited successfully but w/o a persistent daemon.
You can test this by simply running /etc/rc on any running system and watch as it re-execs
things that already started on boot but didn't set a lock file. On a fresh F13 desktop
install
[root@test-f13 jcleaver]# /etc/rc
Entering non-interactive startup
Starting monitoring for VG vg_jctestf13: 2 logical volume(s) in volume group
"vg_testf13" monitored [ OK ]
Starting portreserve: [ OK ]
Starting system logger:
Starting irqbalance: [ OK ]
Starting cups:
Enabling Bluetooth devices:
[root@test-f13 jcleaver]#
On *EL5 variants, I get:
[root@el5-x86-64 ~]# /etc/rc
Entering non-interactive startup
Applying Intel CPU microcode update: [FAILED]
Starting sysstat: Calling the system activity data collector (sadc):
[ OK ]
Starting background readahead: [ OK ]
Starting anacron: [ OK ]
[root@el5-x86-64 ~]#
Questions:
1) Should I submit these as bugs on the individual packages? (This seems like a great use
for the "/var/lock/subsys/$subsys.init" case in /etc/rc, where an initscript has
been called at boot to do setup and doesn't need to be run again unless a
'stop' has occurred.)
2) How will systemd handle telinit/runlevel cases with the existing runlevel? Is there a
way to verify (from a logical init/subsys perspective only) that what should be running in
your runlevel is?
Regards,
-jc
7:07 p.m.
New subject: Runlevel subsys re-verification via /etc/rc (was RE: [HEADS-UP] systemd for F14 - the next steps)
On Wed, 14.07.10 15:55, Cleaver, Japheth (jcleaver(a)soe.sony.com) wrote:
2) How will systemd handle telinit/runlevel cases with the existing
runlevel? Is there a way to verify (from a logical init/subsys
perspective only) that what should be running in your runlevel is?
Not sure I fully grok the question, but we translate telinit requests,
so that "telinit 3" is kinda equivalent to "systemctl isolate
runlevel3.target".
Note that on systemd multiple targets can be active at the same time and
that includes that e.g. "runlevel3.target" and "runlevel4.target"
could
be active at the same time. In the event this happens the "runlevel"
command will return the highest runlevel target that is active. This
makes a lot of sense I believe, given that graphical.target (which we
alias to runlevel5.target) pulls in multi-user.target (which we alias to
runlevel3.target).
Also note that in systemd it is easily possible to have no
runlevel.target running at all. In that case the runlevel command will
just say "N".
And the subsys stuff is not really necessary in a systemd world. If sysv
scripts continue to create those files its fine, but systemd won't take
notice and it won't create any files like this for native units. The
subsys stuff is an attempt to properly synchronize service activation
without a central daemon. Since we now have that those files are kinda
unnecessary.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:15 a.m.
On 07/14/2010 10:43 AM, Lennart Poettering wrote:
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.
We cannot do this, because iscsid is needed to find the iscsi device.
The iscsid daemon and the kernel modules work together to implement the
iscsi protocol. Basically, to do discovery and log into disks, iscsid
will send/recv iscsi packets through the iscsi kernel modules. iscsid
then parses the packets and does things like CHAP and the iscsi
parameter negotiation.
11:14 a.m.
On Mon, 19.07.10 11:15, Mike Christie (mchristi(a)redhat.com) wrote:
On 07/14/2010 10:43 AM, Lennart Poettering wrote:
> 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.
We cannot do this, because iscsid is needed to find the iscsi device.
The iscsid daemon and the kernel modules work together to implement the
iscsi protocol. Basically, to do discovery and log into disks, iscsid
will send/recv iscsi packets through the iscsi kernel modules. iscsid
then parses the packets and does things like CHAP and the iscsi
parameter negotiation.
But if that's the case, why do you believe you gain anything by checking
whether the root directory is on iscsi?
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:44 a.m.
On 07/19/2010 11:14 AM, Lennart Poettering wrote:
On Mon, 19.07.10 11:15, Mike Christie (mchristi(a)redhat.com) wrote:
>
> On 07/14/2010 10:43 AM, Lennart Poettering wrote:
>> 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.
>
> We cannot do this, because iscsid is needed to find the iscsi device.
> The iscsid daemon and the kernel modules work together to implement the
> iscsi protocol. Basically, to do discovery and log into disks, iscsid
> will send/recv iscsi packets through the iscsi kernel modules. iscsid
> then parses the packets and does things like CHAP and the iscsi
> parameter negotiation.
But if that's the case, why do you believe you gain anything by checking
whether the root directory is on iscsi?
For root on iscsi we always need it on.
I think the problem was that the iscsid service was on by default, so
when things like libvirt install it iscsid would always start but many
times not be needed.
In F-14, can we change the default from being on to off then just have
the users set it to be started if they want it? For root though, then
would the installer set it to be on for the user.
12:33 p.m.
On Mon, 19.07.10 11:44, Mike Christie (mchristi(a)redhat.com) wrote:
> But if that's the case, why do you believe you gain anything
by checking
> whether the root directory is on iscsi?
For root on iscsi we always need it on.
But what happens for /home on iscsi? It's the same story, isn't it? So
why is / handled differently than /home in this respect?
I think the problem was that the iscsid service was on by default, so
when things like libvirt install it iscsid would always start but many
times not be needed.
In a systemd world we can fix this in a much nicer way:
libvirtd.service would just have a "Wants: iscsid.service" in it. That
way when libvirtd is started iscsid is started too. And if people use
iscsid in other areas too they can just add a single symlink
(/etc/systemd/system/multi-user.target.wants/iscsid.service →
/lib/systemd/system/iscsid.service) and it is started on boot, regadless
whether libvirtd is enabled or not.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:41 p.m.
Hi,
On 07/19/2010 07:33 PM, Lennart Poettering wrote:
On Mon, 19.07.10 11:44, Mike Christie (mchristi(a)redhat.com) wrote:
>> But if that's the case, why do you believe you gain anything by checking
>> whether the root directory is on iscsi?
>
> For root on iscsi we always need it on.
But what happens for /home on iscsi? It's the same story, isn't it? So
why is / handled differently than /home in this respect?
There are 2 conditions on which the iscsid script starts iscsid:
1) / is on iscsi
2) Some previously discovered iscsi targets in the iscsi database
/var/lib/iscsi are marked as automount
1) Is special because in this case the iscsi log in happens from the initrd,
and there should *not* be a re-login attempt when the iscsi initscript
(which runs after the iscsid script) does autologins, so the iscsi target
holding / is not marked as autostart (and autostop!!) in the iscsi database.
a target holding /home but not / would simply be marked autologin in the
iscsi database.
As Mike already said one option for F-14 is to simple make the iscsid service
default to off, and make anaconda turn it on when iscsi is used during
installation, and expect a sysadmin to enable it if he / she manually
configures iscsi after installation.
> I think the problem was that the iscsid service was on by
default, so
> when things like libvirt install it iscsid would always start but many
> times not be needed.
In a systemd world we can fix this in a much nicer way:
libvirtd.service would just have a "Wants: iscsid.service" in it. That
way when libvirtd is started iscsid is started too. And if people use
iscsid in other areas too they can just add a single symlink
(/etc/systemd/system/multi-user.target.wants/iscsid.service →
/lib/systemd/system/iscsid.service) and it is started on boot, regadless
whether libvirtd is enabled or not.
I'm afraid that is not how the relation between libvirt and
iscsi-initiator-utils works. I don't know exactly what libvirt needs
iscsi-initiator-utils for, but I think it does not require
iscsid to be running. I guess we need to involve one of the
libvirt guys into this discussion to tell us what exactly libvirt uses
iscsi-initiator-utils for.
Regards,
Hans
7:01 a.m.
On 07/19/2010 06:41 PM, Hans de Goede wrote:
>
> In a systemd world we can fix this in a much nicer way:
> libvirtd.service would just have a "Wants: iscsid.service" in it. That
> way when libvirtd is started iscsid is started too. And if people use
> iscsid in other areas too they can just add a single symlink
> (/etc/systemd/system/multi-user.target.wants/iscsid.service →
> /lib/systemd/system/iscsid.service) and it is started on boot, regadless
> whether libvirtd is enabled or not.
I'm afraid that is not how the relation between libvirt and
iscsi-initiator-utils works. I don't know exactly what libvirt needs
iscsi-initiator-utils for, but I think it does not require
iscsid to be running. I guess we need to involve one of the
libvirt guys into this discussion to tell us what exactly libvirt uses
iscsi-initiator-utils for.
Libvirt allows connecting to an iscsi target, using that storage as a local
'libvirt storage pool'. AIUI all libvirt uses is iscsiadm.
Here's a list of commands it can run behind the scenes:
ISCSIADM --mode session
ISCSIADM --mode iface
ISCSIADM --mode iface --interface $IFNAME --op new
ISCSIADM --mode iface --interface $IFNAME --op update --name
iface.initiatorname --value $IQN
ISCSIADM --mode discovery --type sendtargets --portal $PORTAL
ISCSIADM --mode node --portal portal --targetname $TARGETPATH --interface
$IFACE $ACTION
ISCSIADM --mode node --portal portal --targetname $TARGETPATH $ACTION
ISCSIADM --mode session -r $SESSION -R
ISCSIADM --mode discovery --type sendtargets --portal $PORTAL
You can check the relevant code here:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/storage/storage_backen...
- Cole
7:02 a.m.
On Tue, Jul 20, 2010 at 12:41:11AM +0200, Hans de Goede wrote:
>> I think the problem was that the iscsid service was on by
default, so
>> when things like libvirt install it iscsid would always start but many
>> times not be needed.
>
> In a systemd world we can fix this in a much nicer way:
> libvirtd.service would just have a "Wants: iscsid.service" in it. That
> way when libvirtd is started iscsid is started too. And if people use
> iscsid in other areas too they can just add a single symlink
> (/etc/systemd/system/multi-user.target.wants/iscsid.service →
> /lib/systemd/system/iscsid.service) and it is started on boot, regadless
> whether libvirtd is enabled or not.
I'm afraid that is not how the relation between libvirt and
iscsi-initiator-utils works. I don't know exactly what libvirt needs
iscsi-initiator-utils for, but I think it does not require
iscsid to be running. I guess we need to involve one of the
libvirt guys into this discussion to tell us what exactly libvirt uses
iscsi-initiator-utils for.
libvirt doesn't directly care about iscsid at all. It just issues
commands using iscsiadm to login/out of targets & query LUNs, etc.
If iscsiadm requires that iscsid be running in order to work, then
I guess it should activate it when required ?
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:58 a.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
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.
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
10:04 a.m.
On 07/14/2010 10:58 AM, Bill Nottingham wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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.
> 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.
10:14 a.m.
Daniel J Walsh (dwalsh(a)redhat.com) said:
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
11:57 a.m.
On Wed, 14.07.10 11:04, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> 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.
10:48 a.m.
On Wed, 14 Jul 2010 10:58:07 -0400
Bill Nottingham <notting(a)redhat.com> wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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
11:32 a.m.
On Wed, 2010-07-14 at 10:58 -0400, Bill Nottingham wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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.
11:47 a.m.
James Antill (james(a)fedoraproject.org) said:
> 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
12:38 p.m.
On Wed, 14.07.10 12:32, James Antill (james(a)fedoraproject.org) wrote:
On Wed, 2010-07-14 at 10:58 -0400, Bill Nottingham wrote:
> Lennart Poettering (mzerqung(a)0pointer.de) said:
> > 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.
Yes, this is exactly what I have in mind.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:54 a.m.
On Wed, 14.07.10 10:58, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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?
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.
12:01 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
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.)
> 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
12:07 p.m.
On Wed, Jul 14, 2010 at 7:01 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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.
12:32 p.m.
On Wed, 14.07.10 19:07, drago01 (drago01(a)gmail.com) wrote:
On Wed, Jul 14, 2010 at 7:01 PM, Bill Nottingham <notting(a)redhat.com> wrote:
> Lennart Poettering (mzerqung(a)0pointer.de) said:
>> 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.
Well, that doesn't really work, since upstart and systemd would fight
for the /sbin/init name. If we want the system to boot into systemd by
default /sbin/init must be linekd to /bin/systemd.
systemd provides compatibility with those sysv tools like
reboot/shutdown/runlevel and init itself via symlinks to native
binaries. The package "systemd" currently includes the native binaries
and "systemd-sysvinit" adds in those symlinks. Only
"systemd-sysvinit"
conflicts with upstart, and only that package is what makes systemd the
default init system. And that is the package which I want to make
obsolete upstart.
To achieve what you want to do upstart would need to support something
similar: make it possible to install it without insisting on the
/sbin/init file name and related ones, and then add in those names via
symlinks only by a an upstart-sysvinit package or so. But upstart
doesn't support something like that. Sorry.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:45 p.m.
On Wed, 2010-07-14 at 19:32 +0200, Lennart Poettering wrote:
Well, that doesn't really work, since upstart and systemd would fight
for the /sbin/init name. If we want the system to boot into systemd by
default /sbin/init must be linekd to /bin/systemd.
systemd provides compatibility with those sysv tools like
reboot/shutdown/runlevel and init itself via symlinks to native
binaries. The package "systemd" currently includes the native binaries
and "systemd-sysvinit" adds in those symlinks. Only
"systemd-sysvinit"
conflicts with upstart, and only that package is what makes systemd the
default init system. And that is the package which I want to make
obsolete upstart.
To achieve what you want to do upstart would need to support something
similar: make it possible to install it without insisting on the
/sbin/init file name and related ones, and then add in those names via
symlinks only by a an upstart-sysvinit package or so. But upstart
doesn't support something like that. Sorry.
Would alternatives work here ?
1:48 p.m.
On Wed, 14.07.10 13:45, Matthias Clasen (mclasen(a)redhat.com) wrote:
> To achieve what you want to do upstart would need to support
something
> similar: make it possible to install it without insisting on the
> /sbin/init file name and related ones, and then add in those names via
> symlinks only by a an upstart-sysvinit package or so. But upstart
> doesn't support something like that. Sorry.
Would alternatives work here ?
Yes, the alternatives system would probably work. However, I think there
are things where it is a good idea to use and where it isn't. And I
think this case is one of the latter. If we go down the switchable init
via symlinks route then i'd prefer if we did this via
installing/removing packages, not via the alternatives system.
i.e. if people want to keep upstart around then somebody should sit down
and prep packages which move all upstart binaries to other names and
then introduces a package upstart-sysvinit which then symlinks the names
to the old sysv command names. People could then install that package
and uninstall systemd-sysvinit to switch the default, while keeping both
systems around and accessible via init= on the kernel cmdline.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:59 p.m.
On Wed, 2010-07-14 at 20:48 +0200, Lennart Poettering wrote:
On Wed, 14.07.10 13:45, Matthias Clasen (mclasen(a)redhat.com) wrote:
> > To achieve what you want to do upstart would need to support something
> > similar: make it possible to install it without insisting on the
> > /sbin/init file name and related ones, and then add in those names via
> > symlinks only by a an upstart-sysvinit package or so. But upstart
> > doesn't support something like that. Sorry.
>
> Would alternatives work here ?
Yes, the alternatives system would probably work. However, I think there
are things where it is a good idea to use and where it isn't. And I
think this case is one of the latter. If we go down the switchable init
via symlinks route then i'd prefer if we did this via
installing/removing packages, not via the alternatives system.
I was trying to think of ways to reduce the 'what if it just stops
booting' fear involved in this transition, by finding a way to let
upstart and systemd temporarily coexist on a system.
I don't think we want to have a switchable init system as a feature
beyond the initial transition phase.
2:16 p.m.
On Wed, 14.07.10 14:59, Matthias Clasen (mclasen(a)redhat.com) wrote:
On Wed, 2010-07-14 at 20:48 +0200, Lennart Poettering wrote:
> On Wed, 14.07.10 13:45, Matthias Clasen (mclasen(a)redhat.com) wrote:
>
> > > To achieve what you want to do upstart would need to support something
> > > similar: make it possible to install it without insisting on the
> > > /sbin/init file name and related ones, and then add in those names via
> > > symlinks only by a an upstart-sysvinit package or so. But upstart
> > > doesn't support something like that. Sorry.
> >
> > Would alternatives work here ?
>
> Yes, the alternatives system would probably work. However, I think there
> are things where it is a good idea to use and where it isn't. And I
> think this case is one of the latter. If we go down the switchable init
> via symlinks route then i'd prefer if we did this via
> installing/removing packages, not via the alternatives system.
I was trying to think of ways to reduce the 'what if it just stops
booting' fear involved in this transition, by finding a way to let
upstart and systemd temporarily coexist on a system.
I don't think we want to have a switchable init system as a feature
beyond the initial transition phase.
Well, if upstart would be installabale without necessarily taking
posession of the /sbin/init binary name then we could make systemd the
default and people could boot into upstart by passing
init=/sbin/upstart or so.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:26 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
> Would alternatives work here ?
Yes, the alternatives system would probably work. However, I think there
are things where it is a good idea to use and where it isn't. And I
think this case is one of the latter. If we go down the switchable init
via symlinks route then i'd prefer if we did this via
installing/removing packages, not via the alternatives system.
alternatives isn't really appropriate - it's only changeable at runtime,
which means that you'd flip the alternative, and then telinit/shutdown/etc
would all start acting strangely w.r.t. the init you're currently running.
Bill
2:42 p.m.
On Wed, 14.07.10 15:26, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> > Would alternatives work here ?
>
> Yes, the alternatives system would probably work. However, I think there
> are things where it is a good idea to use and where it isn't. And I
> think this case is one of the latter. If we go down the switchable init
> via symlinks route then i'd prefer if we did this via
> installing/removing packages, not via the alternatives system.
alternatives isn't really appropriate - it's only changeable at runtime,
which means that you'd flip the alternative, and then telinit/shutdown/etc
would all start acting strangely w.r.t. the init you're currently running.
I think this is actually not that big of a problem. The systemd client
tools actually can speak /dev/initctl as well as the Upstart D-Bus API
too a limited degree. Also, the Upstart client tools actually speak
/dev/initctl too, to some degree. This is needed to facility upgrades
properly. Also note that systemd actually supports /dev/initctl.
Here's a little chart showing you which client tools (x) speak which
protocol (y):
sysvinit | Upstart | systemd
---------+---------+--------
/dev/initctl fully | limited | limited
Upstart Proto | fully | limited
Systemd Proto | | fully
And here's the same table showing which init daemons speak which protocol
(i.e. which proto is supported on the server side):
sysvinit | Upstart | systemd
---------+---------+--------
/dev/initctl fully | | limited
Upstart Proto | fully |
Systemd Proto | | fully
The effect of this is that the upstart client tools can speak to all
three init systems either via /dev/initctl or via native Upstart. And
also the systemd client tools can speak to all three init systems too,
via any of the three protocols.
"limited" in this context usually means that it is enough to reboot the
system or change a runlevel (or something equivalent).
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:16 p.m.
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(a)BitWagon.com
12:37 p.m.
On Wed, 14.07.10 10:16, John Reiser (jreiser(a)bitwagon.com) wrote:
> 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.
When systemd talks to the console it uses only /dev/console, never
something like /dev/tty1. That means if the serial console works at all
it should work with systemd as well.
Note that I have developed most of systemd by running it in a kvm
machine with serial console on my terminal. That always worked fine
(though I must admit that the last weeks I have exclusively tested i on
real machines).
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:25 p.m.
B1;2401;0cOn Wed, 14.07.10 13:01, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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.)
Well, I am not sure what you mean by 95% coverage case. Minus bugs we
should have 99.9% compatibility with SysV init right now. And those bugs
we don't find if people don't use things. Feature-wise systemd is
definitely "complete", bug-wise not really since it got only limited testing
so far.
Note that my rawhide machine I updated all the way from F7 or so, and it
still works. If other rawhide folks are like me they are not going to
reinstall rawhide just for the fun of it, but just upgrade their
development machines. I want those to upgrade to systemd, too.
Note that our sysv compat even goes so far that you can pass the old
runlevels on the kernel command line and systemd should do the right
thing. i.e. if you pass "S" on the kernel command line systemd will take
that as hint to enter its "rescue" mode, which is mostly equivalent to
the old runlevel 1/S. So I guess what I am saying is that debugging
won't be that different from debugging a sysv machine.
There's also the systemd.unit= kernel command line option which you may
use to boot into different targets. See the feature page for details.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:13 p.m.
On Wed, 14.07.10 13:44, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> There's also the systemd.unit= kernel command line option which you may
> use to boot into different targets. See the feature page for details.
Does it pull this from inittab if there's no other configuration for
this?
Ok. You got me on this one. Systemd does actually not parse the
inittab. That cruft looked a bit too ugly and clumsy and old for us to
support.
However, we have added replcacements for everything is was used
for. i.e. the gettys are started now via normal services.
The replacement for the default runlevel stuff is a symlink in
/etc/systemd/system. You could do this:
/etc/systemd/system/default.target → /lib/systemd/system/multi-user.target
to avoid the graphical UI, and boot into the text console only
(i.e. much like the old runlevel 3)
Or you could do this:
/etc/systemd/system/default.target → /lib/systemd/system/graphical.target
to boot into the graphical stuff by default. This is the default as we
package it.
And the admin could even define additional targets, to achieve different
system profiles he can boot into or switch forth and back to and from,
and give it arbitrary names, and even pull in any of the targets we ship
by default.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:24 p.m.
On 07/14/2010 02:13 PM, Lennart Poettering wrote:
On Wed, 14.07.10 13:44, Bill Nottingham (notting(a)redhat.com) wrote:
>
> Lennart Poettering (mzerqung(a)0pointer.de) said:
>> There's also the systemd.unit= kernel command line option which you may
>> use to boot into different targets. See the feature page for details.
>
> Does it pull this from inittab if there's no other configuration for
> this?
Ok. You got me on this one. Systemd does actually not parse the
inittab. That cruft looked a bit too ugly and clumsy and old for us to
support.
However, we have added replcacements for everything is was used
for. i.e. the gettys are started now via normal services.
The replacement for the default runlevel stuff is a symlink in
/etc/systemd/system. You could do this:
/etc/systemd/system/default.target → /lib/systemd/system/multi-user.target
to avoid the graphical UI, and boot into the text console only
(i.e. much like the old runlevel 3)
Or you could do this:
/etc/systemd/system/default.target → /lib/systemd/system/graphical.target
to boot into the graphical stuff by default. This is the default as we
package it.
Or you could just parse inittab and notice when runlevel 3 was listed.
Keeps everything nice and compatible, including existing manuals and
books, and sysadmin knowledge.
Jeff
1:25 p.m.
On Wed, Jul 14, 2010 at 8:24 PM, Jeff Garzik <jgarzik(a)pobox.com> wrote:
On 07/14/2010 02:13 PM, Lennart Poettering wrote:
> On Wed, 14.07.10 13:44, Bill Nottingham (notting(a)redhat.com) wrote:
>
>>
>> Lennart Poettering (mzerqung(a)0pointer.de) said:
>>> There's also the systemd.unit= kernel command line option which you may
>>> use to boot into different targets. See the feature page for details.
>>
>> Does it pull this from inittab if there's no other configuration for
>> this?
>
> Ok. You got me on this one. Systemd does actually not parse the
> inittab. That cruft looked a bit too ugly and clumsy and old for us to
> support.
>
> However, we have added replcacements for everything is was used
> for. i.e. the gettys are started now via normal services.
>
> The replacement for the default runlevel stuff is a symlink in
> /etc/systemd/system. You could do this:
>
> /etc/systemd/system/default.target → /lib/systemd/system/multi-user.target
>
> to avoid the graphical UI, and boot into the text console only
> (i.e. much like the old runlevel 3)
>
> Or you could do this:
>
> /etc/systemd/system/default.target → /lib/systemd/system/graphical.target
>
> to boot into the graphical stuff by default. This is the default as we
> package it.
Or you could just parse inittab and notice when runlevel 3 was listed.
Keeps everything nice and compatible, including existing manuals and
books, and sysadmin knowledge.
What about the passing a runlevel number to the kernel cmdline?
(Thats what I use when I want a different runlevel and not fiddle with
random config files).
2:09 p.m.
On Wed, 14.07.10 20:25, drago01 (drago01(a)gmail.com) wrote:
>> Or you could do this:
>>
>> /etc/systemd/system/default.target → /lib/systemd/system/graphical.target
>>
>> to boot into the graphical stuff by default. This is the default as we
>> package it.
>
> Or you could just parse inittab and notice when runlevel 3 was listed.
> Keeps everything nice and compatible, including existing manuals and
> books, and sysadmin knowledge.
What about the passing a runlevel number to the kernel cmdline?
That is fully supported. Systemd will translate those runlevel numbers
to native targets and execute them, overriding whatever
default.target might be pointing to.
(Thats what I use when I want a different runlevel and not fiddle
with
random config files).
Yes, that was my thinking too, which is why we decided it was Ok to drop
inittab completely while we kept compat support for kernel cmdline stuff in.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:08 p.m.
On Wed, 14.07.10 14:24, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> /etc/systemd/system. You could do this:
>
> /etc/systemd/system/default.target → /lib/systemd/system/multi-user.target
>
> to avoid the graphical UI, and boot into the text console only
> (i.e. much like the old runlevel 3)
>
> Or you could do this:
>
> /etc/systemd/system/default.target → /lib/systemd/system/graphical.target
>
> to boot into the graphical stuff by default. This is the default as we
> package it.
Or you could just parse inittab and notice when runlevel 3 was listed.
Keeps everything nice and compatible, including existing manuals and
books, and sysadmin knowledge.
Is this really such a biggie? I mean Upstart ignores inittab too, the
only option it still takes into account is this default runlevel and
that only via some shell hackery.
We go one step further and also ignore that one line. If Upstart managed
to pull this off without complains by simply replacing inittab with a
big blurb "Hey, changing this has no effect except for this one line",
and only left one option in there that still matters then we can go one
step further and place a file there which says "Hey, this file is
completely redundant, please do this other thing instead.", or can't we?
The manual and books already are wrong for almost everything
they say about inittab on all Fedora systems that run Upstart (and that
is F12 and F13 at least?). Just replacing one more option shouldn't make
any difference.
I'd also argue that simply changing a symlink in /etc/systemd/system is
a lot easier to understand and discoverable than having to edit old and
crufty /etc/inittab which to fully understand you really must have a
historical Unix background for.
Let's keep things simple, do the clean cut, document that in the file
itself and point people to the right and modern approach.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:18 p.m.
On 07/14/2010 03:08 PM, Lennart Poettering wrote:
I'd also argue that simply changing a symlink in
/etc/systemd/system is
a lot easier to understand and discoverable than having to edit old and
crufty /etc/inittab which to fully understand you really must have a
historical Unix background for.
Strangely enough, a lot of Fedora users actually have a Unix/Linux
background. ;-)
"Easier to understand and discoverable" seems to vary from one's point
of view. As the author of the change in question, of course it's easier
to understand and discover.
From the standpoint of -everyone else-, the change would be breaking
scripts and human knowledge needlessly. There is no urgent need to
eliminate /etc/inittab.
Jeff
2:33 p.m.
On Wed, 14.07.10 15:18, Jeff Garzik (jgarzik(a)pobox.com) wrote:
On 07/14/2010 03:08 PM, Lennart Poettering wrote:
> I'd also argue that simply changing a symlink in /etc/systemd/system is
> a lot easier to understand and discoverable than having to edit old and
> crufty /etc/inittab which to fully understand you really must have a
> historical Unix background for.
Strangely enough, a lot of Fedora users actually have a Unix/Linux
background. ;-)
"Easier to understand and discoverable" seems to vary from one's point
of view. As the author of the change in question, of course it's easier
to understand and discover.
From the standpoint of -everyone else-, the change would be breaking
scripts and human knowledge needlessly. There is no urgent need to
eliminate /etc/inittab.
Well, not "everyone" else, only those which come from old-world Unix.
I would have prefered if you would have taken up this fight with the
Upstart people when it was added to Fedora. We are just finishing the
work Upstart began in this area, and I am not really willing to fight
now a battle that if at all should have been fought some releases ago when
Upstart was adopted.
I am sorry, but I am not going to provide full compatibility with
inittab within systemd. It's not supported in Upstart and I won't do a
backwards flip and support it in systemd again.
That train already left the station.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4 p.m.
On 07/14/2010 03:33 PM, Lennart Poettering wrote:
On Wed, 14.07.10 15:18, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> On 07/14/2010 03:08 PM, Lennart Poettering wrote:
>> I'd also argue that simply changing a symlink in /etc/systemd/system is
>> a lot easier to understand and discoverable than having to edit old and
>> crufty /etc/inittab which to fully understand you really must have a
>> historical Unix background for.
>
> Strangely enough, a lot of Fedora users actually have a Unix/Linux
> background. ;-)
>
> "Easier to understand and discoverable" seems to vary from one's point
> of view. As the author of the change in question, of course it's easier
> to understand and discover.
>
> From the standpoint of -everyone else-, the change would be breaking
> scripts and human knowledge needlessly. There is no urgent need to
> eliminate /etc/inittab.
Well, not "everyone" else, only those which come from old-world Unix.
I would have prefered if you would have taken up this fight with the
Upstart people when it was added to Fedora. We are just finishing the
work Upstart began in this area, and I am not really willing to fight
now a battle that if at all should have been fought some releases ago when
Upstart was adopted.
I am sorry, but I am not going to provide full compatibility with
inittab within systemd. It's not supported in Upstart and I won't do a
backwards flip and support it in systemd again.
Runlevel inittab changing works in all releases up to and including
Fedora 13. That should not change.
Jeff
4:17 p.m.
On Wed, 14.07.10 17:00, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> I would have prefered if you would have taken up this fight with
the
> Upstart people when it was added to Fedora. We are just finishing the
> work Upstart began in this area, and I am not really willing to fight
> now a battle that if at all should have been fought some releases ago when
> Upstart was adopted.
>
> I am sorry, but I am not going to provide full compatibility with
> inittab within systemd. It's not supported in Upstart and I won't do a
> backwards flip and support it in systemd again.
Runlevel inittab changing works in all releases up to and including
Fedora 13. That should not change.
Well, I guess we have to agree to disagree about whether this one option
is a particularly valuable inheritance from traditional Unix which we
really need to support for all eternity.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:03 p.m.
On Wed, 2010-07-14 at 21:08 +0200, Lennart Poettering wrote:
On Wed, 14.07.10 14:24, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> > /etc/systemd/system. You could do this:
> >
> > /etc/systemd/system/default.target → /lib/systemd/system/multi-user.target
> >
> > to avoid the graphical UI, and boot into the text console only
> > (i.e. much like the old runlevel 3)
> >
> > Or you could do this:
> >
> > /etc/systemd/system/default.target → /lib/systemd/system/graphical.target
> >
> > to boot into the graphical stuff by default. This is the default as we
> > package it.
>
> Or you could just parse inittab and notice when runlevel 3 was listed.
> Keeps everything nice and compatible, including existing manuals and
> books, and sysadmin knowledge.
Is this really such a biggie? I mean Upstart ignores inittab too, the
only option it still takes into account is this default runlevel and
that only via some shell hackery.
We go one step further and also ignore that one line.
That one line is quite important though. I'm also not sure what you
gain by not parsing it. Just have:
/lib/systemd/system/1.target => single-user.target
/lib/systemd/system/3.target => multi-user.target
/lib/systemd/system/5.target => graphical.target
...and use the target specified by that one line. At some point much
later we can then change the inittag to runlevel "default", and it'll
work as it does now.
Let's keep things simple, do the clean cut, document that in the
file
itself and point people to the right and modern approach.
I think you mean being fully back compat. with all of inittab is "not
simple", but I doubt Jeff was asking for that (given that, as you say,
upstart is in RHEL-6 and doesn't). But adding a few lines of C code to
parse the default runlevel out of inittab seems pretty simple and would
bring with it a lot of backwards compat.
3:38 p.m.
On Wed, 14.07.10 16:03, James Antill (james(a)fedoraproject.org) wrote:
> > Or you could just parse inittab and notice when runlevel 3
was listed.
> > Keeps everything nice and compatible, including existing manuals and
> > books, and sysadmin knowledge.
>
> Is this really such a biggie? I mean Upstart ignores inittab too, the
> only option it still takes into account is this default runlevel and
> that only via some shell hackery.
>
> We go one step further and also ignore that one line.
That one line is quite important though. I'm also not sure what you
gain by not parsing it.
Well, the way things are designed is that we read compat configuration
only if no native configuration for this particular item
exists. Example: we read /etc/init.d/avahi-daemon if
/lib/systemd/system/avahi-daemon.service does not exist. This is
followed everywhere else too.
Now, if we translate the same logic to inittab we'd have to check
/etc/systemd/systemd/default.target first, and if that doesn't exist
fallback to /etc/inittab. However, that symlink will always exist
because we ship it in the rpm and we want people to use it. Which makes
the fallback kinda useless, unless we tell people to rm the symlink when
they edit inittab. However, if they do that they could just update the
symlink to point to the right place directly. Which is why I think
compat for that line in inittab is really not necessary.
Just have:
/lib/systemd/system/1.target => single-user.target
/lib/systemd/system/3.target => multi-user.target
/lib/systemd/system/5.target => graphical.target
This exists already, though we called it runlevel2.target and
similar. Runlevel symlinks for 0,1,6 are placed in /lib/systemd/system,
and those for 2-5 are in /etc/systemd/system, so that the admin can have
changing them if he feels like it.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:01 p.m.
On Wed, 2010-07-14 at 22:38 +0200, Lennart Poettering wrote:
On Wed, 14.07.10 16:03, James Antill (james(a)fedoraproject.org)
wrote:
> > > Or you could just parse inittab and notice when runlevel 3 was listed.
> > > Keeps everything nice and compatible, including existing manuals and
> > > books, and sysadmin knowledge.
> >
> > Is this really such a biggie? I mean Upstart ignores inittab too, the
> > only option it still takes into account is this default runlevel and
> > that only via some shell hackery.
> >
> > We go one step further and also ignore that one line.
>
> That one line is quite important though. I'm also not sure what you
> gain by not parsing it.
Well, the way things are designed is that we read compat configuration
only if no native configuration for this particular item
exists. Example: we read /etc/init.d/avahi-daemon if
/lib/systemd/system/avahi-daemon.service does not exist. This is
followed everywhere else too.
Sure, and for service configuration that seems fine.
Now, if we translate the same logic to inittab we'd have to
check
/etc/systemd/systemd/default.target first, and if that doesn't exist
fallback to /etc/inittab.
But your runlevel is not a service configuration, so I see no reason
why you couldn't say "if there is an 'id:blah:' line in inittab
that's
authoritative .... if not, use default".
4:19 p.m.
On Wed, 14.07.10 17:01, James Antill (james(a)fedoraproject.org) wrote:
On Wed, 2010-07-14 at 22:38 +0200, Lennart Poettering wrote:
> On Wed, 14.07.10 16:03, James Antill (james(a)fedoraproject.org) wrote:
>
> > > > Or you could just parse inittab and notice when runlevel 3 was
listed.
> > > > Keeps everything nice and compatible, including existing manuals and
> > > > books, and sysadmin knowledge.
> > >
> > > Is this really such a biggie? I mean Upstart ignores inittab too, the
> > > only option it still takes into account is this default runlevel and
> > > that only via some shell hackery.
> > >
> > > We go one step further and also ignore that one line.
> >
> > That one line is quite important though. I'm also not sure what you
> > gain by not parsing it.
>
> Well, the way things are designed is that we read compat configuration
> only if no native configuration for this particular item
> exists. Example: we read /etc/init.d/avahi-daemon if
> /lib/systemd/system/avahi-daemon.service does not exist. This is
> followed everywhere else too.
Sure, and for service configuration that seems fine.
> Now, if we translate the same logic to inittab we'd have to check
> /etc/systemd/systemd/default.target first, and if that doesn't exist
> fallback to /etc/inittab.
But your runlevel is not a service configuration, so I see no reason
why you couldn't say "if there is an 'id:blah:' line in inittab
that's
authoritative .... if not, use default".
Well, I want people to use the new thing and have the new logic
auhtoritative. I don't want to keep the old cruft around forever.
Also, where do you suggest I put this message?
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:58 a.m.
On Wed, 2010-07-14 at 23:19 +0200, Lennart Poettering wrote:
On Wed, 14.07.10 17:01, James Antill (james(a)fedoraproject.org)
wrote:
> But your runlevel is not a service configuration, so I see no reason
> why you couldn't say "if there is an 'id:blah:' line in inittab
that's
> authoritative .... if not, use default".
Well, I want people to use the new thing and have the new logic
auhtoritative. I don't want to keep the old cruft around forever.
Sure, but this is not a case of you having to decide between "do the
old thing forever" or "break it now".
Do it as:
1. Leave /etc/inittab functionally as it is in Fed-13, with 3 and 5
doing the obvious thing and the big comment saying stuff about systemd
instead of upstart. If people want to opt. in to "the new way" they can
just cp /dev/empty /etc/inittab.
2. For F-15 or F-16 change inittab to be:
id:default:initdefault:
...and have anaconda write that out and configure using a symlink
instead. Users can still change it to 3 or 5, or whatever ... but if
they don't it'll work as though inittab doesn't exist (the "new"
way).
3. At some point you remove support for parsing inittab, so people have
to configure using symlinks ... some people will still not like you
removing free compat. code, but assuming you wait a few years at least
"everything" will support "the new way".
6:33 a.m.
On Thu, Jul 15, 2010 at 01:58:33AM -0400, James Antill wrote:
1. Leave /etc/inittab functionally as it is in Fed-13, with 3 and 5
doing the obvious thing and the big comment saying stuff about systemd
instead of upstart. If people want to opt. in to "the new way" they can
just cp /dev/empty /etc/inittab.
2. For F-15 or F-16 change inittab to be:
id:default:initdefault:
...and have anaconda write that out and configure using a symlink
instead. Users can still change it to 3 or 5, or whatever ... but if
they don't it'll work as though inittab doesn't exist (the "new"
way).
3. At some point you remove support for parsing inittab, so people have
to configure using symlinks ... some people will still not like you
removing free compat. code, but assuming you wait a few years at least
"everything" will support "the new way".
I agree. You went through all the trouble to make systemd backwards
compatible with /etc/fstab, why not /etc/inittab for the default
runlevel too?
9:59 a.m.
On Thu, 15.07.10 07:33, Chuck Anderson (cra(a)WPI.EDU) wrote:
On Thu, Jul 15, 2010 at 01:58:33AM -0400, James Antill wrote:
> 1. Leave /etc/inittab functionally as it is in Fed-13, with 3 and 5
> doing the obvious thing and the big comment saying stuff about systemd
> instead of upstart. If people want to opt. in to "the new way" they can
> just cp /dev/empty /etc/inittab.
>
> 2. For F-15 or F-16 change inittab to be:
>
> id:default:initdefault:
>
> ...and have anaconda write that out and configure using a symlink
> instead. Users can still change it to 3 or 5, or whatever ... but if
> they don't it'll work as though inittab doesn't exist (the
"new" way).
>
> 3. At some point you remove support for parsing inittab, so people have
> to configure using symlinks ... some people will still not like you
> removing free compat. code, but assuming you wait a few years at least
> "everything" will support "the new way".
I agree. You went through all the trouble to make systemd backwards
compatible with /etc/fstab, why not /etc/inittab for the default
runlevel too?
Because it reverses everything.
I.e. generally we have the rule that "native configuration breaks legacy
configuration". However, to make the inittab stuff useful we'd have to
turn that around, and say that "legacy breaks native". Why? Because the
/etc/systemd/system/default.target symlink is created by the rpm in all
cases and would hence make the inittab ignored anyway.
If I added inittab parsing support even when keeping "native breaks
legacy" around, then inittab would matter only if the default.target
symlink doesn't exist. We could certainly inform the user to delete that
symlink, via some blurb in inittab, however, if he goes and deletes it,
wouldn't it be much easier to just fix properly and to the right boot
target, and have a future-proof system?
i.e. isn't this:
# vi /etc/inittab
... user reads the blurb and changes a line, exits
# rm /etc/systemd/system/default.target
really that much better in your eyes, than this:
# vi /etc/inittab
... user reads the blurb, quits right-away
# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
I don't think it is...
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:41 a.m.
tor 2010-07-15 klockan 16:59 +0200 skrev Lennart Poettering:
If I added inittab parsing support even when keeping "native
breaks
legacy" around, then inittab would matter only if the default.target
symlink doesn't exist.
Yeah, when saying "keep compat" you have to define exactly how to do
that, which isn't always easy. I myself have written kickstart scripts
that would need to be changed to deal with this but it's really rather
trivial and I don't have any good alternative suggestion.
But I do think the %postinstall script, if it's an install and not an
update, should check the contents of inittab and set the symlink
accordingly. Otherwise an upgrade to a new release might make the system
start X when it didn't do that before, which would be bad.
/Alexander
10:47 a.m.
Alexander Boström (abo(a)root.snowtree.se) said:
> If I added inittab parsing support even when keeping
"native breaks
> legacy" around, then inittab would matter only if the default.target
> symlink doesn't exist.
To go back to upstart, one of the reason upstart parses inittab for
the default runlevel is because it doesn't actually have a configuration
store for this elsewhere. So it's simplest to just use the legacy
config there.
But I do think the %postinstall script, if it's an install and
not an
update, should check the contents of inittab and set the symlink
accordingly. Otherwise an upgrade to a new release might make the system
start X when it didn't do that before, which would be bad.
This part I agree with... we shouldn't be changing people's systems on
upgrade.
Bill
11:19 a.m.
On 07/15/2010 09:17 PM, Bill Nottingham wrote:
Alexander Boström (abo(a)root.snowtree.se) said:
> But I do think the %postinstall script, if it's an install and not an
> update, should check the contents of inittab and set the symlink
> accordingly. Otherwise an upgrade to a new release might make the system
> start X when it didn't do that before, which would be bad.
>
This part I agree with... we shouldn't be changing people's systems on
upgrade.
Can someone please file a bug report, preferably with a patch for the
post install script? This shouldn't be controversial.
Rahul
12:51 p.m.
On Thu, 15.07.10 21:49, Rahul Sundaram (metherid(a)gmail.com) wrote:
On 07/15/2010 09:17 PM, Bill Nottingham wrote:
> Alexander Boström (abo(a)root.snowtree.se) said:
>
>> But I do think the %postinstall script, if it's an install and not an
>> update, should check the contents of inittab and set the symlink
>> accordingly. Otherwise an upgrade to a new release might make the system
>> start X when it didn't do that before, which would be bad.
>>
> This part I agree with... we shouldn't be changing people's systems on
> upgrade.
>
Can someone please file a bug report, preferably with a patch for the
post install script? This shouldn't be controversial.
No need. It's on my todo list. My todo list has a perfect memory... ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:25 a.m.
On Thu, 15.07.10 17:41, Alexander Boström (abo(a)root.snowtree.se) wrote:
tor 2010-07-15 klockan 16:59 +0200 skrev Lennart Poettering:
> If I added inittab parsing support even when keeping "native breaks
> legacy" around, then inittab would matter only if the default.target
> symlink doesn't exist.
Yeah, when saying "keep compat" you have to define exactly how to do
that, which isn't always easy. I myself have written kickstart scripts
that would need to be changed to deal with this but it's really rather
trivial and I don't have any good alternative suggestion.
But I do think the %postinstall script, if it's an install and not an
update, should check the contents of inittab and set the symlink
accordingly. Otherwise an upgrade to a new release might make the system
start X when it didn't do that before, which would be bad.
That is a good suggestion. To make sure that the symlinks are never
overwritten by rpm we need to install them manually in %post anyway, and
quickly checking the old inittab for a good default choice is a very
good idea.
/me adds this to his todo list.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:04 a.m.
On Thu, 15 Jul 2010 16:59:40 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
Because it reverses everything.
And this is a problem because ?
I.e. generally we have the rule that "native configuration
breaks
legacy configuration".
Who's "we", what is the rationale of this rule ? Looks like it is a
rule made to break things on upgrades. Most upstream I know have the
inverse rule. Do not break things unless it is *necessary*.
I do not see why it is necessary to break here.
However, to make the inittab stuff useful we'd
have to turn that around, and say that "legacy breaks native". Why?
Because the /etc/systemd/system/default.target symlink is created by
the rpm in all cases and would hence make the inittab ignored anyway.
If I added inittab parsing support even when keeping "native breaks
legacy" around, then inittab would matter only if the default.target
symlink doesn't exist. We could certainly inform the user to delete
that symlink, via some blurb in inittab, however, if he goes and
deletes it, wouldn't it be much easier to just fix properly and to
the right boot target, and have a future-proof system?
i.e. isn't this:
# vi /etc/inittab
... user reads the blurb and changes a line, exits
# rm /etc/systemd/system/default.target
really that much better in your eyes, than this:
# vi /etc/inittab
... user reads the blurb, quits right-away
# ln
-sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
I don't think it is...
You are assuming a human is doing these changes, in many cases it is
install (kickstart) scripts. And keeping compatibility means an admin
does not have to start making big exceptions because a subset of
machines now start needing a different way to change it.
You can also add a blurb in inittab that says something about removing
the init line, and how this will activate the beautiful systemd
mechanism to handle runlevels.
- Then admins can choose which one to use.
- Does not break on upgrades
- Does not break anaconda and anaconda devs have the time to do the
change to stop installing an inittab in new installations while keeping
what is there working on updates without having to do special case
handle. Otherwise anaconda will have to care about handling this change
too on distro upgrades.
And so on.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11:12 a.m.
2010/7/15 Simo Sorce <ssorce(a)redhat.com>:
On Thu, 15 Jul 2010 16:59:40 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> Because it reverses everything.
And this is a problem because ?
> I.e. generally we have the rule that "native configuration breaks
> legacy configuration".
Who's "we", what is the rationale of this rule ? Looks like it is a
rule made to break things on upgrades. Most upstream I know have the
inverse rule. Do not break things unless it is *necessary*.
I do not see why it is necessary to break here.
> However, to make the inittab stuff useful we'd
> have to turn that around, and say that "legacy breaks native". Why?
> Because the /etc/systemd/system/default.target symlink is created by
> the rpm in all cases and would hence make the inittab ignored anyway.
>
> If I added inittab parsing support even when keeping "native breaks
> legacy" around, then inittab would matter only if the default.target
> symlink doesn't exist. We could certainly inform the user to delete
> that symlink, via some blurb in inittab, however, if he goes and
> deletes it, wouldn't it be much easier to just fix properly and to
> the right boot target, and have a future-proof system?
>
> i.e. isn't this:
>
> # vi /etc/inittab
> ... user reads the blurb and changes a line, exits
> # rm /etc/systemd/system/default.target
>
> really that much better in your eyes, than this:
>
> # vi /etc/inittab
> ... user reads the blurb, quits right-away
> # ln
> -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
>
> I don't think it is...
You are assuming a human is doing these changes, in many cases it is
install (kickstart) scripts. And keeping compatibility means an admin
does not have to start making big exceptions because a subset of
machines now start needing a different way to change it.
You can also add a blurb in inittab that says something about removing
the init line, and how this will activate the beautiful systemd
mechanism to handle runlevels.
- Then admins can choose which one to use.
- Does not break on upgrades
- Does not break anaconda and anaconda devs have the time to do the
change to stop installing an inittab in new installations while keeping
what is there working on updates without having to do special case
handle. Otherwise anaconda will have to care about handling this change
too on distro upgrades.
And so on.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
also there is the fact that current init scripts usually do alot
more... like adding configtest (a generic way of syntax checking
before trying to restart the daemon to avoid downtime with last minute
changes that cannot be tested on another machine for one way or
another...) and i also hope that this time restarting a service plays
nice with using cluster software (restarting returns exit 0 if the
daemon starts successful no matter if the shutdown failed.)
kind regards,
Rudolf Kastl
11:24 a.m.
On Thu, 2010-07-15 at 16:59 +0200, Lennart Poettering wrote:
I.e. generally we have the rule that "native configuration
breaks legacy
configuration".
You already said this, and I responded.
However, to make the inittab stuff useful we'd have to
turn that around, and say that "legacy breaks native". Why? Because the
/etc/systemd/system/default.target symlink is created by the rpm in all
cases and would hence make the inittab ignored anyway.
So ... don't do that.
It's like saying you have /etc/fstab support, but systemd currently
ships with "native unit files for swaps and mount points" so it doesn't
work.
If I added inittab parsing support even when keeping "native
breaks
legacy" around, then inittab would matter only if the default.target
symlink doesn't exist. We could certainly inform the user to delete that
symlink, via some blurb in inittab, however, if he goes and deletes it,
wouldn't it be much easier to just fix properly and to the right boot
target, and have a future-proof system?
i.e. isn't this:
# vi /etc/inittab
... user reads the blurb and changes a line, exits
# rm /etc/systemd/system/default.target
really that much better in your eyes, than this:
After the rm you can change the runlevel the same way on any version of
RHEL, Fedora, Debian, gentoo, whatever. Hence the term "backwards
compatible".
# vi /etc/inittab
... user reads the blurb, quits right-away
# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
You also seem to be under the impression that symlinks are somehow
better than config. files ... you are wrong, IMNSHO. The most obvious
reasons you are wrong include:
1. You can't have comments with a symlink.
2. You put the data under version control with a symlink.
3. You can type "man inittab", but not
"man /etc/systemd/system/default.target" (assuming you can find it).
...but I can live with that (hey, I don't configure gettys much
anyway ... so the configuration being insane doesn't impact ME).
The disregard for minimal backwards compat. does annoy me though. Given
it seems unlikely you'll fix any of it, so I think I shall go re-read:
http://skvidal.wordpress.com/2008/10/29/fedora-culture-clashes/
...and ignore this thread.
11:22 a.m.
On Thu, 15.07.10 01:58, James Antill (james(a)fedoraproject.org) wrote:
Sure, but this is not a case of you having to decide between
"do the
old thing forever" or "break it now".
Well the way I like to think of this is that Upstart already started the
work for us to make inittab obsolete and in fact succeeded in obseleting
almost all contents of it. And that happened some releases ago when
upstart was adopted. And now, after waiting those releases it is time to
let go the one remaining option as well.
You are asking to keep it around for a few more releases, that's the
only difference in argumentation i see here. And I guess we just have to
agree to disagree on how many releases this should be supported still.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:28 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
> Does it pull this from inittab if there's no other
configuration for
> this?
Ok. You got me on this one. Systemd does actually not parse the
inittab. That cruft looked a bit too ugly and clumsy and old for us to
support.
However, we have added replcacements for everything is was used
for. i.e. the gettys are started now via normal services.
The replacement for the default runlevel stuff is a symlink in
/etc/systemd/system. You could do this:
/etc/systemd/system/default.target → /lib/systemd/system/multi-user.target
to avoid the graphical UI, and boot into the text console only
(i.e. much like the old runlevel 3)
Or you could do this:
/etc/systemd/system/default.target → /lib/systemd/system/graphical.target
to boot into the graphical stuff by default. This is the default as we
package it.
And the admin could even define additional targets, to achieve different
system profiles he can boot into or switch forth and back to and from,
and give it arbitrary names, and even pull in any of the targets we ship
by default.
The issue is that this is a behavior change (from both sysvinit and upstart)
that will need code to be handled properly in other packages. Anaconda,
at least, will need to be patched to set the default bootup target
differently depending on which init system it's installing, which
is kind of ugly.
If I must ask, what's gained by the change in implementation and
nomenclature here? All of these existed before as runlevels, and at least
with sysvinit, the administrator could define their own custom ones.
Bill
3:24 p.m.
On Wed, 14.07.10 14:28, Bill Nottingham (notting(a)redhat.com) wrote:
> And the admin could even define additional targets, to achieve
different
> system profiles he can boot into or switch forth and back to and from,
> and give it arbitrary names, and even pull in any of the targets we ship
> by default.
The issue is that this is a behavior change (from both sysvinit and upstart)
that will need code to be handled properly in other packages. Anaconda,
at least, will need to be patched to set the default bootup target
differently depending on which init system it's installing, which
is kind of ugly.
Hmm, can you please elaborate on what you think anaconda should be
writing into that file?
Also, is there something easier then calling symlink(2)? Way easier than
patching config files at least...
If I must ask, what's gained by the change in implementation and
nomenclature here? All of these existed before as runlevels, and at least
with sysvinit, the administrator could define their own custom ones.
"Any customer can have a car painted any colour he wants so long as it
is black." -- Henry Ford, when he designed sysvinit.
sysvinit allows you to have exactly 4 general purpose runlevels, which
have the superbly descriptive names "2", "3", "4", and
"5". And that's
where the story ends. In systemd the model is much simpler, more obvious
yet more powerful: target units can be labeled freely and you can have
as many as you want.
On top of that they can be explicit supersets of other targets, and they
follow the same synchronization logic as any other unit. You can alias
targets (i.e. make them accessible under more than one name), and you
can even activate multiple of these at the same time (and this is
actually used by default, for example there is
"bluetooth.target"). Yippieh, yippieh, yeah!
You really cannot see why runlevels are old cruft and completely
arbitrary in their design and naming, and really need replacing?
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:34 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
> The issue is that this is a behavior change (from both sysvinit
and upstart)
> that will need code to be handled properly in other packages. Anaconda,
> at least, will need to be patched to set the default bootup target
> differently depending on which init system it's installing, which
> is kind of ugly.
Hmm, can you please elaborate on what you think anaconda should be
writing into that file?
ananconda is what sets the default runlevel post install. It does this
by editing inittab. This change would mean that anaconda would conditionally
need to do something else, depending on what it happens to be installing.
sysvinit allows you to have exactly 4 general purpose runlevels,
which
have the superbly descriptive names "2", "3", "4", and
"5". And that's
where the story ends. In systemd the model is much simpler, more obvious
yet more powerful: target units can be labeled freely and you can have
as many as you want.
It allows 7, 8, 9, as well. (Wheee, undocumented features.)
You really cannot see why runlevels are old cruft and completely
arbitrary in their design and naming, and really need replacing?
Oh, they are. But they're also 30+ years of historical precedent that
people are used to and code is expecting. Even OSX has them in some
manner.
Bill
4:14 p.m.
On Wed, 14.07.10 16:34, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> > The issue is that this is a behavior change (from both sysvinit and upstart)
> > that will need code to be handled properly in other packages. Anaconda,
> > at least, will need to be patched to set the default bootup target
> > differently depending on which init system it's installing, which
> > is kind of ugly.
>
> Hmm, can you please elaborate on what you think anaconda should be
> writing into that file?
ananconda is what sets the default runlevel post install. It does this
by editing inittab. This change would mean that anaconda would conditionally
need to do something else, depending on what it happens to be
installing.
Or it could just do both changes. That should be easy enough.
Hmm, I wasn't aware that Anaconda even asks a question about the
runlevel. Given that I am too lazy to try this out now, what exactly is
this question? i.e. does it ask "Are you installing a server or a
deskop?" or what does it ask?
> sysvinit allows you to have exactly 4 general purpose runlevels,
which
> have the superbly descriptive names "2", "3", "4", and
"5". And that's
> where the story ends. In systemd the model is much simpler, more obvious
> yet more powerful: target units can be labeled freely and you can have
> as many as you want.
It allows 7, 8, 9, as well. (Wheee, undocumented features.)
> You really cannot see why runlevels are old cruft and completely
> arbitrary in their design and naming, and really need replacing?
Oh, they are. But they're also 30+ years of historical precedent that
people are used to and code is expecting. Even OSX has them in some
manner.
And that's why we support them to a large degree, via compatiblity
targets "runlevel3.target" and similar. What we don't support is setting
their default choice with /etc/inittab. That's all.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:23 p.m.
Hmm, I wasn't aware that Anaconda even asks a question about the
runlevel. Given that I am too lazy to try this out now, what exactly is
this question? i.e. does it ask "Are you installing a server or a
deskop?" or what does it ask?
The default runlevel is inferred based upon packages installed and
method of installation:
if ts.dbMatch('provides', 'service(graphical-login)').count() and \
ts.dbMatch('provides', 'xorg-x11-server-Xorg').count() and \
anaconda.displayMode == 'g' and not flags.usevnc:
anaconda.desktop.setDefaultRunLevel(5)
Asking a question like this of the user would be kind of absurd.
- Chris
4:30 p.m.
On Wed, 14.07.10 17:23, Chris Lumens (clumens(a)redhat.com) wrote:
> Hmm, I wasn't aware that Anaconda even asks a question about the
> runlevel. Given that I am too lazy to try this out now, what exactly is
> this question? i.e. does it ask "Are you installing a server or a
> deskop?" or what does it ask?
The default runlevel is inferred based upon packages installed and
method of installation:
if ts.dbMatch('provides', 'service(graphical-login)').count() and \
ts.dbMatch('provides', 'xorg-x11-server-Xorg').count() and \
anaconda.displayMode == 'g' and not flags.usevnc:
anaconda.desktop.setDefaultRunLevel(5)
Asking a question like this of the user would be kind of absurd.
Well, if this is all this is about then I wonder why this is there
anyway? If no gdm is installed, then runlevel 5 and 3 should be
identical anyway, so what's the point of fixing the default runlevel
there?
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:42 p.m.
On Wed, 14 Jul 2010 23:30:44 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
Well, if this is all this is about then I wonder why this is there
anyway? If no gdm is installed, then runlevel 5 and 3 should be
identical anyway, so what's the point of fixing the default runlevel
there?
Because you may have gdm installed and not wish to currently boot with
it? I just tried systemd on a test machine here... it came up fine, but
it started gdm, even though I normally don't want it to do so.
How can I tell systemd not to boot in graphical?
rm /etc/systemd/system/default.target
ln
-s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
?
Perhaps someone could put together a wiki page for lazy sysadmins with
a Q&A? ie, I used to do this in upstart/sysvinit, how do I do it with
systemd?
Anyhow, the machine came up fine, so thats pretty nice compatibility
wise. ;)
kevin
4:50 p.m.
On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote:
Perhaps someone could put together a wiki page for lazy sysadmins
with
a Q&A? ie, I used to do this in upstart/sysvinit, how do I do it with
systemd?
Jóhann Guðmundsson (viking_ice) has been working on something along
these lines:
http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd
it was mentioned in the QA meeting a few weeks back.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:24 p.m.
On Wed, Jul 14, 2010 at 2:50 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote:
> Perhaps someone could put together a wiki page for lazy sysadmins with
> a Q&A? ie, I used to do this in upstart/sysvinit, how do I do it with
> systemd?
Jóhann Guðmundsson (viking_ice) has been working on something along
these lines:
http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd
it was mentioned in the QA meeting a few weeks back.
I have a few requests for things to add to that page :-)
* What replaces chkconfig
* What replaces /etc/init.d/SERVICENAME start | stop ?
Similarly, for packaging guidelines updates, how do we install
packages that provide services and have them not start up?
-Toshio
3:39 a.m.
>>>> "TK" == Toshio Kuratomi
<a.badger(a)gmail.com> writes:
TK> * What replaces chkconfig
TK> * What replaces /etc/init.d/SERVICENAME start | stop ?
If the answers aren't "chkconfig" and "service foo start" then I
fear
significant backlash from poor people who actually have to run F-14
systems. We pretty much have to keep them working, even if they have to
be packaged separately from systemd.
- J<
7:04 a.m.
On 07/21/2010 03:24 AM, Toshio Kuratomi wrote:
I have a few requests for things to add to that page :-)
* What replaces chkconfig
systemd-install
Now first the gotcha then I'll provide chkconfig replacement example.
Admins will need to know that they have to use chkconfig for services
that do not have a native systemd $service file. ( legacy for services )
And as the general rule goes "native configuration breaks legacy
configuration" so if a native systemd $service file does exist than
changing service via chkconfig no longer will work.
Now the systemd developers could add a little pony to speed up adoption
and prevent potential chkconfig Admin/User fiasco by simply letting
systemd-install fallback to chkconfig if it finds no native service file
in /lib/systemd/system/ with msg to stdout asking Admins to file a bug
against a given missing service.
Admins/Users could then stop using chkconfig and use systemd-install
only instead which would speed up adobtion
Systemd-install examples ( see man page for detail list of options )
To see running targets on your system.
systemctl list-units --type=target
To see all available running targets on your system.
systemctl list-units --type=target --all
To see which native systemd system files exist on your installed system
ls /lib/systemd/system/
To enable service ( chkconfig $service on )
systemd-install enable $service.service
To disable service ( chkconfig $service off )
systemd-install disable $service.service
To enable service and start it ( chkconfig $service on && service
$service start )
systemd-install --realize=yes enable $service.service
To always start service on boot instead of when a connection comes in or
some hardware is plugged in.
ln -sf /lib/systemd/system/foobar.service
/etc/systemd/system/multi-user.target.wants/foobar.service
Remember to reload the systemd manager
systemctl daemon-reload
So to enable avahi-daemon
systemd-install enable avahi-daemon.service
To disable avahi-daemon
systemd-install disable avahi-daemon.service
To enable avahi-daemon and start it
systemd-install --realize=yes enable avahi-daemon.service
To always start avahi-daemon on boot
ln -sf /lib/systemd/system/avahi-daemon.service
/etc/systemd/system/multi-user.target.wants/avahi-daemon.service
Reload the systemd manager
systemctl daemon-reload
* What replaces /etc/init.d/SERVICENAME start | stop ?
systemctl.
systemctl examples ( sem man pages for detail list of options )
Replacing traditional /sbin/service with systemctl
To list running services
systemctl list-units --type=service
To list all available services
systemctl list-units --type=service --all
To start a service
systemctl start $foo.service
To stop a service
systemctl stop $foo.service
To reload a service .conf file.
systemctl reload $foo.service
To restart a service
systemctl restart $foo.service
To show service status ( Admins should love the output from this )
systemctl status $foo.service
Using Apache as an example
Starting Apache
systemctl start httpd.service
Stopping Apache
systemctl stop httpd.service
Reloading httpd.conf
systemctl reload httpd.service
Restarting Apache
systemctl restart httpd.service
To check if Apache is running
systemct status httpd.service
I will add this ( and more ) to the page soon as can.
8:14 a.m.
Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com> said:
And as the general rule goes "native configuration breaks legacy
configuration" so if a native systemd $service file does exist than
changing service via chkconfig no longer will work.
As an admin, this is crap. Where does this "general rule" come from?
As strong desire to piss off the people that actually use your software?
Frankly, if all this systemd goes in as announced here, I don't see
myself using Fedora much longer (and if this lands in RHEL 7, I'll be
switching my company systems as well).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:16 a.m.
On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> said:
> And as the general rule goes "native configuration breaks legacy
> configuration" so if a native systemd $service file does exist than
> changing service via chkconfig no longer will work.
As an admin, this is crap. Where does this "general rule" come from?
As strong desire to piss off the people that actually use your software?
So "different == crap" ?
If it does provide a hard to use interface I'd understand the
frustration but only because it is NEW / DIFFERENT does not mean that
the world is falling over.
Seriously an admin that refuses to learn anything new ("omg it isn't
the same as I have been doing for the last 10 years) he should really
consider changing job / profession.
Changes aren't bad for the sole reasons of being changes.
If the new interface is crap ok complain about it but it being
different (as long as it is documented) is a non issue IMO.
10:29 a.m.
Once upon a time, drago01 <drago01(a)gmail.com> said:
On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams
<cmadams(a)hiwaay.net> wrote:
> Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
said:
>> And as the general rule goes "native configuration breaks legacy
>> configuration" so if a native systemd $service file does exist than
>> changing service via chkconfig no longer will work.
>
> As an admin, this is crap. Where does this "general rule" come from?
> As strong desire to piss off the people that actually use your software?
So "different == crap" ?
Different for no good reason (other than to break legacy configuration)
is crap. Providing multiple interfaces, one to manage some services and
one to manage the others, is major crap.
Seriously an admin that refuses to learn anything new ("omg it
isn't
the same as I have been doing for the last 10 years) he should really
consider changing job / profession.
This isn't about managing one system; it's about managing lots of
systems and now one is different (but only for some services, who knows
which) for no good reason.
Changes aren't bad for the sole reasons of being changes.
Change for the sake of change is always a bad sign of "let's reinvent
the wheel". How hard would it be to provide backwards-compatible
chkconfig and service commands?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:13 p.m.
On Wed, Jul 21, 2010 at 10:29:40AM -0500, Chris Adams wrote:
Different for no good reason (other than to break legacy
configuration)
is crap.
Plus one million to this, by the way.
Providing multiple interfaces, one to manage some services and one
to
manage the others, is major crap.
*nod*
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:47 a.m.
On Wed, 2010-07-21 at 17:16 +0200, drago01 wrote:
On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams
<cmadams(a)hiwaay.net> wrote:
> Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
said:
>> And as the general rule goes "native configuration breaks legacy
>> configuration" so if a native systemd $service file does exist than
>> changing service via chkconfig no longer will work.
>
> As an admin, this is crap. Where does this "general rule" come from?
> As strong desire to piss off the people that actually use your software?
So "different == crap" ?
If it does provide a hard to use interface I'd understand the
frustration but only because it is NEW / DIFFERENT does not mean that
the world is falling over.
In general, yes, it does (just not to you):
http://skvidal.wordpress.com/2008/10/29/fedora-culture-clashes/
...however this case (breaking service/chkconfig) seems like such a huge
pointless difference that I can't imagine RHEL-7 not requiring that it's
fixed. So the only real question is how long Fedora users have to live
with it broken.
1:05 p.m.
On Wed, Jul 21, 2010 at 5:47 PM, James Antill <james(a)fedoraproject.org> wrote:
On Wed, 2010-07-21 at 17:16 +0200, drago01 wrote:
> On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams <cmadams(a)hiwaay.net> wrote:
> > Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
said:
> >> And as the general rule goes "native configuration breaks legacy
> >> configuration" so if a native systemd $service file does exist than
> >> changing service via chkconfig no longer will work.
> >
> > As an admin, this is crap. Where does this "general rule" come from?
> > As strong desire to piss off the people that actually use your software?
>
> So "different == crap" ?
>
> If it does provide a hard to use interface I'd understand the
> frustration but only because it is NEW / DIFFERENT does not mean that
> the world is falling over.
In general, yes, it does (just not to you):
I though we where talking about *admins* here not $grandma ...
And when I say/here admin I'd expect to be talking about a human (not
some kind of robot that has hardwired commands and can't adapt to
changes).
1:29 p.m.
Once upon a time, drago01 <drago01(a)gmail.com> said:
And when I say/here admin I'd expect to be talking about a human
(not
some kind of robot that has hardwired commands and can't adapt to
changes).
If you only have to manage one system, good for you. I have to manage a
bunch, and everything that is different _for_no_good_reason_ between
them is a PITA. Yes, management scripts can be adapted, but now they
have to handle systems A-Z one way, systems AA-ZZ another (but
apparently not for all services, try to guess which?). That makes an
admin unhappy and less likely to deploy any more of systems type AA-ZZ.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
6:18 p.m.
On Wed, 21.07.10 13:29, Chris Adams (cmadams(a)hiwaay.net) wrote:
Once upon a time, drago01 <drago01(a)gmail.com> said:
> And when I say/here admin I'd expect to be talking about a human (not
> some kind of robot that has hardwired commands and can't adapt to
> changes).
If you only have to manage one system, good for you. I have to manage a
bunch, and everything that is different _for_no_good_reason_ between
them is a PITA. Yes, management scripts can be adapted, but now they
have to handle systems A-Z one way, systems AA-ZZ another (but
apparently not for all services, try to guess which?). That makes an
admin unhappy and less likely to deploy any more of systems type AA-ZZ.
BTW, you are emphasizing that that there was no reason for the stfuf we
do. But you are wrong. There actually is. The reason why we came up with
systemd-install as a counterpart of chkconfig instead of patching
chkconfig is that it actually works very very differently from
it. i.e. beyond the fact that both create symlinks, one in
/etc/systemd/system, the other in /etc/rcN.d/ they have very little in
common. One cares about priorities, the other doesn't. One knows only 6
runelvels, the other knows arbitrary numbers of targets. One can hook
stuff into runlevels and runlevels only; the other can hook stuff into
any unit. One can actually make the changes effetive immediately, the
other doesn't do that; one can handle sockets and mounts and other kind
of units, the other cannot; and so on and so on.
Yes, they are counterparts in some way, but they nevertheless are very
differnt in what they do. Which is why we chose not to hack the old tool
to make the it half work on the new system, but came up with a new tool.
Of course, there's a solution between "transparently" and "different
tool", which is to warn the user loudly and make suggestions what to do
instead if he uses the old tool, and possibly even execute the
suggestion right away if the semantics for that one call are close
enough to what the user intended. And that's what I added to my todo
list and Jef thankfully offered to implement.
We are trying to find a way here between radical new designs, and
staunch interface conservatism. i.e. we innovate and carefully try to
select the stuff we want to keep around and leave out the stuff whose
end has come. That naturally means that we do things on middle grounds,
not on extremes. We won't do 100% compat with sysv, but we won't do 0%
either. And that being the way it is I can only ask people to be a bit
more conisderate in their positions. i.e. people whining on the mailing
list that they will leave Fedora just because chkconfig might be not as
100% supported as they wish it was don't really help and don't see the
big picture. Because the big picture will tell you that we keep
incomparably more stuff in then we remove. For example, we provide
compatibility with /dev/initctl, with sysv init scripts, with LSB init
script headers, with chkconfig init script headers, with the various
sysv client tools, with the kernel command line options, with the
signals we take, with /etc/fstab and more.
So, please, when Jef finishes his work, or I find the time to, we will
provide chkconfig compat too (at least to a certain degree). However,
doing this is actually just the cherry on top of the topping of our
delicous cake. But even without the cherry it still would be very yummy
and still have topping.
Or in short: extremism sucks. Please acknoweledge that we try to find a
middle ground, and that we are open for suggestions. Because we are. I
already fixed a couple of issues that were discussed on this mailing
list and added a couple more to my todo list. I won't make everybody
happy, but you have a bigger chance to get your suggestion heard if you
don't take extremist positions, declare sysv the holy grail and say
you'll abandon Fedora if we depart from that.
Yes, I guess being a developer who develops new stuff I like innovation
in interfaces more than administrators who then might end up using
this. But it doesn't really help claiming we had no idea what admins
want and consistently ignore their wishes. Because we actually do have a
pretty good idea. We don't fully share all opinions, but we are aware more
often than not.
Also, one last thing: there's so much in systemd that admins should
really love. It would be great to sometimes look on the bright side of
things. One small and random example, just to make a point: Look how
awesome the output of "systemctl status avahi-daemon.service" is:
<snip>
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
Active: active (running)
Main: 6841 (avahi-daemon)
Status: "Server startup complete. Host name is lambda.local. Local service cookie
is 813782141."
CGroup: name=systemd:/systemd-1/avahi-daemon.service
├ 6841 avahi-daemon: running [lambda.local]
└ 6842 avahi-daemon: chroot helper
</snip>
It shows you all processes that belong to a service (in a tree
actually), something that was previously impossible to figure out. It
gives you a nice status string of the daemon. It tells you the
cgroup. It tells you that everything is OK. When it fails, it weill tell
you the exit code/status and stuff. It's just really really handy for
administrative work, and it
gives you a lot of information that was previously lost entirely:
processes could just vanish from sight and their exit codes were
completely lost. Now, tell me, as an admin, wouldn't you agree that it
is kinda amazing that for so long you managed to survive without all
that information? And that we now offer this to you is long long
overdue?
Solaris SMF had something like this for a long time, and much like for
ZFS and dtrace those Solaris admins always made fun of us Linux folks
that we still lacked all these toys. And now finally we provide
something equally useful. So as an admin you should really love systemd,
-- not hate it just because it does a few things differently.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:13 p.m.
On Thu, Jul 22, 2010 at 01:18:09AM +0200, Lennart Poettering wrote:
BTW, you are emphasizing that that there was no reason for the stfuf
we
do. But you are wrong. There actually is. The reason why we came up with
systemd-install as a counterpart of chkconfig instead of patching
chkconfig is that it actually works very very differently from
it. i.e. beyond the fact that both create symlinks, one in
/etc/systemd/system, the other in /etc/rcN.d/ they have very little in
common. One cares about priorities, the other doesn't. One knows only 6
runelvels, the other knows arbitrary numbers of targets. One can hook
stuff into runlevels and runlevels only; the other can hook stuff into
any unit. One can actually make the changes effetive immediately, the
other doesn't do that; one can handle sockets and mounts and other kind
of units, the other cannot; and so on and so on.
It appears that you're looking at this from the point of view of chkconfig
as a tool which causes certain manipuations of the system to happen
(symlinks changed). That's the backwards approach. Look at it from the other
side: it is a user-interface for changing under what conditions certain
services run. Then extend that user interface to fit the new capabilities
that you're adding.
Yes, they are counterparts in some way, but they nevertheless are
very
differnt in what they do. Which is why we chose not to hack the old tool
to make the it half work on the new system, but came up with a new tool.
They're different in the particulars. They're the same in purpose.
Of course, there's a solution between "transparently"
and "different
tool", which is to warn the user loudly and make suggestions what to do
instead if he uses the old tool, and possibly even execute the
So, making an annoying warning here is really an option of last resort. If
your goal is to antagonize and annoy your audience, it's a good approach,
but I'm pretty sure that's not your intention. Think I'm kidding or
exaggerating? Look at the horrible mess with the message from nslookup (I
still hear people complain about that from time to time -- and still use
nslookup!)
more conisderate in their positions. i.e. people whining on the
mailing
list that they will leave Fedora just because chkconfig might be not as
100% supported as they wish it was don't really help and don't see the
big picture. Because the big picture will tell you that we keep
I didn't see anyone saying that they will leave Fedora. However, in my job,
I see Fedora increasingly sidelined for any serious use -- and it's not just
because of some other distro's mindshare. Fedora is important to me and I've
been involved for a long time, and I dislike seeing this happen, so it's
frustrating to have legitimate concerns rudely tossed aside as not seeing
the big picture -- when, in fact, the big picture *is the problem*.
Also, one last thing: there's so much in systemd that admins
should really
love. It would be great to sometimes look on the bright side of things.
Sure. I don't love sysv init. It sucks in a whole multitude of ways. And I'm
not really sold on upstart or any of the other replacements either. Systemd
looks interesting, which is why I'm bothering to comment in the first place
rather than just taking the "make it stop! make it stop!" line.
One small and random example, just to make a point: Look how awesome
the
output of "systemctl status avahi-daemon.service" is:
<snip>
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
Active: active (running)
Main: 6841 (avahi-daemon)
Status: "Server startup complete. Host name is lambda.local. Local service cookie
is 813782141."
CGroup: name=systemd:/systemd-1/avahi-daemon.service
├ 6841 avahi-daemon: running [lambda.local]
└ 6842 avahi-daemon: chroot helper
</snip>
So, um. This is not so awesome, because for logged output, the multi-line
format makes it hard to parse. And for human-readable output, it's got the
opposite problem: it's more than 80 columns, and it's very verbose,
burying the answer I want (is the thing running?) in the middle of the
paragraph, while telling me many things I probably don't care about.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:49 p.m.
On Wed, 21.07.10 20:13, Matthew Miller (mattdm(a)mattdm.org) wrote:
It appears that you're looking at this from the point of view of
chkconfig
as a tool which causes certain manipuations of the system to happen
(symlinks changed). That's the backwards approach. Look at it from the other
side: it is a user-interface for changing under what conditions certain
services run. Then extend that user interface to fit the new capabilities
that you're adding.
Well, the chkconfig tool is actually a tool which is way more than a
dumbed-down access utility to the /etc/rcX.d/ symlink farms. What its
implementation actually does is defined very much in detail and for
example documented in the man page, to the last bit. In other words: it
is *NOT* an implementation detail what exactly it does to enable/disable
a service. In fact the interface to chkconfig is defined on a multitude
of levels, not only the mere command line arguments. For example we have
chkconfig headers in all init scritps which are part of the api of
chkconfig.
This is for example very different from let's say the sysv
"/sbin/reboot" command whose semantics are pretty well known and trivial
to understand. It is easy to reimplement that command on top of a
different system. But chkconfig? Not so much if you have neither rcN.d
links, priorities, nor S or K links -- nor even init scripts at all.
The logic behind chkconfig is exposed in many ways in the user
interface, for example in the chkconfig command line, e.g.
commands such as "resetpriorities", and stuff like that.
> One small and random example, just to make a point: Look how
awesome the
> output of "systemctl status avahi-daemon.service" is:
>
> <snip>
> avahi-daemon.service - Avahi mDNS/DNS-SD Stack
> Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
> Active: active (running)
> Main: 6841 (avahi-daemon)
> Status: "Server startup complete. Host name is lambda.local. Local service
cookie is 813782141."
> CGroup: name=systemd:/systemd-1/avahi-daemon.service
> ├ 6841 avahi-daemon: running [lambda.local]
> └ 6842 avahi-daemon: chroot helper
> </snip>
So, um. This is not so awesome, because for logged output, the multi-line
format makes it hard to parse. And for human-readable output, it's got the
opposite problem: it's more than 80 columns, and it's very verbose,
burying the answer I want (is the thing running?) in the middle of the
paragraph, while telling me many things I probably don't care about.
Jeez. I guess you cannot be helped. I guess it doesn't help in any way
here to mention that we were two steps ahead of you here and provide
"systemctl show" which can be used to introspect systemd units in all
details and properties in a parsable way. Also, we added "systemctl check"
which prints a one line super-short status.
But anyway, I give up. If you keep looking long enough you'll find
something you don't like in everything.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:59 p.m.
On Wed, Jul 21, 2010 at 19:49, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 21.07.10 20:13, Matthew Miller (mattdm(a)mattdm.org) wrote:
But anyway, I give up. If you keep looking long enough you'll find
something you don't like in everything.
If this is how you normally deal with problems, I am beginning to
understand why pulseaudio has had such a bad reputation. A) You read
everything that matt said as a personal attack of trying to find deep
fault and then you go off in a temper tantrum. None of that is going
to make things easier and pretty much sets this whole project up as a
big FAIL because the people who have to buy into it as it affects them
the most are now all lumped in as whiners.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
7:29 a.m.
Once upon a time, Stephen John Smoogen <smooge(a)gmail.com> said:
If this is how you normally deal with problems, I am beginning to
understand why pulseaudio has had such a bad reputation. A) You read
everything that matt said as a personal attack of trying to find deep
fault and then you go off in a temper tantrum. None of that is going
to make things easier and pretty much sets this whole project up as a
big FAIL because the people who have to buy into it as it affects them
the most are now all lumped in as whiners.
This is a part of my dissatisfaction with systemd. We're told that this
new all-powerful tool will make everything better, and we'd better like
it, just the way pulseaudio was "introduced". At least with PA, you
could remove it, but with systemd, there's really no going back.
I guess part of it is that I don't see what's so great about merging
init and inetd. Some of the features of systemd sound nice, but I'm not
sure they're worth the rest of the "fun" of a major switch like this.
I'm not exactly happy with Lennart's development "style" (for lack of a
better word). I can't get a PC speaker beep out of an xterm (so now I
have to have sound configured and speakers just to get a terminal bell),
and Lennart's response to that was just that the PC speaker should go
away anyway. Even with speakers, I could only get one bell per second,
which Lennart finally fixed, but only in rawhide (because he doesn't
like to backport patches).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:13 p.m.
On Thu, Jul 22, 2010 at 03:49:21AM +0200, Lennart Poettering wrote:
The logic behind chkconfig is exposed in many ways in the user
interface, for example in the chkconfig command line, e.g.
commands such as "resetpriorities", and stuff like that.
I think having some level of command-line user-interface compatiblity,
even if not 100%, is important. "resetpriorities" is probably so
rarely used that the systemd version of chkconfig could probably just
make it a no-op (unless it was dealing with old sysvinit scripts, in
which case it could probably just call through to the old chkconfig).
But for basics such as "chkconfig service on|off|--list", there should
be compatibility. Runlevels could perhaps be dealt with by mapping
the common cases like 3,5 to the multiuser-target, graphical-target,
etc. Likewise for "service foo start|stop|reload|condrestart" etc.
Jeez. I guess you cannot be helped. I guess it doesn't help in
any way
here to mention that we were two steps ahead of you here and provide
"systemctl show" which can be used to introspect systemd units in all
details and properties in a parsable way. Also, we added "systemctl check"
which prints a one line super-short status.
Well, there is some merit in the already stated argument for having
good UI design. In this example, you could have used long-standing
precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N)
arguments instead of "status" "show" "check". Now
you've created new
lore of needing to know when to use "status" vs. "show" vs.
"check",
what the differences are between them, and what their order of
increasing verbosity is.
But anyway, I give up. If you keep looking long enough you'll
find
something you don't like in everything.
Please don't give up. I think most of this is valid criticism that
should be voiced, but that doesn't imply that the overall architecture
and implementation of systemd isn't great. I like most of what I see,
but I do cringe at some of the command, argument, and option naming
choices that were made. And I think it is asking too much for users
to have to know to use systemd-install for some things and
chkconfig/service for others, not to mention needing to update all the
RPM spec files for new scriptlets, or fixing anaconda to know when to
call which (I'm guessing that anaconda might call chkconfig or
service, but don't know for sure. Are you sure you know where all the
skeletons are hiding?)
9:42 p.m.
On Wed, 21.07.10 22:13, Chuck Anderson (cra(a)WPI.EDU) wrote:
On Thu, Jul 22, 2010 at 03:49:21AM +0200, Lennart Poettering wrote:
> The logic behind chkconfig is exposed in many ways in the user
> interface, for example in the chkconfig command line, e.g.
> commands such as "resetpriorities", and stuff like that.
I think having some level of command-line user-interface compatiblity,
even if not 100%, is important. "resetpriorities" is probably so
rarely used that the systemd version of chkconfig could probably just
make it a no-op (unless it was dealing with old sysvinit scripts, in
which case it could probably just call through to the old chkconfig).
But for basics such as "chkconfig service on|off|--list", there should
be compatibility. Runlevels could perhaps be dealt with by mapping
the common cases like 3,5 to the multiuser-target, graphical-target,
etc. Likewise for "service foo start|stop|reload|condrestart" etc.
As mentioned multiple times this is actually what happens all over the
place. We support the runlevels on the kernel command lines, and init
scripts are "redirected" to systemctl as soon as
https://bugzilla.redhat.com/show_bug.cgi?id=612728
is merged. And it is on my todo list to add something similar here for
chkconfig, and Jef offered to implement this.
This discussion was was mostly about whether to make this completely
transparent or not. And in contrast to the support for /sbin/reboot and
stuff I was and still am arguing that in the case of the init scripts
and chkconfig while we might execute something that is mostly equivalent
what the user asked for we still should warn him, that this is not fully
equivalent what used to be done. OTOH /sbin/reboot and suchlike are
fully and transparently supported by systemd and there's no reason to
push him to use anything else.
> Jeez. I guess you cannot be helped. I guess it doesn't help
in any way
> here to mention that we were two steps ahead of you here and provide
> "systemctl show" which can be used to introspect systemd units in all
> details and properties in a parsable way. Also, we added "systemctl
check"
> which prints a one line super-short status.
Well, there is some merit in the already stated argument for having
good UI design. In this example, you could have used long-standing
precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N)
arguments instead of "status" "show" "check". Now
you've created new
lore of needing to know when to use "status" vs. "show" vs.
"check",
what the differences are between them, and what their order of
increasing verbosity is.
Well, I think good UI means that you distuingish computer parsable and
human readable tools. "status" is human readable.
"show"/"check" are
computer-parsable.
Human-readable stuff we want to indent and ellipsize to make it easily
readable. Computer-parsable stuff should be neither.
And that's why came up with two commands (and added a third one which is
the same as the other one, but treats the runlevel specially).
Or to turn this around: many folks parse the output of ifconfig. And
that's just wrong on so many levels. We try to do better and actually
provide you with a proper interface for people who want to parse our
output.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:18 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
Or to turn this around: many folks parse the output of ifconfig. And
that's just wrong on so many levels. We try to do better and actually
provide you with a proper interface for people who want to parse our
output.
For a counter-example: the LVM2 commands output human readable info by
default, but have a -C argument to output colon separated info instead.
There isn't a "vgdisplay", "vgshow", etc., each showing similar
info but
in different formats.
Having multiple, similar-named commands will only result in admin
frustration as they run each one they remember in turn until they get
the output they need. The command set needs to be as simple as
possible, with arguments to adjust behavior (e.g. -v for verbose/more
info, -vv for even more info, -C for parseable output, --now to make a
change take effect immediately).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:36 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
[...]
Well, I think good UI means that you distuingish computer parsable
and
human readable tools. "status" is human readable.
"show"/"check" are
computer-parsable.
Mildly disagree. It is nice to be able to remember from people-use what the
output looks like when computer-parsing it. It is nasty if you have to
remember that foo(1)'s output is for human consumption, while scripts
should use bar(8). People will just go ahead and use foo(1), while bitching
all the time about its nasty format. Here find(1) shows a nice compromise:
You can make it spit out stuff in computer-friendlier format, but the
result is not _too_ far removed from its regular output.
Human-readable stuff we want to indent and ellipsize to make it
easily
readable.
If it is text meant to be read rarely. But when you get used to some tool
(we aren't talking Aunt Tillie here!) the fact that (due to indentation,
text flowing and such) the one word you are looking for now has to be
searched for in random text doesn't help a bit. I.e., it is fine for
ps(1)'s manpage to be formatted for prettyness, it definitely isn't for
ps(1)'s output.
Computer-parsable stuff should be neither.
It must be easily readable anyway! Best part is that if done right, you
don't get to maintain several programs ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
6:46 p.m.
On Thu, 22.07.10 16:36, Horst H. von Brand (vonbrand(a)inf.utfsm.cl) wrote:
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
[...]
> Well, I think good UI means that you distuingish computer parsable and
> human readable tools. "status" is human readable.
"show"/"check" are
> computer-parsable.
Mildly disagree. It is nice to be able to remember from people-use what the
output looks like when computer-parsing it. It is nasty if you have to
remember that foo(1)'s output is for human consumption, while scripts
should use bar(8). People will just go ahead and use foo(1), while bitching
all the time about its nasty format. Here find(1) shows a nice compromise:
You can make it spit out stuff in computer-friendlier format, but the
result is not _too_ far removed from its regular output.
Same with systemd. If you use "systemctl status foo.service" the output
is human readable. If it is "systemctl show foo.service" it is computer
parsable. Just a slightly different command of the systemctl tool.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:06 p.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
Same with systemd. If you use "systemctl status
foo.service" the output
is human readable. If it is "systemctl show foo.service" it is computer
parsable. Just a slightly different command of the systemctl tool.
Again: this is confusing! There should be one (and only one) command to
show information. It should accept arguments to modify that output,
e.g. default to brief info, -v gets a little more info, -vv gets all
kinds of info, -p to get "parseable" output (or -f for "formatted"),
etc.
Having "status" and "show" give the same info in different formats
will
always be confusing. People won't remember which is which (because the
works mean similar things in this context) and will run the wrong one
for what they want about 50% of the time (which will just be
frustrating).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
7:16 p.m.
On Thu, Jul 22, 2010 at 18:06, Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> Same with systemd. If you use "systemctl status foo.service" the output
> is human readable. If it is "systemctl show foo.service" it is computer
> parsable. Just a slightly different command of the systemctl tool.
Again: this is confusing! There should be one (and only one) command to
show information. It should accept arguments to modify that output,
e.g. default to brief info, -v gets a little more info, -vv gets all
kinds of info, -p to get "parseable" output (or -f for "formatted"),
etc.
Having "status" and "show" give the same info in different formats
will
always be confusing. People won't remember which is which (because the
works mean similar things in this context) and will run the wrong one
for what they want about 50% of the time (which will just be
frustrating).
To reword this into a slightly less cranky more useful comment:
My usual dealing with this is that you want one command and an
optional flag to change output.
systemctl status # awk readable
systemctl status --human # human readable
The general rule to remember is that the person you are going to deal
with is going to be tired, grumpy, and pissed off. Commands need to be
simple to remember and easy to script first.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
8:01 p.m.
On Thu, 22.07.10 18:16, Stephen John Smoogen (smooge(a)gmail.com) wrote:
On Thu, Jul 22, 2010 at 18:06, Chris Adams <cmadams(a)hiwaay.net> wrote:
> Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
>> Same with systemd. If you use "systemctl status foo.service" the
output
>> is human readable. If it is "systemctl show foo.service" it is
computer
>> parsable. Just a slightly different command of the systemctl tool.
>
> Again: this is confusing! There should be one (and only one) command to
> show information. It should accept arguments to modify that output,
> e.g. default to brief info, -v gets a little more info, -vv gets all
> kinds of info, -p to get "parseable" output (or -f for
"formatted"),
> etc.
>
> Having "status" and "show" give the same info in different
formats will
> always be confusing. People won't remember which is which (because the
> works mean similar things in this context) and will run the wrong one
> for what they want about 50% of the time (which will just be
> frustrating).
>
To reword this into a slightly less cranky more useful comment:
My usual dealing with this is that you want one command and an
optional flag to change output.
systemctl status # awk readable
systemctl status --human # human readable
The general rule to remember is that the person you are going to deal
with is going to be tired, grumpy, and pissed off. Commands need to be
simple to remember and easy to script first.
Note again that the two commands show different data. "status" actually
shows only what the name suggests, i.e. the runtime status. OTOH "show"
allows you to introspect the unit in much more detailed ways, allows you
to query and show every tiny property. For example you can use it to
query the PID file of a unit, or the RLIMIT_NOFILE resource limit
configured for the unit, or the capability bounding set, or whether the
unit was started with a private, poly-instantiated /tmp, or, or, or.
Anyway, it would be really cool if could discuss this when everybody
actually had a look on the tool, and played around with this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:54 p.m.
On Thu, 22.07.10 19:06, Chris Adams (cmadams(a)hiwaay.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
> Same with systemd. If you use "systemctl status foo.service" the output
> is human readable. If it is "systemctl show foo.service" it is computer
> parsable. Just a slightly different command of the systemctl tool.
Again: this is confusing! There should be one (and only one) command to
show information. It should accept arguments to modify that output,
e.g. default to brief info, -v gets a little more info, -vv gets all
kinds of info, -p to get "parseable" output (or -f for "formatted"),
etc.
"show" actually gives you full access to all properties of a
service. It's a long list. It gives you runtime parameters as well as
the stuff you configured in your unit file or which was implied form the
defaults. It is also sometimes a little bit too much for people to
grasp, since for example it shows the full set of dependencies that are
implicitly added to most services. We certainly don't want to show this
to our users most of the time.
So, "show" is very verbose. On the other hand "status" is pretty
short. It only shows runtime information and that in a hightly reduced
way. For example fields are suppressed depending on the state of the
unit and other fields are shown, and then shows the process tree for
this. It also ellipsizes and aligns the output, and applies coloring (in
case the unit is in some 'maintenance' state, i.e. crashed, exited with
non-zero exit code, timed out, yadda yadda).
I think the differences between the two commands are sufficiently big to
warrant the two seperate commands.
Having "status" and "show" give the same info in
different formats will
always be confusing. People won't remember which is which (because the
works mean similar things in this context) and will run the wrong one
for what they want about 50% of the time (which will just be
frustrating).
You are discussing something you never actually played around
with...
Trust me, the output of the two commands is sufficiently different to
not confuse anybody.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:01 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/22/2010 05:54 PM, Lennart Poettering wrote:
So, "show" is very verbose. On the other hand
"status" is pretty
short. It only shows runtime information and that in a hightly reduced
way. For example fields are suppressed depending on the state of the
unit and other fields are shown, and then shows the process tree for
this. It also ellipsizes and aligns the output, and applies coloring (in
case the unit is in some 'maintenance' state, i.e. crashed, exited with
non-zero exit code, timed out, yadda yadda).
I think the differences between the two commands are sufficiently big to
warrant the two seperate commands.
In this case, I'd consider using "describe". Describe sounds quite a
bit more like a full listing of something, rather than a quick status.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxI6dYACgkQ4v2HLvE71NUByQCcDlej/YYT1GtLvv0ROWRgAUWb
3usAoIr2dgUuoOa0dnLwYNxP1WXK80Lk
=oB0b
-----END PGP SIGNATURE-----
9:05 p.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
Trust me, the output of the two commands is sufficiently different
to
not confuse anybody.
It isn't the output that is confusing, it is the names. "show" and
"status" are just too close, and people are not going to remember which
is which.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:22 p.m.
On Thu, 2010-07-22 at 19:06 -0500, Chris Adams wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> Same with systemd. If you use "systemctl status foo.service" the output
> is human readable. If it is "systemctl show foo.service" it is computer
> parsable. Just a slightly different command of the systemctl tool.
Again: this is confusing! There should be one (and only one) command to
show information. It should accept arguments to modify that output,
e.g. default to brief info, -v gets a little more info, -vv gets all
kinds of info, -p to get "parseable" output (or -f for "formatted"),
etc.
Having "status" and "show" give the same info in different formats
will
always be confusing. People won't remember which is which (because the
works mean similar things in this context) and will run the wrong one
for what they want about 50% of the time (which will just be
frustrating).
I agree with Chris here, I find the 'one command, with modifying
parameters' paradigm much the easiest to follow.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:37 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 16:36, Horst H. von Brand (vonbrand(a)inf.utfsm.cl)
wrote:
> Lennart Poettering <mzerqung(a)0pointer.de> wrote:
>
> [...]
>
> > Well, I think good UI means that you distuingish computer parsable and
> > human readable tools. "status" is human readable.
"show"/"check" are
> > computer-parsable.
>
> Mildly disagree. It is nice to be able to remember from people-use what the
> output looks like when computer-parsing it. It is nasty if you have to
> remember that foo(1)'s output is for human consumption, while scripts
> should use bar(8). People will just go ahead and use foo(1), while bitching
> all the time about its nasty format. Here find(1) shows a nice compromise:
> You can make it spit out stuff in computer-friendlier format, but the
> result is not _too_ far removed from its regular output.
Same with systemd. If you use "systemctl status
foo.service" the output
is human readable. If it is "systemctl show foo.service" it is computer
parsable. Just a slightly different command of the systemctl tool.
Better make that a --parseable (or -C, or --format=<gibberish>) flag for
the _same_ (sub)command. Look at rpm or git for examples ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
12:33 p.m.
On 07/21/2010 10:42 PM, Lennart Poettering wrote:
On Wed, 21.07.10 22:13, Chuck Anderson (cra(a)WPI.EDU) wrote:
>
> Well, there is some merit in the already stated argument for having
> good UI design. In this example, you could have used long-standing
> precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N)
> arguments instead of "status" "show" "check". Now
you've created new
> lore of needing to know when to use "status" vs. "show" vs.
"check",
> what the differences are between them, and what their order of
> increasing verbosity is.
Well, I think good UI means that you distuingish computer parsable and
human readable tools. "status" is human readable.
"show"/"check" are
computer-parsable.
I would recommend having 'status' maintain the same semantics as
'service foo status'. The new names aren't sufficiently more
understandable to warrant breaking from long established naming scheme IMO.
Generally I think maintaining similar CLI behavior with 'service' for
common functionality is a good thing. Which situation is more desirable?
Situation 1:
Ted: "I heard systemctl is kind of replacing service..."
# systemctl libvirtd status
Unknown command 'libvirtd'
Ted: "Huh? Oh, must need command first"
# systemctl status libvirtd
Could not find unit '/etc/systemd/libvirtd'
Ted: "Whaa? <looks in /etc> I guess I need to specify the whole file?"
# systemctl status libvirtd.service
<semi-verbose output>
Ted: "WTF!? I just want the status output! Do I need to parse all this?
systemd/fedora sux"
Situation 2:
Ted: "I heard systemctl is kind of replacing service..."
# systemctl libvirtd status
running
Ted: <content. expectations were met>
<2 months later>
Lennart: Hey User, try systemctl libvirtd status -v
Ted: Whoa! Look at all that cool extra information! systemd/fedora rox!
*air guitar*
Granted, the user's conclusion in the first situation is bogus, but if
someones first interaction with the new system is confusion and
unnecessary readjustment of long held interface expectations, it's going
to cause a lot of friction and ill will. Obviously some expectations
will be invalidated, but limiting this should be a high priority IMO.
Thanks,
Cole
12:57 p.m.
On Fri, Jul 23, 2010 at 11:33, Cole Robinson <crobinso(a)redhat.com> wrote:
On 07/21/2010 10:42 PM, Lennart Poettering wrote:
> On Wed, 21.07.10 22:13, Chuck Anderson (cra(a)WPI.EDU) wrote:
>
>>
>> Well, there is some merit in the already stated argument for having
>> good UI design. In this example, you could have used long-standing
>> precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N)
>> arguments instead of "status" "show" "check". Now
you've created new
>> lore of needing to know when to use "status" vs. "show" vs.
"check",
>> what the differences are between them, and what their order of
>> increasing verbosity is.
>
> Well, I think good UI means that you distuingish computer parsable and
> human readable tools. "status" is human readable.
"show"/"check" are
> computer-parsable.
>
I would recommend having 'status' maintain the same semantics as
'service foo status'. The new names aren't sufficiently more
understandable to warrant breaking from long established naming scheme IMO.
Generally I think maintaining similar CLI behavior with 'service' for
common functionality is a good thing. Which situation is more desirable?
Situation 1:
Ted: "I heard systemctl is kind of replacing service..."
# systemctl libvirtd status
Unknown command 'libvirtd'
Ted: "Huh? Oh, must need command first"
# systemctl status libvirtd
Could not find unit '/etc/systemd/libvirtd'
Ted: "Whaa? <looks in /etc> I guess I need to specify the whole file?"
# systemctl status libvirtd.service
<semi-verbose output>
Ted: "WTF!? I just want the status output! Do I need to parse all this?
systemd/fedora sux"
Hey you know Ted too. He's the guy who mailed us a lighter and a bag
full of poop in 1998... since it was do it yourself Unix.
I have to say the best Command Line UI I have had to deal lately is
cobbler. The commands are laid out nicely and if you fuck up you can
see a long list of options and how they should be used.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
1:01 p.m.
On Fri, 23 Jul 2010 13:33:23 -0400
Cole Robinson <crobinso(a)redhat.com> wrote:
Granted, the user's conclusion in the first situation is bogus,
but if
someones first interaction with the new system is confusion and
unnecessary readjustment of long held interface expectations, it's
going to cause a lot of friction and ill will. Obviously some
expectations will be invalidated, but limiting this should be a high
priority IMO.
Actually all you need to keep the user happy is that "service foo
status" returns correctly whether the service is using classic init or
systemd. systemctl does much more than the classic service command, so
the different syntax there is needed to make all commands consistent.
The only nitpick I may have is the use of foo.service instead of
"service foo", because when I query/enable/do something, I do that for
a service not for the file that defines the service. But this is mostly
a matter of semantics.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:32 p.m.
On Wed, 2010-07-21 at 22:13 -0400, Chuck Anderson wrote:
On Thu, Jul 22, 2010 at 03:49:21AM +0200, Lennart Poettering wrote:
> The logic behind chkconfig is exposed in many ways in the user
> interface, for example in the chkconfig command line, e.g.
> commands such as "resetpriorities", and stuff like that.
I think having some level of command-line user-interface compatiblity,
even if not 100%, is important. "resetpriorities" is probably so
rarely used that the systemd version of chkconfig could probably just
make it a no-op (unless it was dealing with old sysvinit scripts, in
which case it could probably just call through to the old chkconfig).
But for basics such as "chkconfig service on|off|--list", there should
be compatibility. Runlevels could perhaps be dealt with by mapping
the common cases like 3,5 to the multiuser-target, graphical-target,
etc. Likewise for "service foo start|stop|reload|condrestart" etc.
Mostly I agree. Just a small modification: we don't really have to care
about how often the commands are used *now*, just whether they would
make any sense at all with systemd. resetpriorities clearly wouldn't, so
with a full systemd system, resetpriorities should simply print an
informational message to the effect that it's an absurd command. With a
mixed system where systemd is still handling some old-school sysvinit
scripts, it should reset the priorities of those.
> Jeez. I guess you cannot be helped. I guess it doesn't help
in any way
> here to mention that we were two steps ahead of you here and provide
> "systemctl show" which can be used to introspect systemd units in all
> details and properties in a parsable way. Also, we added "systemctl
check"
> which prints a one line super-short status.
Well, there is some merit in the already stated argument for having
good UI design. In this example, you could have used long-standing
precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N)
arguments instead of "status" "show" "check". Now
you've created new
lore of needing to know when to use "status" vs. "show" vs.
"check",
what the differences are between them, and what their order of
increasing verbosity is.
> But anyway, I give up. If you keep looking long enough you'll find
> something you don't like in everything.
Please don't give up. I think most of this is valid criticism that
should be voiced, but that doesn't imply that the overall architecture
and implementation of systemd isn't great. I like most of what I see,
but I do cringe at some of the command, argument, and option naming
choices that were made. And I think it is asking too much for users
to have to know to use systemd-install for some things and
chkconfig/service for others, not to mention needing to update all the
RPM spec files for new scriptlets, or fixing anaconda to know when to
call which (I'm guessing that anaconda might call chkconfig or
service, but don't know for sure. Are you sure you know where all the
skeletons are hiding?)
Right. Please try to take the constructive bits from the criticism,
Lennart, and just leave the rest. You don't need to engage with it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:44 p.m.
ons 2010-07-21 klockan 22:13 -0400 skrev Chuck Anderson:
But for basics such as "chkconfig service on|off|--list",
there should
be compatibility.
Yes. I basically use:
chkconfig foo on
chkconfig foo off
env LC_ALL=C.UTF-8 chkconfig --list | fgrep :on |awk '{print $1}
The rest I don't really care about.
But the thing to remember: If systemd-install is too complicated to use,
people will keep using chkconfig and service instead and ignore the
warning. That's why it's important to have something that supports
everything that systemd does while still being simple to use. I don't
care if that's an extended chkconfig or systemd-install or something
else.
Constructive ideas about how to improve systemd-install should be taken
seriously.
I do like systemd, btw. I also like pulseaudio. And selinux. :)
/Alexander
2:47 p.m.
On 07/23/2010 01:14 AM, Alexander Boström wrote:
But the thing to remember: If systemd-install is too complicated to
use,
people will keep using chkconfig and service instead and ignore the
warning. That's why it's important to have something that supports
everything that systemd does while still being simple to use. I don't
care if that's an extended chkconfig or systemd-install or something
else.
systemd-install will be obsoleted by systemdctl as Lennart indicated
later in the thread.
Rahul
6:27 p.m.
On Fri, 23.07.10 01:17, Rahul Sundaram (metherid(a)gmail.com) wrote:
On 07/23/2010 01:14 AM, Alexander Boström wrote:
> But the thing to remember: If systemd-install is too complicated to use,
> people will keep using chkconfig and service instead and ignore the
> warning. That's why it's important to have something that supports
> everything that systemd does while still being simple to use. I don't
> care if that's an extended chkconfig or systemd-install or something
> else.
>
systemd-install will be obsoleted by systemdctl as Lennart indicated
later in the thread.
Minor correction: it's systemctl, not systemdctl.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:20 p.m.
On Thu, Jul 22, 2010 at 09:44:31PM +0200, Alexander Boström wrote:
> But for basics such as "chkconfig service
on|off|--list", there should
> be compatibility.
Yes. I basically use:
chkconfig foo on
chkconfig foo off
env LC_ALL=C.UTF-8 chkconfig --list | fgrep :on |awk '{print $1}
I agree, these are my main uses too, with the rare per-runlevel tweak.
The last ("what is supposed to be 'on' right now?") is pretty ugly -- if
the
new thing provides a convenient interface to do the same thing, that'd be a
win.
The rest I don't really care about.
But the thing to remember: If systemd-install is too complicated to use,
people will keep using chkconfig and service instead and ignore the
warning. That's why it's important to have something that supports
everything that systemd does while still being simple to use. I don't
care if that's an extended chkconfig or systemd-install or something
else.
Constructive ideas about how to improve systemd-install should be taken
seriously.
I do like systemd, btw. I also like pulseaudio. And selinux. :)
/Alexander
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:12 p.m.
On Thu, Jul 22, 2010 at 03:49:21AM +0200, Lennart Poettering wrote:
> So, um. This is not so awesome, because for logged output, the
multi-line
> format makes it hard to parse. And for human-readable output, it's got the
> opposite problem: it's more than 80 columns, and it's very verbose,
> burying the answer I want (is the thing running?) in the middle of the
> paragraph, while telling me many things I probably don't care about.
Jeez. I guess you cannot be helped.
Lennart, I am not trying to be helped. I am trying to help you. You can
listen, or you can argue.
But anyway, I give up. If you keep looking long enough you'll
find
something you don't like in everything.
Yes. And if you listen to the things that people to whom you are trying to
sell your software dislike, you may be in a better position to improve that
software.
Or you can go back to Googling for things that support what you already want
to hear.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:22 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
The logic behind chkconfig is exposed in many ways in the user
interface, for example in the chkconfig command line, e.g.
commands such as "resetpriorities", and stuff like that.
The common chkconfig options are on, off, and probably --list. For
service, they are start, stop, restart, reload, and maybe condrestart.
Implement those in a backwards-compatible fashion, and warn about the
rest when somebody tries them.
Is that really so hard to understand?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:17 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 21.07.10 20:13, Matthew Miller (mattdm(a)mattdm.org) wrote:
> It appears that you're looking at this from the point of view of chkconfig
> as a tool which causes certain manipuations of the system to happen
> (symlinks changed). That's the backwards approach. Look at it from the other
> side: it is a user-interface for changing under what conditions certain
> services run. Then extend that user interface to fit the new capabilities
> that you're adding.
Well, the chkconfig tool is actually a tool which is way more than a
dumbed-down access utility to the /etc/rcX.d/ symlink farms. What its
implementation actually does is defined very much in detail and for
example documented in the man page, to the last bit. In other words: it
is *NOT* an implementation detail what exactly it does to enable/disable
a service. In fact the interface to chkconfig is defined on a multitude
of levels, not only the mere command line arguments. For example we have
chkconfig headers in all init scritps which are part of the api of
chkconfig.
You are both right... of sorts ;-)
True, chkconfig's workings do show through a lot more than is sane. OTOH,
if you need to admin a bunch of Fedora systems, some oldish (i.e., Fedora
11 and 12), perhaps even archeological (Fedora 6 someone? ;-), some new
(rawhide, to check out what looms over the horizon), a few RHEL/CentOS
boxen of varied vintage, some old versions of Scientific Linux or some such
"because that is the latest g++ that compiles our junk", perhaps a few
other Linux systems, and your complement of random Windows and Mac boxen,
_any_ difference (at least in the most used command options) hurts like
hell. The _fingers_ need to know how to do stuff, the _brain_ is better
left out of it (much of the time, that is). That's why we still use the
same venerable lpr(1) to print stuff, even though the server behind it has
changed some 4 or 5 times during my Unix life. Sure, if I need to mess
around adding new print queues and such I do engage the brain (and go
RTFMing and googleing, and whatnot), but _please_ leave (most used)
commands/options legacy compatibility in place. Until this is in RHEL, and
a Fedora cycle more or some such.
Pretty please.
[Snippage]
> So, um. This is not so awesome, because for logged output, the
multi-line
> format makes it hard to parse. And for human-readable output, it's got the
> opposite problem: it's more than 80 columns, and it's very verbose,
> burying the answer I want (is the thing running?) in the middle of the
> paragraph, while telling me many things I probably don't care about.
Jeez. I guess you cannot be helped. I guess it doesn't help in
any way
here to mention that we were two steps ahead of you here and provide
"systemctl show" which can be used to introspect systemd units in all
details and properties in a parsable way. Also, we added "systemctl check"
which prints a one line super-short status.
Great to know about that. And yes, it is extremely relevant for a sysadmin
to know how to tickle the system so it spits out awk(1)-able logs and stuff.
But anyway, I give up. If you keep looking long enough you'll
find
something you don't like in everything.
Please don't. I'll find something I don't like everywhere (some tell me
I'm
way too good at that ;-), the point is to make me find enough stuff I _do_
like so I get over the bitter pill. systemd looks interesting enough to be
worth the pain up to here, but there are lost of details to be hashed out.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
4:39 p.m.
On Thu, Jul 22, 2010 at 12:17 PM, Horst H. von Brand
<vonbrand(a)inf.utfsm.cl> wrote:
Great to know about that. And yes, it is extremely relevant for a
sysadmin
to know how to tickle the system so it spits out awk(1)-able logs and stuff.
Hmm... can these tools learn to prefer a certain format when they are
piped into another program and then prefer a different format when
they are just outputting to an active console. And then the preferred
behaviour can be overridden when specific commandline arguments are
present? Don't other tools exhibit this sort of functionality?
foo show | awk would assume one line awkable output
foo show would assume human readable
foo show -1 would force one line awkable output
foo show -v | awk would force human readable into awk
or some such.
-jef
4:46 p.m.
On Thu, Jul 22, 2010 at 15:39, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Thu, Jul 22, 2010 at 12:17 PM, Horst H. von Brand
<vonbrand(a)inf.utfsm.cl> wrote:
> Great to know about that. And yes, it is extremely relevant for a sysadmin
> to know how to tickle the system so it spits out awk(1)-able logs and stuff.
Hmm... can these tools learn to prefer a certain format when they are
piped into another program and then prefer a different format when
they are just outputting to an active console. And then the preferred
behaviour can be overridden when specific commandline arguments are
present? Don't other tools exhibit this sort of functionality?
foo show | awk would assume one line awkable output
foo show would assume human readable
foo show -1 would force one line awkable output
foo show -v | awk would force human readable into awk
I have seen this done with a couple of GNU tools in the past. The
problems that usually stopped this was that too many strange consoles
seem to be a pipe at somepoint and so it spits out the wrong format at
the wrong time. It is usually easier to just add a flag like : --long
to get the detailed stuff and have a default of it being scriptable
output.
or some such.
-jef
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
4:51 p.m.
On Thu, Jul 22, 2010 at 1:46 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
I have seen this done with a couple of GNU tools in the past. The
problems that usually stopped this was that too many strange consoles
seem to be a pipe at somepoint and so it spits out the wrong format at
the wrong time. It is usually easier to just add a flag like : --long
to get the detailed stuff and have a default of it being scriptable
output.
Ah yes good point.
-jef
5:22 p.m.
On Thu, Jul 22, 2010 at 01:39:06PM -0800, Jeff Spaleta wrote:
On Thu, Jul 22, 2010 at 12:17 PM, Horst H. von Brand
<vonbrand(a)inf.utfsm.cl> wrote:
> Great to know about that. And yes, it is extremely relevant for a sysadmin
> to know how to tickle the system so it spits out awk(1)-able logs and stuff.
Hmm... can these tools learn to prefer a certain format when they are
piped into another program and then prefer a different format when
they are just outputting to an active console. And then the preferred
behaviour can be overridden when specific commandline arguments are
present? Don't other tools exhibit this sort of functionality?
foo show | awk would assume one line awkable output
foo show would assume human readable
foo show -1 would force one line awkable output
foo show -v | awk would force human readable into awk
or some such.
Please don't.
/me thinks of python-2.x which treats printing utf8 different when it goes
to the console vs being redirected.
-Toshio
6:43 p.m.
On Thu, 22.07.10 13:39, Jeff Spaleta (jspaleta(a)gmail.com) wrote:
On Thu, Jul 22, 2010 at 12:17 PM, Horst H. von Brand
<vonbrand(a)inf.utfsm.cl> wrote:
> Great to know about that. And yes, it is extremely relevant for a sysadmin
> to know how to tickle the system so it spits out awk(1)-able logs and stuff.
Hmm... can these tools learn to prefer a certain format when they are
piped into another program and then prefer a different format when
they are just outputting to an active console. And then the preferred
behaviour can be overridden when specific commandline arguments are
present? Don't other tools exhibit this sort of functionality?
foo show | awk would assume one line awkable output
foo show would assume human readable
foo show -1 would force one line awkable output
foo show -v | awk would force human readable into awk
Well, I think is very confusing for the user if he wants to write awk
scripts and it turns out what is read through awk is different from what
he himself sees on screen.
That said, systemctl actually generates different output when used on a
tty (i.e. isatty(STDOUT_FILENO) > 0) and when not. However, we do not
change the actual contents, but just drop the ansi coloring (we normally
hightlight all failed units in red, to give the admin a clear indication
that there's something to look into), and suppress a helpful descriptive
legend text we sometimes show at the end of the output. But again, the
actual content we don't change depending on the kind of stderr, and I am
strongly against doing this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:39 p.m.
On Thu, 22 Jul 2010, Lennart Poettering wrote:
On Wed, 21.07.10 13:29, Chris Adams (cmadams(a)hiwaay.net) wrote:
> Once upon a time, drago01 <drago01(a)gmail.com> said:
> > And when I say/here admin I'd expect to be talking about a human (not
> > some kind of robot that has hardwired commands and can't adapt to
> > changes).
>
> If you only have to manage one system, good for you. I have to manage a
> bunch, and everything that is different _for_no_good_reason_ between
> them is a PITA. Yes, management scripts can be adapted, but now they
> have to handle systems A-Z one way, systems AA-ZZ another (but
> apparently not for all services, try to guess which?). That makes an
> admin unhappy and less likely to deploy any more of systems type AA-ZZ.
BTW, you are emphasizing that that there was no reason for the stfuf we
do. But you are wrong. There actually is. The reason why we came up with
systemd-install as a counterpart of chkconfig instead of patching
chkconfig is that it actually works very very differently from
it. i.e. beyond the fact that both create symlinks, one in
/etc/systemd/system, the other in /etc/rcN.d/ they have very little in
common. One cares about priorities, the other doesn't. One knows only 6
runelvels, the other knows arbitrary numbers of targets. One can hook
stuff into runlevels and runlevels only; the other can hook stuff into
any unit. One can actually make the changes effetive immediately, the
other doesn't do that; one can handle sockets and mounts and other kind
of units, the other cannot; and so on and so on.
I think the bigger question is why are we doing this? It really does
sound like some developers got together and said "You know what people
need? This thing. They need this thing!"
Who has been requesting this? What requirements did they give? The
problem people seem to be having is the reasons you give in the above
paragraph are reasons you yourself invented, and that's a backwards way to
do development :-/
Or in short: extremism sucks. Please acknoweledge that we try to find a
middle ground, and that we are open for suggestions. Because we are. I
already fixed a couple of issues that were discussed on this mailing
list and added a couple more to my todo list. I won't make everybody
happy, but you have a bigger chance to get your suggestion heard if you
don't take extremist positions, declare sysv the holy grail and say
you'll abandon Fedora if we depart from that.
As mentioned above, it seems like you're trying to find a middle ground
between where we are today, and this whole other place you guys invented
for seemingly no reason then you felt like coding something.
Yes, I guess being a developer who develops new stuff I like
innovation
in interfaces more than administrators who then might end up using
this. But it doesn't really help claiming we had no idea what admins
want and consistently ignore their wishes. Because we actually do have a
pretty good idea. We don't fully share all opinions, but we are aware more
often than not.
"Any fool can make things bigger, more complex, and more violent. It takes
a touch of genius - and a lot of courage - to move in the opposite
direction." - Einstein.
I'm not calling you a fool, you're clearly not but that quote seems
appropriate. Just be extra careful when it's others (sysadmins) that have
to live with the consequences of your (developer) decisions.
-Mike
8:04 p.m.
On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
I think the bigger question is why are we doing this?
There's some motivation here:
http://0pointer.de/blog/projects/systemd.html
8:35 p.m.
On Wed, 21 Jul 2010, Colin Walters wrote:
On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath
<mmcgrath(a)redhat.com> wrote:
>
> I think the bigger question is why are we doing this?
There's some motivation here:
http://0pointer.de/blog/projects/systemd.html
I was pretty clear in everything you cut off about the whole "You know
what people need, they need this" and the whole developers making things
for sysadmins because they think sysadmins need it thing. 0pointer.de is
Lennart's post. If this is only being developed and driven by the same
people perhaps we should just step back, get it functioning for a while,
_then_ lets talk about replacements. If you guys feel that strongly about
it, you'll still feel that way a year from now when the whole system is
developed and working right? Perhaps then it can go into Fedora?
This should probably say "systemd for F16"
-Mike
9:28 p.m.
On Wed, Jul 21, 2010 at 9:35 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
I was pretty clear in everything you cut off about the whole "You know
what people need, they need this"
Well Lennart's post basically boils down to:
* Boot faster
* Have the init system be more flexible and powerful
If your concern is that it needs more input from current system
administrators, that seems reasonable. (And there have been a lot of
well-described reasonable concerns raised so far, which Lennart and
others have been working on). But that's quite different from saying
it was just created for no reason or "invented" reasons; I don't think
that's accurate or fair.
10 p.m.
On Wed, Jul 21, 2010 at 10:28:32PM -0400, Colin Walters wrote:
Well Lennart's post basically boils down to:
* Boot faster
I don't need my systems to boot any faster. Or rather, I would like them to,
but the majority of the time is spent in the bios boot sequence already as
disks come online and so forth, so improvements here are moot.
My laptop already boots fast enough already, although I guess if it can be
improved even further with minimal disruption, why not. I don't see it as
worth a lot of pain, though -- not because I don't use my laptop a lot, but
because suspend/resume makes boot time irrelevant in the general case.
* Have the init system be more flexible and powerful
So, for me, this is the key benefit. It'd be nice to have the service that
starts services be able to keep track of them better. It might be nice to
have a smarter interface to cron (and something like incrond?).
However, in the overall scheme of things, I don't know any sysadmin who
really spends much time _worrying_ about this stuff. For the most part, it
works _very well_. It's annoying if some little program doesn't already have
a nice init script written, but eh, no big deal. When something goes wrong,
it doesn't take long to figure out what (even if the root cause is a mystery
-- "autofs died. hmm. wonder why") and correct it. Changing the init system
to something complicated runs the risk of making an easy problem into a hard
problem -- this is the concern raised a while ago about shell scripts vs. a
config file interpretted by binary code.
I won't speak for anyone else, but to me this is why "wait, what problem are
we trying to solve?" resonates with me.
I *do* like the prospect of easy management of resources (CPU policy, OOM, io
class) for services. The templating mechanism might be useful here.
And I'm hoping that maybe, finally, dependencies in init will mean that NFS
mounts in fstab don't utterly fail when NetworkManager (another source of
sysadmin displeasure, but let's not go there now) is used.
And I should add that I appreciate that the proposed config file format is
key=value rather than some XML monstrosity.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:25 p.m.
On Wed, 21.07.10 23:00, Matthew Miller (mattdm(a)mattdm.org) wrote:
My laptop already boots fast enough already, although I guess if it
can be
improved even further with minimal disruption, why not. I don't see it as
worth a lot of pain, though -- not because I don't use my laptop a lot, but
because suspend/resume makes boot time irrelevant in the general case.
OK, so we have one feature here that doesn't matter for you.
I *do* like the prospect of easy management of resources (CPU policy,
OOM, io
class) for services. The templating mechanism might be useful here.
And I'm hoping that maybe, finally, dependencies in init will mean that NFS
mounts in fstab don't utterly fail when NetworkManager (another source of
sysadmin displeasure, but let's not go there now) is used.
And I should add that I appreciate that the proposed config file format is
key=value rather than some XML monstrosity.
And here are three features that you like and matter to you.
Now, after discussing this over 2years with many folks and reading up on
launchd and SMF and the opinions on the net, we then distilled of the
requests a set of good features we wanted to implement. Some of those
matter to you. Others don't. But to other people other features matter
and the ones you like don't. And even other people have even other
priorities.
Now, putting this all together, just because there's a lot of stuff in
there you don't need it is not without point in general. Not everybody
has the same needs, and many requirements other people have you don't
have their full validity.
We don't try to make everybody happy with systemd. We will neither offer
every feature people might have requested, nor are we going to drop
features just because others don't see the need. Please accept that. It
doesn't make the project pointless.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:56 p.m.
On Thu, Jul 22, 2010 at 05:25:19AM +0200, Lennart Poettering wrote:
Now, after discussing this over 2years with many folks and reading up
on
launchd and SMF and the opinions on the net, we then distilled of the
requests a set of good features we wanted to implement. Some of those
That is interesting and good for your project. I know you're intelligent and
an great coder, and I have no problem with assuming you did an excellent job
in your research. However, it is -- and I mean this as no insult -- only
tangentially interesting to Fedora.
matter to you. Others don't. But to other people other features
matter
and the ones you like don't. And even other people have even other
priorities.
This is true in a vacuum. In a concrete setting -- a specific distribution
-- it's important to discuss what the priorities of that specific situation
are, and whether a particular piece of software fits those priorities.
And bluntly: I don't think you've done that. The "benefit to Fedora"
section of the feature page says 1) it's a better design (which is to say
nothing about features or priorities or use cases) and 2) it may eventually
speed up booting but is not actually guaranteed to do that yet.
So, while you may have done a good job of fitting your software to the needs
you see in the world, that doesn't automatically mean that there's a good
match for Fedora. (Again, it may be, but you can't just say "We say it's
compelling, so trust us and be compelled.")
We don't try to make everybody happy with systemd. We will
neither offer
every feature people might have requested, nor are we going to drop
features just because others don't see the need. Please accept that. It
doesn't make the project pointless.
I didn't say it was pointless. In fact, I think I'm on record as saying that
it's an interesting project. But while you don't have to "make everybody
happy" in a general sense, in order to be relevant to Fedora, you *do* need
to make a convincing case that the Fedora Project as a whole will be better
off with your project as the default.
And I think it's _very_ fair to say that you had an interesting idea and are
working to get your interesting idea into Fedora quickly for the benefit and
growth of the interesting idea itself, not necessarily for the benefit of
Fedora or Fedora users. In the happy ideal, those two would coincide and
everyone wins, but it's asking a lot of faith from the user community -- and
hubris and arrogance may not be the best strategy.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:18 a.m.
On Wed, 21.07.10 23:56, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Thu, Jul 22, 2010 at 05:25:19AM +0200, Lennart Poettering wrote:
> Now, after discussing this over 2years with many folks and reading up on
> launchd and SMF and the opinions on the net, we then distilled of the
> requests a set of good features we wanted to implement. Some of those
That is interesting and good for your project. I know you're intelligent and
an great coder, and I have no problem with assuming you did an excellent job
in your research. However, it is -- and I mean this as no insult -- only
tangentially interesting to Fedora.
So, that's what you say. I say it is very much relevant for
Fedora. Now, who's right? It's unlikely that we can figure that out for
sure, given that Fedora is a lot of things to a lot of people, so our
two opposite opinions even out in a zero sum game.
Oh, if we only had a committee that would take steering decisions in the
area of engineering! [1]
Lennart
Footnote:
[1] Yes, you got the joke. FESCO accepted systemd as feature for F14 weeks ago.
--
Lennart Poettering - Red Hat, Inc.
10 a.m.
On Thu, Jul 22, 2010 at 04:18:34PM +0200, Lennart Poettering wrote:
Fedora. Now, who's right? It's unlikely that we can figure
that out for
sure, given that Fedora is a lot of things to a lot of people, so our
two opposite opinions even out in a zero sum game.
Oh, if we only had a committee that would take steering decisions in the
area of engineering! [1]
Please read http://fedoraproject.org/wiki/Features/Policy/Acceptance.
Acceptance by FESCo is a sanity check, presumed in most cases to be a
formality, to ensure that new features compliment Fedora's guidelines and
is manageable, prior to publicizing as officially targeted for the next
release.
It is not, in fact, an endorsement in the area of engineering. Feature
approval is a a way of saying: okay, that looks worth trying. But it may
turn out that there are problems not anticipated in the initial proposal,
once the feature has wider exposure. That's not a *problem* -- it's part of
the process.
If those issues can't be addressed in a reasonable way (where "this is going
in like this, so stop resisting change is nowhere close to reasonable),
that's why there's a contingency plan.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:12 p.m.
On Thu, 22.07.10 11:00, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Thu, Jul 22, 2010 at 04:18:34PM +0200, Lennart Poettering wrote:
> Fedora. Now, who's right? It's unlikely that we can figure that out for
> sure, given that Fedora is a lot of things to a lot of people, so our
> two opposite opinions even out in a zero sum game.
> Oh, if we only had a committee that would take steering decisions in the
> area of engineering! [1]
Please read http://fedoraproject.org/wiki/Features/Policy/Acceptance.
Acceptance by FESCo is a sanity check, presumed in most cases to be a
formality, to ensure that new features compliment Fedora's guidelines and
is manageable, prior to publicizing as officially targeted for the next
release.
It is not, in fact, an endorsement in the area of engineering. Feature
approval is a a way of saying: okay, that looks worth trying. But it may
turn out that there are problems not anticipated in the initial proposal,
once the feature has wider exposure. That's not a *problem* -- it's part of
the process.
What was discussed by FESCO was whether we should make it the default in
F14. And FESCO said yes. As usually, should later on during development
of F14 turn out that this actually doesn't work, then we can switch back
to Upstart. From the very beginning we have put together a plan how to
accomplish this best, in this event. This is in fact not any different
as with any other feature accepted by FESCO. Always, there's a plan B
delcared which is executed when the feature turns out not to work.
Make of this what you want, but you can read of this at least one thing:
I am not the only one who things that systemd is very much *in* focus of
fedora, and is good thing to make the default.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:19 p.m.
Lennart Poettering píše v Čt 22. 07. 2010 v 19:12 +0200:
What was discussed by FESCO was whether we should make it the default
in
F14. And FESCO said yes.
That's not what I understand from
http://meetbot.fedoraproject.org/fedora-meeting/2010-06-15/fesco.2010-06-...
. Was there another meeting since?
Mirek
2:55 a.m.
On Wed, 2010-07-21 at 20:35 -0500, Mike McGrath wrote:
On Wed, 21 Jul 2010, Colin Walters wrote:
> On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
> >
> > I think the bigger question is why are we doing this?
>
> There's some motivation here:
> http://0pointer.de/blog/projects/systemd.html
>
I was pretty clear in everything you cut off about the whole "You know
what people need, they need this" and the whole developers making things
for sysadmins because they think sysadmins need it thing. 0pointer.de is
Lennart's post. If this is only being developed and driven by the same
people perhaps we should just step back, get it functioning for a while,
_then_ lets talk about replacements. If you guys feel that strongly about
it, you'll still feel that way a year from now when the whole system is
developed and working right? Perhaps then it can go into Fedora?
This should probably say "systemd for F16"
+1 FWIW. I'm not a huge sysv fanboi either, but I do care about the
experience of sysadmins and the upstream for other projects, and I would
like to see some soak time for this before everyone needs to switch. I
can otherwise just imagine the amount of documentation out there -
books, online resources, etc. that will all be out of date for Fedora
(and perhaps other projects later) but not for other distributions.
Jon.
3:21 a.m.
On Thu, Jul 22, 2010 at 9:55 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
On Wed, 2010-07-21 at 20:35 -0500, Mike McGrath wrote:
> On Wed, 21 Jul 2010, Colin Walters wrote:
>
> > On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath <mmcgrath(a)redhat.com>
wrote:
> > >
> > > I think the bigger question is why are we doing this?
> >
> > There's some motivation here:
> > http://0pointer.de/blog/projects/systemd.html
> >
>
> I was pretty clear in everything you cut off about the whole "You know
> what people need, they need this" and the whole developers making things
> for sysadmins because they think sysadmins need it thing. 0pointer.de is
> Lennart's post. If this is only being developed and driven by the same
> people perhaps we should just step back, get it functioning for a while,
> _then_ lets talk about replacements. If you guys feel that strongly about
> it, you'll still feel that way a year from now when the whole system is
> developed and working right? Perhaps then it can go into Fedora?
>
> This should probably say "systemd for F16"
+1 FWIW. I'm not a huge sysv fanboi either, but I do care about the
experience of sysadmins and the upstream for other projects, and I would
like to see some soak time for this before everyone needs to switch. I
can otherwise just imagine the amount of documentation out there -
books, online resources, etc. that will all be out of date for Fedora
(and perhaps other projects later) but not for other distributions.
FWIW this is the reason why upstart pretty much ended being a renamed
sysvinit without offering any benefits because people are afraid of
change.
The books won't magically be rewritten in time for F16 (people aren't
even using systemd so why write / update books) ?
Isn't it one of Fedora's missions to innovate and lead and not stay in
the past forever because people are afraid of change?
(Note: I am not addressing a particular change here; but people's
resistance against *any* changes=).
6:46 a.m.
On Thu, Jul 22, 2010 at 10:21:07AM +0200, drago01 wrote:
FWIW this is the reason why upstart pretty much ended being a
renamed
sysvinit without offering any benefits because people are afraid of
change.
That's what we call a successful transition. Now, we can incrementally
introduce improvements over the next few releases.
Rsyslog is another example of the same thing.
The books won't magically be rewritten in time for F16 (people
aren't
even using systemd so why write / update books) ?
Because updated books sell? But authors need some lead time.
Isn't it one of Fedora's missions to innovate and lead and
not stay in
the past forever because people are afraid of change?
That last part isn't in the mission, no.
(Note: I am not addressing a particular change here; but
people's
resistance against *any* changes=).
Resistance to any change is a good baseline. Otherwise, you're changing all
the time for no reason -- it's like saying "Imagine how much faster our cars
could go if there were no friction!".
The tricky part is finding out the appropriate level of friction. And that
works better if we discuss in a constructive way as a community. There's a
disturbing tendency among the no-friction advocates to cry "bike-shedding",
but actually gathering feedback is an important part of the process.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:38 a.m.
On Thu, Jul 22, 2010 at 1:46 PM, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Thu, Jul 22, 2010 at 10:21:07AM +0200, drago01 wrote:
> FWIW this is the reason why upstart pretty much ended being a renamed
> sysvinit without offering any benefits because people are afraid of
> change.
That's what we call a successful transition. Now, we can incrementally
introduce improvements over the next few releases.
Once you start doing that people will cry because it is different from
what they are used too (does not matter if the change is for the
better or worse).
Rsyslog is another example of the same thing.
I can't really comment on that because I don't really know what
rsyslog was supposed to offer over syslog.
> The books won't magically be rewritten in time for F16
(people aren't
> even using systemd so why write / update books) ?
Because updated books sell? But authors need some lead time.
How many books about initng exist?
Hmm... zero?
It is a chicken-egg problem ... as long as systemd isn't used anywhere
there won't be any updated books.
> Isn't it one of Fedora's missions to innovate and lead and not stay in
> the past forever because people are afraid of change?
That last part isn't in the mission, no.
Than please read http://fedoraproject.org/wiki/Overview
"The Fedora Project always strives to lead, not follow."
Which means "not wait for others to do the work but do it"
> (Note: I am not addressing a particular change here; but
people's
> resistance against *any* changes=).
Resistance to any change is a good baseline.
Not when it comes to the level to hinder any progress.
Otherwise, you're changing all
the time for no reason -- it's like saying "Imagine how much faster our cars
could go if there were no friction!".
The tricky part is finding out the appropriate level of friction. And that
works better if we discuss in a constructive way as a community. There's a
disturbing tendency among the no-friction advocates to cry "bike-shedding",
but actually gathering feedback is an important part of the process.
Where did I say that one shouldn't gather feedback?
Feed and constructive criticism is helpful regardless of change or not.
But "foo is worse than bar because it is different than bar" just
doesn't cut it.
Some have actually commented in "the interface is hard to
understand/use because ..." which is the proper way to provide
feedback, but "how dare you change the existing system screw you" is
just crap.
8:22 a.m.
On Thu, Jul 22, 2010 at 02:38:36PM +0200, drago01 wrote:
> That's what we call a successful transition. Now, we can
incrementally
> introduce improvements over the next few releases.
Once you start doing that people will cry because it is different from
what they are used too (does not matter if the change is for the
better or worse).
So, let me ask a question: why do you think people have that response?
>> The books won't magically be rewritten in time for F16
(people aren't
>> even using systemd so why write / update books) ?
> Because updated books sell? But authors need some lead time.
How many books about initng exist?
Did any distribution ever say: we intend to move to initng in one year and
it's in testing now? Because if they did, I'm sure that books would reflect
that.
>> Isn't it one of Fedora's missions to innovate and
lead and not stay in
>> the past forever because people are afraid of change?
> That last part isn't in the mission, no.
Than please read http://fedoraproject.org/wiki/Overview
"The Fedora Project always strives to lead, not follow."
Which means "not wait for others to do the work but do it"
Leadership means making careful, well-conceived decisions. Otherwise, it's
not leading, it's charging around blindly shouting "follow me!".
> Otherwise, you're changing all
> the time for no reason -- it's like saying "Imagine how much faster our
cars
> could go if there were no friction!".
>
> The tricky part is finding out the appropriate level of friction. And that
> works better if we discuss in a constructive way as a community. There's a
> disturbing tendency among the no-friction advocates to cry
"bike-shedding",
> but actually gathering feedback is an important part of the process.
Where did I say that one shouldn't gather feedback?
Feed and constructive criticism is helpful regardless of change or not.
I am not getting the message from this thread that systemd developers
believe that. Rather, we get "it's clearly a matter of taste and
bike-shedding", and "I probably shouldn't even have bothered to even reply
to this mail of yours."
But "foo is worse than bar because it is different than
bar" just
doesn't cut it.
Not only does it "cut it", it is a very important point. There is a _very
real_ cost to changing from established practices. Often (and perhaps very
often, in a bleeding-edge distribution like Fedora) it's worth it to do so
despite that cost, because otherwise there's stagnation. But you must:
1) make the case for how the change outweighs the cost, and
2) work to reduce that cost as much as possible.
Instead, you seem to be trying to argue that change comes for free. (And
that those who have to pay this cost are "crying".) This is what does not
"cut it" in actual, practical use.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:52 a.m.
On Thu, Jul 22, 2010 at 3:22 PM, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Thu, Jul 22, 2010 at 02:38:36PM +0200, drago01 wrote:
> > That's what we call a successful transition. Now, we can incrementally
> > introduce improvements over the next few releases.
> Once you start doing that people will cry because it is different from
> what they are used too (does not matter if the change is for the
> better or worse).
So, let me ask a question: why do you think people have that response?
Read this thread? Or any other one that introduces any major change?
> >> The books won't magically be rewritten in time for
F16 (people aren't
> >> even using systemd so why write / update books) ?
> > Because updated books sell? But authors need some lead time.
> How many books about initng exist?
Did any distribution ever say: we intend to move to initng in one year and
it's in testing now? Because if they did, I'm sure that books would reflect
that.
No, but even if would be very unlikely ... producing books costs time
and money you don't do it because someone said "sometime we will start
using foo".
If anything books document existing stuff (and most of the time lag
behind), not what is planned in X years.
> >> Isn't it one of Fedora's missions to innovate
and lead and not stay in
> >> the past forever because people are afraid of change?
> > That last part isn't in the mission, no.
> Than please read http://fedoraproject.org/wiki/Overview
> "The Fedora Project always strives to lead, not follow."
> Which means "not wait for others to do the work but do it"
Leadership means making careful, well-conceived decisions. Otherwise, it's
not leading, it's charging around blindly shouting "follow me!".
Yeah, systemd seems to replace a part of the system which has been
pretty much stagnant for ever and implements a lot of interesting
concepts.
On the other side we have "it isn't 100% like sysvinit" ...
So given this arguments I'd opt for the former.
Going back to the above statement .. we lead by introducing it so when
others adapt it the books should have started to catch up.
Which is pretty much in line with Fedora's mission.
> > Otherwise, you're changing all
> > the time for no reason -- it's like saying "Imagine how much faster our
cars
> > could go if there were no friction!".
> >
> > The tricky part is finding out the appropriate level of friction. And that
> > works better if we discuss in a constructive way as a community. There's a
> > disturbing tendency among the no-friction advocates to cry
"bike-shedding",
> > but actually gathering feedback is an important part of the process.
>
> Where did I say that one shouldn't gather feedback?
> Feed and constructive criticism is helpful regardless of change or not.
I am not getting the message from this thread that systemd developers
believe that. Rather, we get "it's clearly a matter of taste and
bike-shedding", and "I probably shouldn't even have bothered to even reply
to this mail of yours."
> But "foo is worse than bar because it is different than bar" just
> doesn't cut it.
Not only does it "cut it", it is a very important point. There is a _very
real_ cost to changing from established practices. Often (and perhaps very
often, in a bleeding-edge distribution like Fedora) it's worth it to do so
despite that cost, because otherwise there's stagnation. But you must:
1) make the case for how the change outweighs the cost, and
2) work to reduce that cost as much as possible.
See above.
Instead, you seem to be trying to argue that change comes for free.
No I am just saying that a change isn't bad because it is a change.
(And
that those who have to pay this cost are "crying".)
Everyone has to pay this cost and everyone gets something in return.
9:11 a.m.
On Thu, Jul 22, 2010 at 8:52 AM, drago01 <drago01(a)gmail.com> wrote:
On Thu, Jul 22, 2010 at 3:22 PM, Matthew Miller
<mattdm(a)mattdm.org> wrote:
> (And
> that those who have to pay this cost are "crying".)
Everyone has to pay this cost and everyone gets something in return.
That's not what you are hearing from the system administrators on the
list - especially those that manage larger groups of systems, or
manage systems where there are several distributions in place.
For the sysadmins who manage large groups of systems, what is the
inherent benefit to systemd? All I've seen is alot of "hey, this is a
cool feature and you should like it", and not alot of "this
feature/capability will help with this specific problem".
And there isn't much discussion on how implementing systemd will
impact the traditional uses and implementation of a server system -
things like:
- application servers with connection pooling to databases to reduce
response time. The "systemd manages the connections" seems to go
against the current setups where the application handles manages the
application server processes depending on parameters in the
connection. How does the philosophy of having systemd start a process
for each connection impact server response time for normal operations.
Decreasing startup time is a nice-to-have - making sure the server
responds as fast as possible during normal operations is required.
- shared realms/shared memory for session tracking and
inter-application communications
- database startup and connections. I wouldn't want the Oracle or
MySQL listeners start up with each connection, there's way too much
overhead in that part of the process
- monitoring (the port checking that many monitoring systems use will
not work well with the "systemd manages the port and starts the
service when it gets the connection" that I've seen described here.
This is especially important when looking at high availability, where
you need to know that you don't just get a connection, but you
actually talk to the application that's supposed to be listening on
that port.
I'm sure there are other areas, but those are the first things that
came to my mind.
9:13 a.m.
Once upon a time, drago01 <drago01(a)gmail.com> said:
No I am just saying that a change isn't bad because it is a
change.
And others (like me) are just saying that a change isn't good because it
is new.
There's a middle ground that needs to be found, but repeating either of
"change==bad" or "new==good" doesn't help.
IMHO, systemd seems to cram a bunch of existing things (init, inetd,
chkconfig, service, pstree, etc.) together, and the assumption is that
this is new and good. I don't really agree. For example, if on-demand
activation for socket-based services is the way to go, why has everybody
abandonded that model by moving away from inetd? Having init directly
manage services came before sysVinit (hello /etc/inittab), but nobody
uses that anymore either.
Also, hasn't starting lots of services in parallel been tried before and
found to thrash the system, actually slowing down boot instead of
speeding it up?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:49 a.m.
On Thu, 22.07.10 09:13, Chris Adams (cmadams(a)hiwaay.net) wrote:
IMHO, systemd seems to cram a bunch of existing things (init, inetd,
chkconfig, service, pstree, etc.) together, and the assumption is that
this is new and good. I don't really agree. For example, if on-demand
activation for socket-based services is the way to go, why has everybody
abandonded that model by moving away from inetd? Having init directly
manage services came before sysVinit (hello /etc/inittab), but nobody
uses that anymore either.
For starters, systemd is not really about on-demand starting of
services. Only very few services in the end will be started
on-demand. Socket activation is awesome for four reasons, only one of
them being that you actually implement on-demand spawning of daemons, if
you wish to.
1. Parallelization: we can completely get rid of any serialization of
startup. We can start *every* signle daemon at the same time in one big
step, regardless whether one of them needs another. i.e. we can start
avahi at the same time as dbus at the same time as syslog at the same
time as nscd, although every single one of them might want to connect to
another one in this list and in traditional thinking they hence would
have needed to be started one after the other, so that every service
using another services can be sure it can talk to the one it needs. I
mean, how awesome is that? We can completely remove *any* kind of
serialization from daemon startup.
2. Simplicity: dependencies become redundant. Nowhere you really have to
declare that avahi requires dbus or dbus requires syslog the way we
currently do in the LSB init script headers: because the sockets will be
established during early boot. All of them. And if some service wants to
talk to them he can just do so, without any explicit dependency
configured. How awesome is this? We can complete remove *any* kind of
declaration of dependencies from daemon startup!
3. Robustness: The sockets stay around all the time, and always
connectable. You can kill a daemon but you won't lose a single
connection while doing that! Particularly for stateless protocols (such
as DNS or syslog) we can automatically restart a daemon when it crashes,
and when it comes back it will go on where it left of, as if nothing
happened! The client will not even notice! How awesome is that?
Restarting daemons without losing connections?
4. On-Demand Startup: Yes, this too. But this actually is relevant for a
a select few daemons, where it is likely that they aren't used during
boot anyway. If a daemon willk be clearly used during bootup it is smart
to start it as early as possible, and not as late as possible because
then the first user would have to wait for it which prolongs not
shortens the boot process. The select few daemons which can benefit from
on-demand starting is stuff like SSH or CUPS which in most installations
is used seldomly only. But even if we do on-demand by default for these
admins can still start them unconditionally during boot if they want,
simply by placing a single symlink.
Anyway, these four features of socket based activation are what make it
so great. Reducing the whole logic to "inetd in an init system" is
completely besides the point, because it's actually completely unlike
it. While we do socket passing we do it for different reasons and in a
different way. We support inetd compatibility, but in general things will be
different from classic inetd setups in so many ways.
Anyway, I have tried to explain this many times before. For example in
my long blog story. I know I sound like a broken clock, but I can only
encourage people ro read it. http://0pointer.de/blog/projects/systemd.html
Note that this scheme is not new. launchd championed it. It is part of
Apple MacOS since a while. So if you ask "why has every body abandoned
that model" then this is a completely bogus statement. Because MacOS
just recently moved to it, fully and completey, all over the board.
Please, read my blog novel. It is long. But in it I actually try in
lengths to explain what is so great about systemd.
Yes, really grokking the greatness of socket based activation actually
takes a while. But try to wrap your head around it. You might enjoy this
talk from an Apple Engineer which explains the logic. It's about
launchd, not systemd. But the socket based activation is similar in both
systems. So listen to it with a grain of salt:
http://video.google.com/videoplay?docid=1781045834610400422#
Also, hasn't starting lots of services in parallel been tried
before and
found to thrash the system, actually slowing down boot instead of
speeding it up?
Well, if the IO scheduler cannot cope with it (and indeed it seems it is
not perfoming as well as it should), then this needs to be fixed in the
IO scheduler. In general an elevator should benefit from having a
larger set of requests to choose from.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:29 a.m.
On Thu, 22 Jul 2010 16:49:50 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
1. Parallelization: we can completely get rid of any serialization
of
startup. We can start *every* signle daemon at the same time in one
big step, regardless whether one of them needs another. i.e. we can
start avahi at the same time as dbus at the same time as syslog at
the same time as nscd, although every single one of them might want
to connect to another one in this list and in traditional thinking
they hence would have needed to be started one after the other, so
that every service using another services can be sure it can talk to
the one it needs. I mean, how awesome is that? We can completely
remove *any* kind of serialization from daemon startup.
how do you deal with circular dependencies in this case?
I mean what will happen ? Will all services just deadlock?
Malfunction ? Anything that guarantees correct initialization and
behavior ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:42 a.m.
On Thu, 22 Jul 2010, Simo Sorce wrote:
On Thu, 22 Jul 2010 16:49:50 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> 1. Parallelization: we can completely get rid of any serialization of
> startup. We can start *every* signle daemon at the same time in one
> big step, regardless whether one of them needs another. i.e. we can
> start avahi at the same time as dbus at the same time as syslog at
> the same time as nscd, although every single one of them might want
> to connect to another one in this list and in traditional thinking
> they hence would have needed to be started one after the other, so
> that every service using another services can be sure it can talk to
> the one it needs. I mean, how awesome is that? We can completely
> remove *any* kind of serialization from daemon startup.
how do you deal with circular dependencies in this case?
I mean what will happen ? Will all services just deadlock?
Malfunction ? Anything that guarantees correct initialization and
behavior ?
In addition to circular deps, have any studies been done on disk
contention when you just start everything all at once? If we're not
careful we could actually increase boot time in some scenarios. I guess
one way to check would be to go through all your init scripts and add a &
to the end of the start line?
-Mike
10:59 a.m.
On Thu, Jul 22, 2010 at 10:42:19AM -0500, Mike McGrath wrote:
In addition to circular deps, have any studies been done on disk
contention when you just start everything all at once? If we're not
careful we could actually increase boot time in some scenarios. I guess
one way to check would be to go through all your init scripts and add a &
to the end of the start line?
It's my impression that this has been done. The Fedora feature page
discusses the additional importance of readahead when using spinning media,
and appears to be speaking based on tests (athough no number or test results
are given there).
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
11:48 a.m.
On Thu, 22.07.10 10:42, Mike McGrath (mmcgrath(a)redhat.com) wrote:
> how do you deal with circular dependencies in this case?
> I mean what will happen ? Will all services just deadlock?
> Malfunction ? Anything that guarantees correct initialization and
> behavior ?
In addition to circular deps, have any studies been done on disk
contention when you just start everything all at once? If we're not
careful we could actually increase boot time in some scenarios. I guess
one way to check would be to go through all your init scripts and add a &
to the end of the start line?
In theory the elevator should benefit from having more requests at the
same time to choose from. However, theory is theory, and in fact the
Linux IO scheduler does not benefit from this on rotating media too much
right now. However, I think this kind of brokenness needs to be fixed in
the kernel.
This general problem has been discussed a couple of times in the meego
community iirc. There have been suggestions to improve the
situation. But nothing so far has been compelling and actually been
fixed in the kernel.
In generally I believe the right approach is to let the kernel IO
scheduler schedule IO and not try to work around perceived brokeness
simply by always serializing things on the userspace side already. Don't
try to second-guess the IO scheduler, fix it.
One could say that the IO scheduler is currently not directly optimized
for this kind of IO load, because this load simply didn't exist
before. It needs more optimization in this area.
There have been attempts to work around this problem in userspace. For
example with stuff like readahead. I personally believe that readahead
is a deadend, and a correct fix for the problem would be more akin to
Axboe's fcache, i.e. in order to optimize access time it is better to
rearrange sectors then simply reading them in a different order and
hoping this doesn't interfere with the normal IO scheduling applied.
Looking at what Windows and MacOS do in this area is probably
healthy. Both systems rearrange sectors on disk and parallelize as much
as possible. I think that's bascially a good recipe we should follow
too. systemd caters for the latter, we need kernel fixes to cater for
the former.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:11 p.m.
On Thu, Jul 22, 2010 at 8:48 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
Looking at what Windows and MacOS do in this area is probably
healthy. Both systems rearrange sectors on disk and parallelize as much
as possible. I think that's bascially a good recipe we should follow
too. systemd caters for the latter, we need kernel fixes to cater for
the former.
Have you had some discussions with people who have a good
understanding of the kernel I/O scheduler about looking at this work
load as an optimization target?
Also, thinking worse case scenario. If in the rawhide runup if the
release management team find the disk I/O scheduling is a significant
problem when many of our default services "go native." Would it be a
reasonable fallback to flip back some of the services to sysinit style
scripts by default? I'm not suggesting it will be a significant
problem (nor am I putting my neck out and defining what significant
means here...) but its good to have an understanding of where rough
edges are anticipated and to have a fallback plan if the kernel
scheduling can't get fixed in the pre F14 time scale.
-jef
-jef
12:27 p.m.
On Thu, 22.07.10 09:11, Jeff Spaleta (jspaleta(a)gmail.com) wrote:
On Thu, Jul 22, 2010 at 8:48 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> Looking at what Windows and MacOS do in this area is probably
> healthy. Both systems rearrange sectors on disk and parallelize as much
> as possible. I think that's bascially a good recipe we should follow
> too. systemd caters for the latter, we need kernel fixes to cater for
> the former.
Have you had some discussions with people who have a good
understanding of the kernel I/O scheduler about looking at this work
load as an optimization target?
There were some discussions at LPC last year. It is my intention to talk
about this at LPC again, this time with a clear focus on the realistic
workload systemd actually generates. (Kay Sievers and I will do a
presentation about systemd there).
Some folks in the kernel community tend to argue that the problem slowly
goes away with introduction of SSD anyway, but I personally think that
rotating media is going to stay long enough with us that it would be
worth fixing boot.
Also, thinking worse case scenario. If in the rawhide runup if the
release management team find the disk I/O scheduling is a significant
problem when many of our default services "go native." Would it be a
reasonable fallback to flip back some of the services to sysinit style
scripts by default? I'm not suggesting it will be a significant
problem (nor am I putting my neck out and defining what significant
means here...) but its good to have an understanding of where rough
edges are anticipated and to have a fallback plan if the kernel
scheduling can't get fixed in the pre F14 time scale.
Well, the worst that happens right now is that the boot up isn't really
faster with systemd than without systemd on rotating media. I see little
reason to reverse any changes if that's the worst that happens.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:35 a.m.
On Thu, 22.07.10 11:29, Simo Sorce (ssorce(a)redhat.com) wrote:
> they hence would have needed to be started one after the other,
so
> that every service using another services can be sure it can talk to
> the one it needs. I mean, how awesome is that? We can completely
> remove *any* kind of serialization from daemon startup.
how do you deal with circular dependencies in this case?
I mean what will happen ? Will all services just deadlock?
Malfunction ? Anything that guarantees correct initialization and
behavior ?
If a service A uses functionality provided by a service B which in turn
uses functionality provided by A then things willbreak regardless
whether systemd is used or not.
Cyclic dependencies cause deadlocks. Introducing systemd has little
effect on that. It won't make the situation worse, and it won't make
itmuch better either.
Or in other words: If somebody writes a syslog implementation that
writes its logged data to mysql, ignoring that mysql actually itself
logs to syslog, then it is his own fault, and this simply doesn't work,
regardless if syslog or mysql is socket-activated or not, or whether
systemd is used at all. It cannot work, already on a theoretical level.
Or in even other words: this is a theoretical problem, not a practical
one, and orthogonal to the problem set systemd tries to solve.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:48 a.m.
Lennart Poettering píše v Čt 22. 07. 2010 v 18:35 +0200:
If a service A uses functionality provided by a service B which in
turn
uses functionality provided by A then things willbreak regardless
whether systemd is used or not.
Cyclic dependencies cause deadlocks. Introducing systemd has little
effect on that. It won't make the situation worse, and it won't make
itmuch better either.
<snip>
Or in even other words: this is a theoretical problem, not a
practical
one, and orthogonal to the problem set systemd tries to solve.
Not at all. If,
there is a circular dependency between, say, syslogd
and dbus, with the old system:
- syslogd attempts to use dbus, which fails
- syslogd can detect the situation
- syslogd can choose to ignore it (or retry later) and complete startup
- dbus starts
- dbus uses syslog to say it has started successfully
- system boots normally
- [syslogd optionally reconnects to dbus]
I don't know whether this currently happens with Fedora, but it is not
at all irrelevant and systemd could indeed make the situation much
worse.
Mirek
11:54 a.m.
On Thu, 22.07.10 18:48, Miloslav Trmač (mitr(a)volny.cz) wrote:
Lennart Poettering píše v Čt 22. 07. 2010 v 18:35 +0200:
> If a service A uses functionality provided by a service B which in turn
> uses functionality provided by A then things willbreak regardless
> whether systemd is used or not.
>
> Cyclic dependencies cause deadlocks. Introducing systemd has little
> effect on that. It won't make the situation worse, and it won't make
> itmuch better either.
<snip>
> Or in even other words: this is a theoretical problem, not a practical
> one, and orthogonal to the problem set systemd tries to solve.
Not at all. If, there is a circular dependency between, say, syslogd
and dbus, with the old system:
- syslogd attempts to use dbus, which fails
- syslogd can detect the situation
- syslogd can choose to ignore it (or retry later) and complete startup
- dbus starts
- dbus uses syslog to say it has started successfully
- system boots normally
- [syslogd optionally reconnects to dbus]
I don't know whether this currently happens with Fedora, but it is not
at all irrelevant and systemd could indeed make the situation much
worse.
Nope, what you suggest will deadlock sooner or later:
let's say syslog connects to dbus eventually. Doing that means it has to
block (the authentication dbus does is already blocking) on some dbus
request. Now, if dbus logs to syslog while processing that request it
might block writing to /dev/log. And there you have it. A deadlock.
Really, cyclic dependencies cause deadlocks. There's nothing new about
that.
This problem is completely theoretical. As is shown by MacOS which
employs this technique and according to their engineers starts over 160
daemons like this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:49 a.m.
tor 2010-07-22 klockan 18:48 +0200 skrev Miloslav Trmač:
I don't know whether this currently happens with Fedora, but it
is not
at all irrelevant and systemd could indeed make the situation much
worse.
A typical problem in the past has been that starting dbus includes
looking at users and groups which means you need ldap and network but oh
wait networkmanager starts after dbus. This can cause _really_ long
timeouts during boot, basically a hang. (I might have gotten some detail
wrong but something like the above can happen. There are workarounds and
also SSSD might be better than nss_ldap here.)
So what I'm saying is, we already have this problem and it already has
to be dealt with manually by booting in single user mode or press I at
the right point during boot.
Possibly systemd will actually help, as it might make it possible that
at least the text mode logins appear even if there's a deadlock starting
some deamons.
Can systemd track dependecies (deamon foo connects to socket for deamon
bar) and detect and print error messages about deadlocks? Maybe even
break the loops, causing some deamons to just fail to start?
/Alexander
2:12 p.m.
On Thu, 22 Jul 2010 18:35:22 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 11:29, Simo Sorce (ssorce(a)redhat.com) wrote:
> > they hence would have needed to be started one after the other, so
> > that every service using another services can be sure it can talk
> > to the one it needs. I mean, how awesome is that? We can
> > completely remove *any* kind of serialization from daemon startup.
>
> how do you deal with circular dependencies in this case?
> I mean what will happen ? Will all services just deadlock?
> Malfunction ? Anything that guarantees correct initialization and
> behavior ?
If a service A uses functionality provided by a service B which in
turn uses functionality provided by A then things willbreak regardless
whether systemd is used or not.
This is not true.
SSSD is an example of that.
The nss_sss and pam_sss clients know to immediately give up if the
sockets are not there because that means that sssd is not up yet.
Once sssd is up they will start working. This way if a service comes up
1st in the system and do some stupid enumeration getpwent() it will not
block with timeouts or what not. After all if it is a system service
and does an enumeration so early it is certainly not interested in
non-system users.
If I were to use socket activation instead that service would bring
sssd up unnecessarily early, before the network is up. This in turn
will cause sssd to go in offline mode and have a 30 sec delay before it
tries again to go online, failing any authentication for users that are
not already cached (with credentials cached).
Now this will probably mitigated by the fact that we monitor network
interfaces in newer versions and will try to get online earlier if an
interface suddenly appears, but I hope you get the point.
Cyclic dependencies cause deadlocks. Introducing systemd has little
effect on that. It won't make the situation worse, and it won't make
itmuch better either.
I beg to differ, you are changing how dependencies are handled, and can
*cause* cyclic dependencies because of how you make socket activation
work.
Or in other words: If somebody writes a syslog implementation that
writes its logged data to mysql, ignoring that mysql actually itself
logs to syslog, then it is his own fault, and this simply doesn't
work, regardless if syslog or mysql is socket-activated or not, or
whether systemd is used at all. It cannot work, already on a
theoretical level.
This is not the case, although also in SSSD we have code to prevent
libraries from deadlocking us when they try to to getpw* calls (like
libdbus).
Or in even other words: this is a theoretical problem, not a
practical
one, and orthogonal to the problem set systemd tries to solve.
I wish it were true.
It is your attitude to ignore this kind of problems and just mark
them as impossible or unimportant that really scares me. I look back
and I see some of the pulseaudio failures all over again .oO("It's your
kernel driver that sucks, I don't care, pulseaudio works fine with
mine, so I won't even attempt a workaround").
Ignoring scenarios just because they are complex to deal with does not
make them go away. Software will not have the luxury to ignore them.
When it is audio I may not care, when it is the init system I do.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:12 p.m.
On Thu, 22.07.10 15:12, Simo Sorce (ssorce(a)redhat.com) wrote:
> If a service A uses functionality provided by a service B which
in
> turn uses functionality provided by A then things willbreak regardless
> whether systemd is used or not.
This is not true.
SSSD is an example of that.
The nss_sss and pam_sss clients know to immediately give up if the
sockets are not there because that means that sssd is not up yet.
Once sssd is up they will start working. This way if a service comes up
1st in the system and do some stupid enumeration getpwent() it will not
block with timeouts or what not. After all if it is a system service
and does an enumeration so early it is certainly not interested in
non-system users.
Note that we install normal daemon sockets after sysinit ran and the
mount points are established. That basically means that during early
bootup the socket wouldn't be around aynway. Only when other normal
daemons start up the sssd socket would be accessible.
If I were to use socket activation instead that service would bring
sssd up unnecessarily early, before the network is up. This in turn
will cause sssd to go in offline mode and have a 30 sec delay before it
tries again to go online, failing any authentication for users that
are not already cached (with credentials cached).
Now this will probably mitigated by the fact that we monitor network
interfaces in newer versions and will try to get online earlier if an
interface suddenly appears, but I hope you get the point.
Well, to be frank I think sssd would be broken if it enters a mode where
it systematically timeouts requests like this. The right fix is I
believe what you already mentioned: to watch network configuration via
netlink.
Networks today are dynamic. They come and go all the time. Connectivity
is not reliable. It cannot be assumed that a network is guaranteed to be
available on boot at all. You must follow network changes in cases like
yours and react to that.
Or in other words: think of a web browser which would instead of telling
the user in a clean message box "Network not available, blah blub"
simply timeout after 30s hoping that a network might still show up. That
would be awful.
So yes, cyclic dependencies can happen with and without socket
activation, maybe some become more visible with than without it. However
others might actually become less visible. But the fact is still that if
you have blocking calls in two ways between two services, then you will
enter a deadlock sooner or later. Maybe it won't happen during "normal"
operation, but it still be triggerable if a malicious user comes into
play. The right fix is to make the calls either non-blocking or simply
get rid of the cyclic dependency. And that fact doesn't change whether
socket actviation is used or not.
> Cyclic dependencies cause deadlocks. Introducing systemd has
little
> effect on that. It won't make the situation worse, and it won't make
> itmuch better either.
I beg to differ, you are changing how dependencies are handled, and can
*cause* cyclic dependencies because of how you make socket activation
work.
Well, in your sssd example above the cyclic dependency exists with or
without systemd. You try to work around this fact in saying "well,
I simply say that nobody could ever need my services before a certain
point P in time after boot, and I'll just refuse all services before
that." However, that is a really broken requirement to make. Why?
Because it basically means you imply an ordering dependency on your
socket creation, that is neither expressable with LSB init headers, nor
with systemd. The dependency you need is: "make sure to start
services A, B, C *BEFORE* me, and everything else *AFTER* me". Where A,
B, C is probably something like syslog, and "everything else" might be
stuff like ssh, policykit, accounts-daemon, the gettys or gdm which
might need your services because they offer services related to
non-system users. Neither systemd nor LSB can offer you this kind of
order dependencies. There is no such thing as expressing "before
everything but A, B, C". You currently nonetheless require this, and
that is simply broken. Because already with LSB your init script doesn't
actually do what you seem to believe it does.
And systemd or not systemd, and socket based or not socket based
actviation does not change anything about this.
Also, if you look at sssd and a simple hypothetical syslog daemon which
looks up the user id of everybody connecting to it. If sssd is used this
will deadlock: sssd logs to syslog, and syslog uses NSS to resovle your
user id and hence sssd, and sssd won't reply because it is still
waiting for the syslog write to go through. And there you have it: your
system is deadlocked. You currently get away here, because you say:
"well, i assume that all current syslog implementations only look up
names via NSS during initialization for dropping privs and not anymore
during runtime. And hence if we refuse NSS lookups during initialization
we can get out of the problem." But that is a dirty trick, and sooner or
later syslog implementations might show up that actually use NSS during
normal operation too (for example, I am still waiting for a syslog
daemon which uses SCM_CREDENTIALS to receive trustable source
information for log messages, and this might very well look up the uids
in NSS then). Also, there might already be daemons which fall into the
trap you set up for them: for example i am pretty sure you find syslog
daemons which do NSS lookups during configuration reload or when
rotating log files. If that happens, and at
the very same time you try to log something then you have the deadlock:
you try to log and the logger waits for the NSS request to finish. And
all that during runtime, hours after sssd and syslog started up. And it
doesn't help that you refuse service to syslog during its installation.
Now, you might come up with the idea that the large socket buffer would
ensure you never block when logging. But that's not really of any
help. On fedora any user can log to syslog. So you have a rogue user
which connects a few /usr/bin/logger instances to /dev/urandom and he
can easily make sure that the socket buffer runs full all the time, and
your log write will hence have to wait until the syslog implementation
reads from the socket again. But it won't beacuse it waits for you.
So anyway. What I am saying is that you cannot evade the dep cycle loops
by making assumptions when other daemons validly or invalidly do NSS
lookups. You need to get rid of the dep cycles. Otherwise, you will
sooner or later run into deadlocks. Maybe they won't be triggered during
normal operation. But well, as soon as an evil user comes to play, then
you lost. (He actually can make the entire machine stand still this way:
if syslog deadlocks in an NSS call that sssd cannot process then no
syslog messages will be processed and step by step all daemons on the
system will come to a standstill as soon as they write something to
syslog.)
To get rid of dep cycles we have to declare which daemon may use which
other daemon. For example, for the case of mysql and syslog, we can say
that mysql is client and syslog is server and then be done with it. If
we look on sssd things are a bit different though: I think we must allow
syslog to execute NSS queries. And that basically means that sssd as
backend of NSS cannot be allowed to use syslog. (unless you write your
own client implementation for /dev/log which works asynchronously and
buffers messages locally if they cannot be written).
> Or in even other words: this is a theoretical problem, not a
practical
> one, and orthogonal to the problem set systemd tries to solve.
I wish it were true.
It is your attitude to ignore this kind of problems and just mark
them as impossible or unimportant that really scares me. I look back
and I see some of the pulseaudio failures all over again .oO("It's your
kernel driver that sucks, I don't care, pulseaudio works fine with
mine, so I won't even attempt a workaround").
Oh come on. I am not ignoring this. I gave you long explanations why I
think that dep loops like this are broken, independently of systemd. We
have thought about this issue too: but the simple fact is that your
software is broken if it has a dep cycle. Fix your software properly,
don't blame systemd that it doesn't allow you to employ "fixes" that
actually just hide the problem a bit longer.
Oh, and thanks a ton for the PA comparison. If you claim I said
something like you suggested, then please find me a quote. And otherwise
please don't make implications on what I might be thinking or not,
because well, PA might not be perfect but it is certainly more
the trigger not the cause of the problems. If you'd have followed up on
this you'd have known that. And otherwise you are just spreading
FUD. but anyway, I think this is the wrong place to say any more about
PA here.
Ignoring scenarios just because they are complex to deal with does
not
make them go away. Software will not have the luxury to ignore them.
Well, it's you who is ignoring that his software is prone to
deadlocks. I am just pointing you to that.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:19 p.m.
On Fri, 23 Jul 2010 04:12:53 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
Well, in your sssd example above the cyclic dependency exists with
or
without systemd. You try to work around this fact in saying "well,
I simply say that nobody could ever need my services before a certain
point P in time after boot, and I'll just refuse all services before
that." However, that is a really broken requirement to make. Why?
Because it basically means you imply an ordering dependency on your
socket creation, that is neither expressable with LSB init headers,
nor with systemd. The dependency you need is: "make sure to start
services A, B, C *BEFORE* me, and everything else *AFTER* me". Where
A, B, C is probably something like syslog, and "everything else"
might be stuff like ssh, policykit, accounts-daemon, the gettys or
gdm which might need your services because they offer services
related to non-system users. Neither systemd nor LSB can offer you
this kind of order dependencies. There is no such thing as expressing
"before everything but A, B, C". You currently nonetheless require
this, and that is simply broken. Because already with LSB your init
script doesn't actually do what you seem to believe it does.
No I don't require any order, I just said that sssd may not be able to
reply with fresh data until the network is up, which is quite different.
Also what I said is that if the sockets are not available, applications
are not stuck, they just don't get any data that sssd would provide and
they go on with their business.
What I was trying to tell however is that it's not all so linear as you
describe it. In some case it will just work out to be that way, in
other it won't, I just want to make sure you realize there are other
valid cases and take them in account.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:21 p.m.
On Fri, 23 Jul 2010 04:12:53 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
Also, if you look at sssd and a simple hypothetical syslog daemon
which looks up the user id of everybody connecting to it. If sssd is
used this will deadlock: sssd logs to syslog, and syslog uses NSS to
resovle your user id and hence sssd, and sssd won't reply because it
is still waiting for the syslog write to go through.
Luckily sssd is built to prevent things like this being a multi-process
system that uses a common cache to reply to request without ever
blocking.
Of course if you really find a way to lock it up I am more than happy
to see a reproduceable case in order to fix it :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:23 p.m.
On Fri, 23 Jul 2010 04:12:53 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
To get rid of dep cycles we have to declare which daemon may use
which
other daemon. For example, for the case of mysql and syslog, we can
say that mysql is client and syslog is server and then be done with
it. If we look on sssd things are a bit different though: I think we
must allow syslog to execute NSS queries. And that basically means
that sssd as backend of NSS cannot be allowed to use syslog. (unless
you write your own client implementation for /dev/log which works
asynchronously and buffers messages locally if they cannot be
written).
Luckily I have ways to prevent loops, don't worry, that was problem
number I had to resolve many many moons ago, it is taken care of.
But I think we are getting wildly off-topic anyway.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:31 p.m.
Let's go off into a tangent:
Just booted my x86_64 rawhide box (up to date) into systemd. SELinux is
enforcing.
Boot works, but not graphical boot.
The output from the rc scripts is messed up ([OK] in gray, not green; not
at the end of the line but at the start of the next). Several fail.
X doesn't start (yes, /lib/systemd/system/graphical.target is
default.target). I can log into my account here, and on startx XFCE shows
up (my configuration says Gnome on Openbox).
NetworkManager doesn't start, it seems dbus.service is hosed. "systemctl
status dbus.service" just hangs. I've got the following (pasted together
from the output of "ps -l -p <pid>" for the pids given by "pgrep
dbus")
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
1 S 500 1952 1 0 80 0 - 5084 poll_s ? 00:00:00 dbus-launch
1 S 500 1953 1 0 80 0 - 7251 poll_s ? 00:00:00 dbus-daemon
0 Z 0 2680 1 0 80 0 - 0 exit ? 00:00:00 dbus <defunct>
Running quadrapassel (from gnome-games-extra-2.31.4-1.fc14.x86_64) gives:
failed to create drawable
Failed to initialise clutter: Unable to select the newly created GLX context
Seems something took out Gnome... but several other Gnome games (mahjongg
from gnome-games-extra-2.31.4-1.fc14.x86_64, sol from
gnome-games-2.31.4-1.fc14.x86_64) work fine. gnome-terminal also works.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
9 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/22/2010 11:31 PM, Horst H. von Brand wrote:
Let's go off into a tangent:
Just booted my x86_64 rawhide box (up to date) into systemd. SELinux is
enforcing.
Boot works, but not graphical boot.
The output from the rc scripts is messed up ([OK] in gray, not green; not
at the end of the line but at the start of the next). Several fail.
X doesn't start (yes, /lib/systemd/system/graphical.target is
default.target). I can log into my account here, and on startx XFCE shows
up (my configuration says Gnome on Openbox).
NetworkManager doesn't start, it seems dbus.service is hosed. "systemctl
status dbus.service" just hangs. I've got the following (pasted together
from the output of "ps -l -p <pid>" for the pids given by "pgrep
dbus")
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
1 S 500 1952 1 0 80 0 - 5084 poll_s ? 00:00:00 dbus-launch
1 S 500 1953 1 0 80 0 - 7251 poll_s ? 00:00:00 dbus-daemon
0 Z 0 2680 1 0 80 0 - 0 exit ? 00:00:00 dbus <defunct>
Running quadrapassel (from gnome-games-extra-2.31.4-1.fc14.x86_64) gives:
failed to create drawable
Failed to initialise clutter: Unable to select the newly created GLX context
Seems something took out Gnome... but several other Gnome games (mahjongg
from gnome-games-extra-2.31.4-1.fc14.x86_64, sol from
gnome-games-2.31.4-1.fc14.x86_64) work fine. gnome-terminal also works.
This is
caused by selinux. I have sent a patch for systemd to handle
masquerading as dbus and avahi for SELinux.
If you look at your avc messages you will denials about sending messages
to init_t.
I have another patch coming for systemd to handle the creation of
directories with the proper labels.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxJoGcACgkQrlYvE4MpobOKXgCgn1UBdRLze+YkkqYRcPoH6le2
cmkAoOW1GwlN0JswE/lQ65hLDln6bYQZ
=zfP+
-----END PGP SIGNATURE-----
9:29 a.m.
Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
Let's go off into a tangent:
Just booted my x86_64 rawhide box (up to date) into systemd. SELinux is
enforcing.
Boot worked, but the machine got stuck on shudown. Had to power off. Thanks
$DEITY for journalling filesystems...
I saw comments on selinux-policy-targeted-3.8.8-3.fc14.noarch (today's
update) that might be relevant here, will check later.
BTW, why isn't there a specfile inside the git repo for systemd? That might
be the best way to get masoch^Winterested testers to check out the latest
versions that are being discussed here (as command names and flags are
still somewhat in flux, following the discussion can get hard).
Another point that has been bothering me: systemd will run with _very_ high
privileges under SELinux (being able to impersonate a lot of infrastructure
services is almost as good as being root with traditional Unix security).
So its requirements (software wise) should be as minimal as possible (to
make a thorough audit feasible). But it requires gtk+ and vala to build.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
10:58 a.m.
tor 2010-07-22 klockan 15:12 -0400 skrev Simo Sorce:
The nss_sss and pam_sss clients know to immediately give up if the
sockets are not there because that means that sssd is not up yet.
If I were to use socket activation instead that service would bring
sssd up unnecessarily early, before the network is up. This in turn
will cause sssd to go in offline mode and have a 30 sec delay before it
Now this will probably mitigated by the fact that we monitor network
interfaces in newer versions and will try to get online earlier if an
interface suddenly appears, but I hope you get the point.
But this means that SSSD + socket activation would work quite well,
pretty much the same was as it does as a standalone deamon, right?
/Alexander
10:31 a.m.
On Thu, 22 Jul 2010 16:49:50 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
3. Robustness: The sockets stay around all the time, and always
connectable. You can kill a daemon but you won't lose a single
connection while doing that! Particularly for stateless protocols
(such as DNS or syslog) we can automatically restart a daemon when it
crashes, and when it comes back it will go on where it left of, as if
nothing happened! The client will not even notice! How awesome is
that? Restarting daemons without losing connections?
How many truly statless protocols use a stateful connection ?
right now if you restart syslog you already don't miss anything, same
for DNS, where is the advantage there ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:04 p.m.
On Thu, 22.07.10 11:31, Simo Sorce (ssorce(a)redhat.com) wrote:
On Thu, 22 Jul 2010 16:49:50 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> 3. Robustness: The sockets stay around all the time, and always
> connectable. You can kill a daemon but you won't lose a single
> connection while doing that! Particularly for stateless protocols
> (such as DNS or syslog) we can automatically restart a daemon when it
> crashes, and when it comes back it will go on where it left of, as if
> nothing happened! The client will not even notice! How awesome is
> that? Restarting daemons without losing connections?
How many truly statless protocols use a stateful connection ?
right now if you restart syslog you already don't miss anything, same
for DNS, where is the advantage there ?
That's no true. Traditionally, if you stop syslog and then restart it
the socket will be closed and removed from the file system. If clients
log during that time the log message will be lost because /dev/log is not
accessible. And syslog logging is not repeated by the client side if it
fails.
On DNS this is slightly different, as DNS requests are repeated on
failure.
But also HTTP is a good candidate. When apache shuts down it closes the
listening socket but will finish processing the requests it already
began to process. Would apache use socket actviation like this it would
hence be restartable without loosing a single HTTP connection: what is
already accepted will be processed, but what has not been accepted yet
will be delayed until apache is back up again.
Something similar is of course true for every state-less protocol like
this, where each requests can be processed independently of every other
request.
And when a daemon crashes only the requests that were currently
processed will be lost, all others stay queued and will then be deqeued
and processed after the restart.
Socket activation does not prevent all kinds of data loss or denial of
service when a daemon crashes. However it is actually big step to make
the data loss minimal and the outage window as short as possible.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:19 p.m.
On Thu, 22 Jul 2010 19:04:44 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
But also HTTP is a good candidate. When apache shuts down it closes
the listening socket but will finish processing the requests it
already began to process. Would apache use socket actviation like
this it would hence be restartable without loosing a single HTTP
connection: what is already accepted will be processed, but what has
not been accepted yet will be delayed until apache is back up again.
Something similar is of course true for every state-less protocol like
this, where each requests can be processed independently of every
other request.
And when a daemon crashes only the requests that were currently
processed will be lost, all others stay queued and will then be
deqeued and processed after the restart.
Socket activation does not prevent all kinds of data loss or denial of
service when a daemon crashes. However it is actually big step to make
the data loss minimal and the outage window as short as possible.
Bad example, it may make sense if you have a single host, but if you
have multiple HTTP servers, you want the one that died to stop answering
until it is back up and running and ready to server requests.
The last thing you want is to have a client wait forever because the
systemd doesn't kill the socket but apache is not able to properly
restart (say for a configuration mistake).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
6:31 p.m.
On Thu, 22.07.10 15:19, Simo Sorce (ssorce(a)redhat.com) wrote:
> But also HTTP is a good candidate. When apache shuts down it
closes
> the listening socket but will finish processing the requests it
> already began to process. Would apache use socket actviation like
> this it would hence be restartable without loosing a single HTTP
> connection: what is already accepted will be processed, but what has
> not been accepted yet will be delayed until apache is back up again.
>
> Something similar is of course true for every state-less protocol like
> this, where each requests can be processed independently of every
> other request.
>
> And when a daemon crashes only the requests that were currently
> processed will be lost, all others stay queued and will then be
> deqeued and processed after the restart.
>
> Socket activation does not prevent all kinds of data loss or denial of
> service when a daemon crashes. However it is actually big step to make
> the data loss minimal and the outage window as short as possible.
Bad example, it may make sense if you have a single host, but if you
have multiple HTTP servers, you want the one that died to stop answering
until it is back up and running and ready to server requests.
The last thing you want is to have a client wait forever because the
systemd doesn't kill the socket but apache is not able to properly
restart (say for a configuration mistake).
Well, not everything makes sense in all contexts. If you have a fallback
web server in place then you don't need this trick. But I am pretty sure
there are more web serving devices on this planets that do no failover
like you suggest then there are that do this. And for those, which
otherwise have no defined fallback path it is certainly really awesome
if they can just restart apache if it crashes and can rest assured that
they won't lose any request except the one apache actually crashed on.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:30 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 15:19, Simo Sorce (ssorce(a)redhat.com) wrote:
[...]
> Bad example, it may make sense if you have a single host, but if
you
> have multiple HTTP servers, you want the one that died to stop answering
> until it is back up and running and ready to server requests.
>
> The last thing you want is to have a client wait forever because the
> systemd doesn't kill the socket but apache is not able to properly
> restart (say for a configuration mistake).
Well, not everything makes sense in all contexts. If you have a
fallback
web server in place then you don't need this trick. But I am pretty sure
there are more web serving devices on this planets that do no failover
like you suggest then there are that do this. And for those, which
otherwise have no defined fallback path it is certainly really awesome
if they can just restart apache if it crashes and can rest assured that
they won't lose any request except the one apache actually crashed on.
Sorry, but what if the configuration got screwed up, and <whatever daemon>
just won't start properly? Was replaced by a broken version which crashes
on startup? Or gets into a loop (or just does something very timeconsuming
sometimes) before being ready to answer? This _needs_ answers.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
9:17 p.m.
On Thu, 22.07.10 21:30, Horst H. von Brand (vonbrand(a)inf.utfsm.cl) wrote:
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> On Thu, 22.07.10 15:19, Simo Sorce (ssorce(a)redhat.com) wrote:
[...]
> > Bad example, it may make sense if you have a single host, but if you
> > have multiple HTTP servers, you want the one that died to stop answering
> > until it is back up and running and ready to server requests.
> >
> > The last thing you want is to have a client wait forever because the
> > systemd doesn't kill the socket but apache is not able to properly
> > restart (say for a configuration mistake).
> Well, not everything makes sense in all contexts. If you have a fallback
> web server in place then you don't need this trick. But I am pretty sure
> there are more web serving devices on this planets that do no failover
> like you suggest then there are that do this. And for those, which
> otherwise have no defined fallback path it is certainly really awesome
> if they can just restart apache if it crashes and can rest assured that
> they won't lose any request except the one apache actually crashed on.
Sorry, but what if the configuration got screwed up, and <whatever daemon>
just won't start properly? Was replaced by a broken version which crashes
on startup? Or gets into a loop (or just does something very timeconsuming
sometimes) before being ready to answer? This _needs_ answers.
Well, if a service might take an hour to start up it is not a good
candidate for socket activation.
We ratelimit process spawning in systemd. If a unit is respawned too
often in a certain amount of time we give up and put the service in
maintainance mode. Simialr for the socket.
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:18 a.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 21:30, Horst H. von Brand (vonbrand(a)inf.utfsm.cl)
wrote:
> Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> > On Thu, 22.07.10 15:19, Simo Sorce (ssorce(a)redhat.com) wrote:
>
> [...]
> Sorry, but what if the configuration got screwed up, and
<whatever daemon>
> just won't start properly? Was replaced by a broken version which crashes
> on startup? Or gets into a loop (or just does something very timeconsuming
> sometimes) before being ready to answer? This _needs_ answers.
Well, if a service might take an hour to start up it is not a good
candidate for socket activation.
Sure isn't. The problem is how to handle a service that usually starts in
a tenth of a second for some reason today takes forever.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
10:11 a.m.
On Thu, Jul 22, 2010 at 03:52:06PM +0200, drago01 wrote:
>> > That's what we call a successful transition. Now,
we can incrementally
>> > introduce improvements over the next few releases.
>> Once you start doing that people will cry because it is different from
>> what they are used too (does not matter if the change is for the
>> better or worse).
> So, let me ask a question: why do you think people have that response?
Read this thread? Or any other one that introduces any major change?
I'm sorry; let me rephrase. What do you think it is that *causes* that
response in people?
No, but even if would be very unlikely ... producing books costs
time
and money you don't do it because someone said "sometime we will start
using foo".
If anything books document existing stuff (and most of the time lag
behind), not what is planned in X years.
I've been the technical editor on several Linux books, and done technical
review for others. While they do document what exists, having changes sells
new editions, so keeping current is a priority.
> Leadership means making careful, well-conceived decisions.
Otherwise,
> it's not leading, it's charging around blindly shouting "follow
me!".
Yeah, systemd seems to replace a part of the system which has been
pretty much stagnant for ever and implements a lot of interesting
concepts.
On the other side we have "it isn't 100% like sysvinit" ...
That isn't, actually, a fair representation of the "other side".
> Instead, you seem to be trying to argue that change comes for
free.
No I am just saying that a change isn't bad because it is a change.
"Bad" is a value judgement that I think is unhelpful here. It's not that
change is _bad_, it's that change isn't cost-neutral. When you want to
change something, you're starting at the bottom of the hill, not at a
neutral middle ground.
> (And
> that those who have to pay this cost are "crying".)
Everyone has to pay this cost and everyone gets something in return.
And the way you present this as an _overall win_ is by emphasizing the
returns and decreasing the costs.
What I hear is discounting the costs as real, rather than actually trying to
decrease them. This makes enemies out of your would-be supporters.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:20 a.m.
On Thu, Jul 22, 2010 at 11:11:31AM -0400, Matthew Miller wrote:
On Thu, Jul 22, 2010 at 03:52:06PM +0200, drago01 wrote:
> Everyone has to pay this cost and everyone gets something in return.
And the way you present this as an _overall win_ is by emphasizing the
returns and decreasing the costs.
What I hear is discounting the costs as real, rather than actually trying to
decrease them. This makes enemies out of your would-be supporters.
Congratulations on a not-very-charged statement of how to use this
thread constructively. When the experienced system administrators in
this thread bring in their real-world cases of "How should we deal
with common situation <X>?", that should be answered with "You can do
that in the following ways: <Y>. And if that doesn't work, let's
discuss *how* it doesn't work," all of which can be done without
attacking people's skills, intelligence, foresight, or motives on
either side.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
12:46 p.m.
On Thu, 2010-07-22 at 09:22 -0400, Matthew Miller wrote:
I am not getting the message from this thread that systemd
developers
believe that. Rather, we get "it's clearly a matter of taste and
bike-shedding", and "I probably shouldn't even have bothered to even reply
to this mail of yours."
Matt, anyone can pull two quotes out of an ongoing thread and make
someone look bad. I'd have no trouble doing the same for you in this
thread. Lennart has already posted messages making it clear he's
considering, has already accepted or even has already implemented
several suggestions from this thread. It's simply disingenuous to
suggest he's not listening to feedback.
Can we please stick to the technical issues here? That is, how we should
implement systemd to make the transition from upstart/sysv as painless
as possible, and perhaps some semantic improvements to the parameters
and command names Lennart has chosen for systemd. These really don't
need to be emotive issues.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:37 p.m.
On Thu, Jul 22, 2010 at 9:46 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
Can we please stick to the technical issues here? That is, how we
should
implement systemd to make the transition from upstart/sysv as painless
as possible, and perhaps some semantic improvements to the parameters
and command names Lennart has chosen for systemd. These really don't
need to be emotive issues.
Mailings lists are really are good at twisting personality quirks into
weird conflicts. Its always amazing to me how differently I react to
some people when I'm in person with them versus talking to them on a
mailing list or email about the same issue...especially when there is
some conflict...doubly so when the other person isn't a native English
speaker. It's really easy to read malice and intention to offend into
statements in this medium. I have a sneaky suspicion that
statistically, the amount of time you interact with a person
face-to-face greatly impacts the tone of conflict resolution is
handled in mediums when aggregated across the interactions of many
many people. Not that knowing that helps any of us be better at
avoiding it from happening to us.
I'd wager that if we were having this discussion in a room with the
very same people, I think the emotional reactions over the areas of
conflict would be much reduced and personality quirk mismatches
wouldn't cause so much static.
We also seem to get into this sort of cycle when parties have inverted
priority lists. They may actually care about the very same things..
but the priority values don't match up. When priorities are inverted
its actually more heated than when one party doesn't care at all about
something that the other party cares about. Areas of compromise come
in the middle ground of a priority list...so when things are
inverted.. its harder to get to that compromise even though we
actually all _care_,
In this case, we know that systemd developers care about backwards
compatibility to some degree. It does work with traditional sysinit
files out of the box. In fact is clearly a pretty high priority to
them..they didn't break the world. We have a workable fallback
position from native systemd unit files because of that.
One of the questions _we_ as a distribution should consider is how do
we expose that fallback position to sysadmins. How easy do _we_ make
it for local sysadmins to transition their heterogeneous management
infrastructure to support transitioning to system native files..or if
need be falling back to legacy sysinit style files to better integrate
F14 into their environments.
Personally, speaking as a person _and_ a sysadmin, it would be
worthwhile to have a big freakin button somewhere that allowed me to
disable all native systemd config files and let me run sysinit style
files when the situation demands... ie crap like puppeted
configurations. It doesn't have to be the default but something that
lets me get Fedora 14 into my existing local managed environment and
start the transition process to native systemd on the timescale that
makes sense in context of that local management infrastructure.
-jef
2:59 p.m.
On Thu, Jul 22, 2010 at 10:37:20AM -0800, Jeff Spaleta wrote:
[...]
I'd wager that if we were having this discussion in a room with
the
very same people, I think the emotional reactions over the areas of
conflict would be much reduced and personality quirk mismatches
wouldn't cause so much static.
[...]
ISTR this was much the case when we discussed Upstart at the FUDCon in
Raleigh, NC in 2008.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
3:21 p.m.
On 07/22/2010 06:37 PM, Jeff Spaleta wrote:
Personally, speaking as a person_and_ a sysadmin, it would be
worthwhile to have a big freakin button somewhere that allowed me to
disable all native systemd config files and let me run sysinit style
files when the situation demands... ie crap like puppeted
configurations. It doesn't have to be the default but something that
lets me get Fedora 14 into my existing local managed environment and
start the transition process to native systemd on the timescale that
makes sense in context of that local management infrastructure.
I think it's time to re-inform everyone since they seemed to be so
focused on systemd and have completely forgot about upstart.
Nobody has said anything that upstart was being deprecated nobody!
However Lennart has mentioned before he already has created a patch
which makes upstart parallel installable with systemd but somehow nobody
noticed that in the discussion probably due to that fact they were to
focused on systemd and all the doom it brings.
FESCO made sure that we could back out of this if it all went south and
what do you think the fallback is ;)
So we can all be on the same page if you dont want to use systemd you
are not being forced to do so.
Systemd might be the default in F14 but upstart is still alive and kicking.
All you have to do is to install the upstart package after his patch has
landed ( Casey already had OK the patch their just waiting for OK from
Bill which is on vacation or was ) and add this line on the kernel
command line "init=/sbin/upstart" and everything will continue to work
as it always has.
In short no systemd doom of horror will rain upon ye ;)
It should be in every sysadmins capability adding the package and add
the kernel parameter.
Now that everybody has been (re)informed we can go back on focusing
working out these issues together without any negativity on any ones behalf.
JBG
4:09 p.m.
2010/7/22 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
I think it's time to re-inform everyone since they seemed to be
so
focused on systemd and have completely forgot about upstart.
Nobody has said anything that upstart was being deprecated nobody!
That's not exactly what I'm talking about... though that's certainly
another fallback position which should I hope provide enough of a
fallback solution for Chris others who agree with him.
I'm talking about the _better_ fallback position of relying on
systemd's compatibility with sysinit style init instead of systemd
native files when specific sysadmins find that their
configuration/management infrastructure isn't ready to handle the
native files and then work towards moving services to native as they
get more confident in the new configuration format.
Sure going back to upstart provides a fallback, but not in a way that
encourages people to start dealing with the changes in their local
policy and to wrap their heads around systemd native stuff. I don't
want to help people hide from systemd, I want to encourage admins to
get familiar with systemd at the pace that makes sense for them in
their environment. I think advertising sysinit styled init fallback
running under systemd with no native configs that admins can choose
makes sense if we can do it.
-jef
8:42 p.m.
Jeff Spaleta <jspaleta(a)gmail.com> wrote:
2010/7/22 "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com>:
> I think it's time to re-inform everyone since they seemed to be so
> focused on systemd and have completely forgot about upstart.
>
> Nobody has said anything that upstart was being deprecated nobody!
That's not exactly what I'm talking about... though that's certainly
another fallback position which should I hope provide enough of a
fallback solution for Chris others who agree with him.
I'm talking about the _better_ fallback position of relying on
systemd's compatibility with sysinit style init instead of systemd
native files when specific sysadmins find that their
configuration/management infrastructure isn't ready to handle the
native files and then work towards moving services to native as they
get more confident in the new configuration format.
Compatibility with native SysVinit-style upstart is of very little help if
the relevant commands (at least the most used options) aren't
available. E.g. when the big switchover from ipchains to iptables was in
swing, you could (almost) use your old configuration files (mostly calls to
the relevant commands) with no change.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
6:08 p.m.
On Thu, Jul 22, 2010 at 08:21:59PM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/22/2010 06:37 PM, Jeff Spaleta wrote:
> Personally, speaking as a person_and_ a sysadmin, it would be
> worthwhile to have a big freakin button somewhere that allowed me to
> disable all native systemd config files and let me run sysinit style
> files when the situation demands... ie crap like puppeted
> configurations. It doesn't have to be the default but something that
> lets me get Fedora 14 into my existing local managed environment and
> start the transition process to native systemd on the timescale that
> makes sense in context of that local management infrastructure.
I think it's time to re-inform everyone since they seemed to be so
focused on systemd and have completely forgot about upstart.
Nobody has said anything that upstart was being deprecated nobody!
However Lennart has mentioned before he already has created a patch
which makes upstart parallel installable with systemd but somehow nobody
noticed that in the discussion probably due to that fact they were to
focused on systemd and all the doom it brings.
FESCO made sure that we could back out of this if it all went south and
what do you think the fallback is ;)
So we can all be on the same page if you dont want to use systemd you
are not being forced to do so.
Systemd might be the default in F14 but upstart is still alive and kicking.
All you have to do is to install the upstart package after his patch has
landed ( Casey already had OK the patch their just waiting for OK from
Bill which is on vacation or was ) and add this line on the kernel
command line "init=/sbin/upstart" and everything will continue to work
as it always has.
In short no systemd doom of horror will rain upon ye ;)
It should be in every sysadmins capability adding the package and add
the kernel parameter.
Now that everybody has been (re)informed we can go back on focusing
working out these issues together without any negativity on any ones behalf.
This may not be true. No packaging guidelines have been put forth
for systemd yet so I cannot know:
* if we continue to require sysVinit scripts in the guidlines, this is true.
* If we don't, then sysadmins that have to install packages without sysvinit
scripts will have to deal with writing their own init scripts.
-Toshio
8:07 p.m.
On Thu, 22.07.10 19:08, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> Now that everybody has been (re)informed we can go back on
focusing
> working out these issues together without any negativity on any ones behalf.
>
This may not be true. No packaging guidelines have been put forth
for systemd yet so I cannot know:
* if we continue to require sysVinit scripts in the guidlines, this is true.
* If we don't, then sysadmins that have to install packages without sysvinit
scripts will have to deal with writing their own init scripts.
My take on this is that sysvinit scripts should be a requirement, and
systemd unit files an optional addition. Given that the guidelines have
not been updated in any way this is basically what the guideliness
currently say.
And the for F15 we can reinvestiaget this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:54 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
> * if we continue to require sysVinit scripts in the guidlines,
this is true.
> * If we don't, then sysadmins that have to install packages without sysvinit
> scripts will have to deal with writing their own init scripts.
My take on this is that sysvinit scripts should be a requirement, and
systemd unit files an optional addition. Given that the guidelines have
not been updated in any way this is basically what the guideliness
currently say.
I would say until we get a coherent story and guidelines on the packaging,
activation, etc. of systemd unit files in a way that's unlikely to change
long-term, that systemd unit files should not be encouraged. I don't want to
have to train packagers each release.
That being said, from reading the rest of this thread, it looks like we're
making progress on that front.
Bill
8:44 p.m.
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
[...]
This may not be true. No packaging guidelines have been put forth
for systemd yet so I cannot know:
* if we continue to require sysVinit scripts in the guidlines, this is true.
* If we don't, then sysadmins that have to install packages without sysvinit
scripts will have to deal with writing their own init scripts.
I'd suggest keeping them around until RHEL ships with native systemd + 1
Fedora cycle.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
3:06 p.m.
"Jóhann B. Guðmundsson" (johannbg(a)gmail.com) said:
Nobody has said anything that upstart was being deprecated nobody!
Actually, I'll say that, sort of.
Fedora 14 should only ship with one automatic init system. Given the
current feature, that would be systemd. If it fails, that would be
upstart. But I'm firmly of the opinion that allowing people to pick their
own set of breakage in init systems is a really bad idea.
Bill
5:08 p.m.
On Thu, 2010-07-22 at 09:22 -0400, Matthew Miller wrote:
Leadership means making careful, well-conceived decisions. Otherwise,
it's
not leading, it's charging around blindly shouting "follow me!".
I'll leave the rest of the thread to Matthew and Mike McGrath, since
they seem to share my position on almost all of this, but I would like
to specifically call out the above as exactly the right point. It's not
about whether something new is great and useful - or even about systemd
in particular - it's about trying to have a cohesive, usable
distribution, making progress without being annoying.
Jon.
P.S. Also, about the use of "Change". Change is good, but not all change
is good, and change for the sake of change isn't always good either.
Just like in politics, we can use the word "Change" to reflect a liberal
agenda (which I personally agree very strongly with), and cast those who
have rigid and unmovable dogma as being the other dirty C word. But even
those of us who think "Change" is good aren't running through the
streets trying to change every possible thing just because we can. And
with the responsibility to effect change comes the responsibility to
have a good plan to do so, that others believe in and can work with
without totally unheaving everything they are doing already. So
sometimes "Change" needs a bit longer to happen right.
4:15 a.m.
On Thu, Jul 22, 2010 at 09:55, Jon Masters <jonathan(a)jonmasters.org> wrote:
>
> This should probably say "systemd for F16"
+1 FWIW. I'm not a huge sysv fanboi either, but I do care about the
experience of sysadmins and the upstream for other projects, and I would
like to see some soak time for this before everyone needs to switch.
If previous experience shows us anything this will probably work this way:
- F14 will ship will systemd, there will be lots of problems with it
and everyone will be annoyed
- F15 will be slightly better, but people still having problems with
it are still annoyed
- F16 has most of it working again as in F13, but the stuff it does
better than SysV will be a lot better
- then TheOther distribution will start to use it and so everyone who
jumped ship at F14 will have to use it too
- ten years later the cycle starts again
By now I know that it is silly fighting it, there is no way to stop it.
Because I am used to the Red Hat before Fedora I would prefer a slower
pace and the possibility to use the same Linux skills on all
distributions. I also would like more technologies compete for the
SysV spot, but if competition is going to happen it has to come from
somewhere else outside of Fedora.
And if we are not happy with the changes, the only way to vote is with
our feet. For me systemd is not a good reason though, there have been
worse changes and I am still here.
Christof
9:21 a.m.
On Thu, 22.07.10 03:55, Jon Masters (jonathan(a)jonmasters.org) wrote:
> I was pretty clear in everything you cut off about the whole
"You know
> what people need, they need this" and the whole developers making things
> for sysadmins because they think sysadmins need it thing. 0pointer.de is
> Lennart's post. If this is only being developed and driven by the same
> people perhaps we should just step back, get it functioning for a while,
> _then_ lets talk about replacements. If you guys feel that strongly about
> it, you'll still feel that way a year from now when the whole system is
> developed and working right? Perhaps then it can go into Fedora?
>
> This should probably say "systemd for F16"
+1 FWIW. I'm not a huge sysv fanboi either, but I do care about the
experience of sysadmins and the upstream for other projects, and I would
like to see some soak time for this before everyone needs to switch. I
can otherwise just imagine the amount of documentation out there -
books, online resources, etc. that will all be out of date for Fedora
(and perhaps other projects later) but not for other distributions.
If everybody waits for the others to take the first step then we'll be
standing at the same place forever.
While Fedora is different things to different people, I thought one
thing was agreed: that we like to be the ones who innovate, not the ones
who just follow.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:46 p.m.
Mike McGrath <mmcgrath(a)redhat.com> wrote:
On Wed, 21 Jul 2010, Colin Walters wrote:
> On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
> > I think the bigger question is why are we doing this?
>
> There's some motivation here:
> http://0pointer.de/blog/projects/systemd.html
I was pretty clear in everything you cut off about the whole
"You know
what people need, they need this" and the whole developers making things
for sysadmins because they think sysadmins need it thing.
Perhaps not sysadmins per se (managing big boxes, mostly with strange,
varying requirements depending on the exact set of services offered), but
users on foot (handling startup, services, ... "invisibly" is a big bonus
for personal machines). Sure, sysadmins get help by having users pester
less too ;-)
0pointer.de
is
Lennart's post. If this is only being developed and driven by the same
people perhaps we should just step back, get it functioning for a while,
_then_ lets talk about replacements. If you guys feel that strongly about
it, you'll still feel that way a year from now when the whole system is
developed and working right? Perhaps then it can go into Fedora?
Nope. I still remember the pain in going from SunOS (BSD-style init, one
big rc file) to Solaris (SysV style). Much gnashing of teeth, calling Sun
ugly names, and trying to shoehorn everything into rc.local or some
such. It took a while, afterwards I didn't want to look back. It's called
"education", and it doesn't come cheap.
This should probably say "systemd for F16"
To me Fedora is about trying out new stuff, so I'm in favor of giving it a
shot in F14.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
9:11 p.m.
On Wed, 21.07.10 19:39, Mike McGrath (mmcgrath(a)redhat.com) wrote:
> BTW, you are emphasizing that that there was no reason for the
stfuf we
> do. But you are wrong. There actually is. The reason why we came up with
> systemd-install as a counterpart of chkconfig instead of patching
> chkconfig is that it actually works very very differently from
> it. i.e. beyond the fact that both create symlinks, one in
> /etc/systemd/system, the other in /etc/rcN.d/ they have very little in
> common. One cares about priorities, the other doesn't. One knows only 6
> runelvels, the other knows arbitrary numbers of targets. One can hook
> stuff into runlevels and runlevels only; the other can hook stuff into
> any unit. One can actually make the changes effetive immediately, the
> other doesn't do that; one can handle sockets and mounts and other kind
> of units, the other cannot; and so on and so on.
>
I think the bigger question is why are we doing this? It really does
sound like some developers got together and said "You know what people
need? This thing. They need this thing!"
Well, for starters, we actually did our homework. And you can do it too!
It's actually easy, for example, with this amazing thing called
"Google". You can use it to find resources on the Internet! For example
opinions on launchd and Solaris SMF. And you'll then notice that for the
most part people love it, for various reasons.
And now, systemd takes the best ideas out of launchd and SMF (and a few
other things) and then adds a bunch on top, using the best of what Linux
provides.
You are suggesting that this comes out of thin air, but well it
doesn't. "Some developers" actually looked around, managed to use google
and asked around, discussing this for at least the last 2y with various
people and then thought they could create a compelling result of all of
this. And that's systemd.
But of course, if you say the internet is full of lies, and we, the
developers are morons, and Apple users and Solaris folks idiots anyway,
then you are welcome to say that systemd is a project without a
reason.
Also, if you develop exclusively to fullfil exactly what people asked
fro then you produce pretty mediocre software. Of course it is good to
listen, but in the end you as the developer know what's technically
possible and have to give things the final touch that makes it great,
even though the potential users couldn't see that right away. The
developer tends to know his area very well, or at least he should. And
maybe that makes him a good candidate to actually come up with the best
design possible? I mean, if you don't that, can you have any
self-respect as a developer?
Or to put this differently: launchd is in fact one great invention. It
is a design an engineer up with, not a user/admin. And there's a reason
for that. That's not to say the user/admin is dumb or anything, but the
technical possibilities are known to the developer best and that's why
they came up with this great design.
Who has been requesting this? What requirements did they give? The
problem people seem to be having is the reasons you give in the above
paragraph are reasons you yourself invented, and that's a backwards way to
do development :-/
Jeez. Sometimes before complaining that other people didn't do their
homework maybe you should do your own. Google isn't that hard to
use. Reading up on Wikipedia either.
As mentioned above, it seems like you're trying to find a middle
ground
between where we are today, and this whole other place you guys invented
for seemingly no reason then you felt like coding something.
Maybe it seems like that to you, but most likely this is because you
never looked beyond sysvinit, and refused to even consider launchd or
SMF in any way. Those systems have issues, absolutely, everything has,
but they also have some really amazing features and parts of their
design are simply awesome. And so far we Linux folks had *nothing* that
came even close to either. And yes, with systemd we now have.
"Any fool can make things bigger, more complex, and more
violent. It takes
a touch of genius - and a lot of courage - to move in the opposite
direction." - Einstein.
I'm not calling you a fool, you're clearly not but that quote seems
appropriate. Just be extra careful when it's others (sysadmins) that have
to live with the consequences of your (developer) decisions.
Well, if you don't want to call me a fool, then why did you put a quote
here that basically calls me one?
Quite frankly, I find your mail insulting and remarkably
uninformed.
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:40 p.m.
Lennart Poettering píše v Čt 22. 07. 2010 v 04:11 +0200:
Or to put this differently: launchd is in fact one great invention.
It
is a design an engineer up with, not a user/admin. And there's a reason
for that. That's not to say the user/admin is dumb or anything, but the
technical possibilities are known to the developer best and that's why
they came up with this great design.
You know, if you let a good engineer design a
car, you get a Formula 1.
It looks cool, it has great features and great performance.
And only a few people in the world would actually want to use one, when
given the option.
A Formula 1 is not allowed on regular roads, people don't want to spend
so much time learning a different and unforgiving driving mechanism, and
they definitely don't want to seat their family and kids in one.
systemd is currently a racing car. The people who are asking you for a
minivan are not stupid, or out to get you; they have better things to do
with their time than to adapt their entire life to owning a racing car.
Yes, they'd like to have a better minivan, but given their life, they
need a _minivan_. If you keep trying to sell them a racing car, they'll
eventually just let you play with your racing car and go elsewhere.
The racing car technology needs to be transferred to the minivan
concept; if it means leaving some cool technology unused, so be it.
Mirek
4:12 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 21.07.10 19:39, Mike McGrath (mmcgrath(a)redhat.com) wrote:
[...]
> Who has been requesting this? What requirements did they give?
The
> problem people seem to be having is the reasons you give in the above
> paragraph are reasons you yourself invented, and that's a backwards way to
> do development :-/
Jeez. Sometimes before complaining that other people didn't do
their
homework maybe you should do your own. Google isn't that hard to
use. Reading up on Wikipedia either.
Please show us. A farm of URLs is fine with me.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
7:37 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
So, please, when Jef finishes his work, or I find the time to, we
will
provide chkconfig compat too (at least to a certain degree). However,
doing this is actually just the cherry on top of the topping of our
delicous cake. But even without the cherry it still would be very yummy
and still have topping.
The cake is a lie! :-)
Yes, I guess being a developer who develops new stuff I like
innovation
in interfaces more than administrators who then might end up using
this.
See, that's a problem. You are designing a tool to be used by admins,
but you blow off what admins like.
Also, one last thing: there's so much in systemd that admins
should
really love. It would be great to sometimes look on the bright side of
things. One small and random example, just to make a point: Look how
awesome the output of "systemctl status avahi-daemon.service" is:
Okay, there's some interesting stuff there I guess. It isn't something
I'll need on a regular basis. Including a process tree isn't always a
good idea (think sendmail and dovecot on busy mail servers; hundreds of
lines of output). When I want to see a process tree, there are already
tools to do that (I prefer the traditional Unix philosophy to make
things do one job and do it well, or just run perl for everything).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:03 a.m.
2010/7/21 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
Admins will need to know that they have to use chkconfig for services
that
do not have a native systemd $service file. ( legacy for services )
And as the general rule goes "native configuration breaks legacy
configuration" so if a native systemd $service file does exist than changing
service via chkconfig no longer will work.
Would it be reasonable to extend chkconfig so that it can know which
services it can no longer control and provide a pointer blurb to
admins when they try to use chkconfig with those services in the F14
timeframe. The reality is any change to scriptable behaviour is a
pitchfork wielding mob scenario. (mental note: this would make a good
Simpson's episode)
If we are breaking curmudgeony workflows it be really nice to provide
some breadcrumbs along the way to help us old dogs learn new tricks.
Admins are going to need to learn how to use and configure systemd
native configs in the F14 timeframe, feedback from the "legacy" system
tools when we need to recondition our muscle memory and are scripted
actions would go a long way to lowering the frustration level...if the
native/legacy tool break can't be avoided.
-jef
noon
On Wed, 2010-07-21 at 08:03 -0800, Jeff Spaleta wrote:
2010/7/21 "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com>:
> Admins will need to know that they have to use chkconfig for services that
> do not have a native systemd $service file. ( legacy for services )
>
> And as the general rule goes "native configuration breaks legacy
> configuration" so if a native systemd $service file does exist than changing
> service via chkconfig no longer will work.
Would it be reasonable to extend chkconfig so that it can know which
services it can no longer control and provide a pointer blurb to
admins when they try to use chkconfig with those services in the F14
timeframe. The reality is any change to scriptable behaviour is a
pitchfork wielding mob scenario. (mental note: this would make a good
Simpson's episode)
If we are breaking curmudgeony workflows it be really nice to provide
some breadcrumbs along the way to help us old dogs learn new tricks.
Admins are going to need to learn how to use and configure systemd
native configs in the F14 timeframe, feedback from the "legacy" system
tools when we need to recondition our muscle memory and are scripted
actions would go a long way to lowering the frustration level...if the
native/legacy tool break can't be avoided.
It occurs to me that chkconfig isn't, in packaging terms, part of either
upstart or systemd. It's just a standalone utility, it builds from its
own SRPM.
systemd being an open source project, its interfaces shouldn't be hard
to figure out, and hey, I seem to recall seeing quite a bit of
documentation, and Lennart seems perfectly happy to provide info when
asked.
So...why can't any of those complaining about this just go ahead and
patch chkconfig to support systemd? It's not like Lennart can stop you,
no matter how much he twirls his moustache ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:45 p.m.
On Wed, 21.07.10 10:00, Adam Williamson (awilliam(a)redhat.com) wrote:
> If we are breaking curmudgeony workflows it be really nice to
provide
> some breadcrumbs along the way to help us old dogs learn new tricks.
> Admins are going to need to learn how to use and configure systemd
> native configs in the F14 timeframe, feedback from the "legacy" system
> tools when we need to recondition our muscle memory and are scripted
> actions would go a long way to lowering the frustration level...if the
> native/legacy tool break can't be avoided.
It occurs to me that chkconfig isn't, in packaging terms, part of either
upstart or systemd. It's just a standalone utility, it builds from its
own SRPM.
systemd being an open source project, its interfaces shouldn't be hard
to figure out, and hey, I seem to recall seeing quite a bit of
documentation, and Lennart seems perfectly happy to provide info when
asked.
So...why can't any of those complaining about this just go ahead and
patch chkconfig to support systemd? It's not like Lennart can stop you,
no matter how much he twirls his moustache ;)
I have no moustache. ;-) But otherwise you are right.
Let me say here that the scripts in /etc/init.d resp. everything run via
/sbin/service already will have the necessary glue code in there as soon
as Bill merges https://bugzilla.redhat.com/show_bug.cgi?id=612728 . It
will forward start/stop requests to systemctl. That means people can
continue to use "/etc/init.d/foo start" and "/sbin/service foo start",
and
the right thing will happen and they'll learn something too.
We can add similar code to chkconfig too: something that warns the admin
when a native systemd unit file exists, and then redirects the command
properly. It is now on my todo list, but not even near the top of the
list.
I would greatly appreciate if somebody would work on this, because I am
currently pushing this through single-handedly everywhere else now. In
fact I'd appreciate help in all areas. For example, if somebody would
pick up the /var/run resp. /var/lock on tmpfs issue I'd be a happy
man. Or if somebody would help me and post the unit files from
http://0pointer.de/public/systemd-units/ on bugzilla, then I'd be even
happier.
Of course, if the other folks on this list think that bike-shedding and
nitpicking is time better spent then actually doing things and helping
with the integration, then they are welcome to continue wasting my time
by wanting to discuss the names of the binaries we use. Jeez.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:51 p.m.
On Wed, Jul 21, 2010 at 9:45 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
We can add similar code to chkconfig too: something that warns the
admin
when a native systemd unit file exists, and then redirects the command
properly. It is now on my todo list, but not even near the top of the
list.
Is there a reasonable deadline to shoot for? Let me get past this
weekend and I'll try to commit to doing so that I can be publicly
shamed if I fail at doing it.
Is there a todo list published that can be scanned by other interested
parties for low hanging fruit?
-jef
1:46 p.m.
On Wed, 21.07.10 09:51, Jeff Spaleta (jspaleta(a)gmail.com) wrote:
Heya,
Is there a reasonable deadline to shoot for? Let me get past this
weekend and I'll try to commit to doing so that I can be publicly
shamed if I fail at doing it.
Thanks a lot for looking into this. Much appreciated!
Next week's is the feature freeze IIRC and also GUADEC. Which means I am
not really going to be around. Which is why I want the systemd switch
completed by the end of the week. I have prepped a patch with makes
upstart parallel installable with systemd, so that people can rescue
their systems with init=/sbin/upstart on the kernel command line, should
systemd break it. This should give as a smoother transition. Casey
OK'eyed that patch basically, but we were hoping for a second OK from
Bill, but he is on vacation, so i guess we'll have to do without it. Due
to that my plan is to release v4 tonight and upload Upstart and systemd
in a way that systemd is default and upstart can be installed as
alternative.
For the chkconfig stuff the deadline is not as crucial I think. I think
people running rawhide can deal with an "imperfect" chkconfig for
now. Of course, this change should be completed before we release F14,
and before admins get their fingers on this.
Is there a todo list published that can be scanned by other
interested
parties for low hanging fruit?
Kinda. I maintain this list in git:
http://cgit.freedesktop.org/systemd/tree/fixme
However, it is a mishmash of english and a bit of german and you
probably need a bit of context to figure out what I mean by the items
listed. That list is primarily for myself, but it might be interesting
for other folks too which is why I commit it to git.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:03 p.m.
On 07/21/2010 04:03 PM, Jeff Spaleta wrote:
Would it be reasonable to extend chkconfig so that it can know which
services it can no longer control and provide a pointer blurb to
admins when they try to use chkconfig with those services in the F14
timeframe. The reality is any change to scriptable behaviour is a
pitchfork wielding mob scenario. (mental note: this would make a good
Simpson's episode)
If we are breaking curmudgeony workflows it be really nice to provide
some breadcrumbs along the way to help us old dogs learn new tricks.
Admins are going to need to learn how to use and configure systemd
native configs in the F14 timeframe, feedback from the "legacy" system
tools when we need to recondition our muscle memory and are scripted
actions would go a long way to lowering the frustration level...if the
native/legacy tool break can't be avoided.
FYI. There is work being done to allow as smooth transaction as possible.
Lennart has added to his todo list to look at letting systemd-install
fallback to chkconfig if no native systemd service file is found which
will smooth the transaction from the legacy chkconfig to systemd-install
enable/disable $foo.service.
There is an RFE for the same compatibility from chkconfig #616857 as in
chkconfig will try to use systemd native files first and spill out a
deprecation warning or just spill out deprecation warning hinting users
( Written in C patches welcome ) and #612728 is dealing with users that
directly run /etc/init.d/foo along the way cleaning some other stuff
which should have been done eons ago and I suspect /sbin/service will be
fixed at the same time.
< rant at those nei sayers >
I must say it's interesting to see how the community holds so dear to
the code that was forge by putting holes in paper and have absolutely no
problem screaming at baby when it's barely out of it's birth canal. . .
Regular desktop end user wont notice any other change other than perhaps
faster bootup and the people that call themselves "power/advanced/admin"
users should have no problem to adapt and are urged from the start to
use systemd-install and systemctl however if there is nothing but air in
that power and the only thing they are capable of administrating are
themselves with the only advancement they show is getting closer to the
door on their way out, there is a point and click operating system
waiting for them around the corner which they can play
power/advanced/admin crossword pussle by checking random boxes to make
things work for them or they can choose to stay on F13 until it EOL then
switch to F15 which hopefully all upstream has provided native systemd
service files for their daemon and most if any cruff has been sorted out.
For god sakes people alpha aint even out the door yet!
</rant at those nei sayers >
JBG
12:30 p.m.
2010/7/21 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
There is an RFE for the same compatibility from chkconfig #616857 as
in
chkconfig will try to use systemd native files first and spill out a
deprecation warning or just spill out deprecation warning hinting users (
Written in C patches welcome ) and #612728 is dealing with users that
directly run /etc/init.d/foo along the way cleaning some other stuff which
should have been done eons ago and I suspect /sbin/service will be fixed at
the same time.
Cool. I'll keep those in mind.
< rant at those nei sayers >
I must say it's interesting to see how the community holds so dear to the
code that was forge by putting holes in paper and have absolutely no problem
screaming at baby when it's barely out of it's birth canal. . .
Community is an interesting word. And I don't think it applies here.
Sysadmins are a breed apart quite frankly because other people expect
them to be. And if you don't realize that sysadmins as a subspecies
of the larger human experience are going to be grump-tastic about any
changes...you don't know enough sysadmins and you aren't going to make
many of them your friend. Is it rational? Nope..but it is what it is.
Know your audience. There's a difference between looking forward to
adapting to change and the inherent ability to adapt to change.. the
two personality traits don't necessarily go together. I'm here to tell
you that sysadmins don't historically, as the only unchallengeable
monolithic human cultural stereotype, enjoy adapting..especially when
they are told to suck it up and just deal with it...which is basically
what they are told on a daily basis. Being good at adapting can wear
you down when people grow an expectation that you are
uncharacteristically good at doing it... just saying.
I'm not part of the zero regression fanclub. But I'd like to help do
what is reasonable to minimize the frustration of introducing a new
way of doing things. The deprecation warnings are reasonable to me. We
aren't going to reduce that frustration to zero of course. But we sure
as hell aren't going to blunt the unavoidable pitchforks by telling
sysadmin to just suck it up. I'd like to find a way to sell them on
short term pain for long term gain from the sysadmin point of view.
-jef"I'd tell you to go out and hug a sysadmin but that probably just
get you punched"spaleta
2:26 p.m.
ons 2010-07-21 klockan 09:30 -0800 skrev Jeff Spaleta:
I'm not part of the zero regression fanclub. But I'd like to
help do
what is reasonable to minimize the frustration of introducing a new
way of doing things. The deprecation warnings are reasonable to me. We
aren't going to reduce that frustration to zero of course. But we sure
as hell aren't going to blunt the unavoidable pitchforks by telling
sysadmin to just suck it up. I'd like to find a way to sell them on
short term pain for long term gain from the sysadmin point of view.
I'm a sysadmin and I welcome improvements in software even if it means I
have to change how I do things. I really do have bigger things to worry
about than some small change in some command line tool.
However, I agree with Chris Adams, make things backwards-compatible when
it's practical. Putting some wrapper code in chkconfig is exactly the
right thing to do. It should be simple (it doesn't have to be perfect,
it can ignore --level for example) and it would keep a lot of shell
script from breaking.
-jef"I'd tell you to go out and hug a sysadmin but that
probably just
get you punched"spaleta
"Beware of the sysadmin!" :D
/Alexander
1:45 p.m.
Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com> said:
Regular desktop end user wont notice any other change other than
perhaps
faster bootup and the people that call themselves "power/advanced/admin"
users should have no problem to adapt and are urged from the start to
Please remember that Fedora is not just about desktop end users, or even
users at all in some cases. There are years of scripts, documentation,
etc. that use chkconfig and service, and breaking them will be a PITA.
For god sakes people alpha aint even out the door yet!
Well, the last time I waited (or didn't notice) a big change until after
it was released, I got the "why didn't you say something while this was
in development" response.
I just want to see changes in a backwards-compatible way whenever it is
practical. I understand that that is not always the case, but I don't
see anything here that indicates systemd and the long-standing
chkconfig/service interfaces can't continue to work. IMHO the onus is
on the systemd developers to make it backwards compatible where
practical, as they are the group that (a) are advocating a major change
and (b) know how systemd (and presumably the current init system) works.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
2:23 p.m.
On Wed, Jul 21, 2010 at 10:45 AM, Chris Adams <cmadams(a)hiwaay.net> wrote:
I just want to see changes in a backwards-compatible way whenever it
is
practical. I understand that that is not always the case, but I don't
see anything here that indicates systemd and the long-standing
chkconfig/service interfaces can't continue to work. IMHO the onus is
on the systemd developers to make it backwards compatible where
practical, as they are the group that (a) are advocating a major change
and (b) know how systemd (and presumably the current init system) works.
The onus is on _us_ as participants to get changes well integrated in
a timely manner. There's never been a mandate..nor will their every
be a mandate for a Fedora feature to be 100% backwards compatible
across releases as a showstopper for inclusion. To suggest otherwise
is pure hyperbole.
Systemd is going into rawhide early enough for those of us who care
about script oriented backwards compatibility to sand down of the
edges we care about regardless of the priorities of the main
developer(s). As long as we are not bumping up against fundamental
differences in opinion and they give us the freedom of action to make
backwards compatibility with legacy tools possible.
I think we are having this discussion early enough. But we need to
figure out what those items that are high priority to us (but low in
the upstream todo list) are and knock them out in parallel.
-jef
12:12 p.m.
On Wed, Jul 21, 2010 at 12:04:39PM +0000, "Jóhann B. Guðmundsson" wrote:
ls /lib/systemd/system/
To enable service ( chkconfig $service on )
systemd-install enable $service.service
To disable service ( chkconfig $service off )
systemd-install disable $service.service
I don't care what specific name you chose, but "systemd-install" is not a
very administrator-friendly choice. In what way is disabling a service
installing systemd?
Having admin-friendly names (like "service foo start") is important for
mindshare.
Annd, actually, maybe extending the service script to understand about
systemd is the way to go here.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:27 p.m.
On Wed, 21.07.10 13:12, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Wed, Jul 21, 2010 at 12:04:39PM +0000, "Jóhann B. Guðmundsson" wrote:
> ls /lib/systemd/system/
> To enable service ( chkconfig $service on )
> systemd-install enable $service.service
> To disable service ( chkconfig $service off )
> systemd-install disable $service.service
I don't care what specific name you chose, but "systemd-install" is not a
very administrator-friendly choice. In what way is disabling a service
installing systemd?
It's called systemd-install, not install-systemd. "systemd-" is the
common prefix for many of the systemd tools (though not all). How very
discoverable.
I am pretty sure there'll be folks who finds issues with every name we
pick. I am not going to play the game of making everybody happy. Sorry.
And in this case, where it's clearly a matter of taste and bike-shedding
I probably shouldn't even have bothered to even reply to this mail of
yours.
Having admin-friendly names (like "service foo start") is
important for
mindshare.
Well, I believe these ones are admin friendly. But well, If people
disagree then I guess we have to agree to disagree on this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:55 p.m.
On Wed, Jul 21, 2010 at 07:27:52PM +0200, Lennart Poettering wrote:
It's called systemd-install, not install-systemd.
"systemd-" is the
common prefix for many of the systemd tools (though not all). How very
discoverable.
However, only some of those actions are "install". So that's confusing and
non-discoverable. It's also way too long, and if all of the systemd tools
start with "systemd", it's a pain for tab completion. Not a problem in
scripts, but a hassle for administration.
And in this case, where it's clearly a matter of taste and
bike-shedding
Like I said, I don't particularly care _what_ color it is -- although I have
a strong preference for leaving it how it was. (chkconfig and service -- or
if one tool can condense the functionality, fine).
I probably shouldn't even have bothered to even reply to this
mail of
yours.
Well, it's nice that you deign to participate.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
6:15 p.m.
On Wed, Jul 21, 2010 at 06:55:41PM -0400, Matthew Miller wrote:
> And in this case, where it's clearly a matter of taste and
bike-shedding
[...]
> I probably shouldn't even have bothered to even reply to
this mail of
> yours.
Well, it's nice that you deign to participate.
Sorry for returning the snippy attitude. However, user-interface design is
important, even when that user interface is the command-line. And it's
arrongant and obnoxious to dismiss out-of-hand feedback from your end-user
community as "bike-shedding".
There are legitmate concerns here, and if Fedora as a whole doesn't care
about them, that sucks for Fedora.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:20 p.m.
On Wed, Jul 21, 2010 at 07:15:29PM -0400, Matthew Miller wrote:
There are legitmate concerns here, and if Fedora as a whole
doesn't care
about them, that sucks for Fedora.
It has been brought to my intention that this statement is unfairly sweeping
and broad. Which is encouraging, really, so let me rephrase:
There are legitmate concerns here, and if Fedora as a whole *didn't* care
about them, that *would* suck for Fedora.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:13 a.m.
On Tue, 20.07.10 20:24, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
On Wed, Jul 14, 2010 at 2:50 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote:
>
>> Perhaps someone could put together a wiki page for lazy sysadmins with
>> a Q&A? ie, I used to do this in upstart/sysvinit, how do I do it with
>> systemd?
>
> Jóhann Guðmundsson (viking_ice) has been working on something along
> these lines:
>
> http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd
>
> it was mentioned in the QA meeting a few weeks back.
I have a few requests for things to add to that page :-)
* What replaces chkconfig
* What replaces /etc/init.d/SERVICENAME start | stop ?
Similarly, for packaging guidelines updates, how do we install
packages that provide services and have them not start up?
The longer answers for most of these questions you find in Jóhann's
reply. But a few additional notes:
- If you only install a SysV init script, then continue to use chkconfig
as usual. It works as intended to enable/disable SysV init
scripts. Only if you use native systemd unit files you should use
systemd-install instead. Note that most operations systemd-install
executes are very easy however, as all it does is creating/removing a
few suggested symlinks which are listed in a [Install] section in
the unit file. It is OK and even expected to manually create
additional symlinks, or remove symlinks, as the administrator likes.
- Regardless whether systemd or SysV init scripts/unit files are used,
"systemctl start" and "systemctl stop" are the recommended
replacements for "service foo start" and "service foo stop".
Howver,
as soon as https://bugzilla.redhat.com/show_bug.cgi?id=612728 is fixed
you can use the old syntax for SysV scripts too in which case the
right thing happens, but you'll get a blurb printed that suggests you
to use "systemctl" instead, the next time.
- If you want to enable and possibly start a service from the %post of
an RPM then use the "systemd-install enable" command, which will
create a few symlinks as listed in the [Install] section of the unit
file. On top of that you may also pass --realize=... to the command,
which allows you to not only enable the unit for the next boot, but
also have the changes take effect immediately: i.e. --realize=reload
is the very least you should use, which simply makes systemd aware of
the changed symlinks. Then, at time of %preun you should use
--realize=yes which makes sure the daemon is stopped in
deinstallation. For a few daemons it makes sense to restart them if
they are running already during upgrade. Use --realize=minimal for
those. For even others (usually very low-level ones) it might even
make sense to start them right-away after installation, even if they
were not running before. For those use --realize=maybe. But which
option you use really depends on the package. Most packages
should probably stick to --realize=yes on %preun and --realize=reload
in %post. Suggested .spec file fragments you find in the daemon(7) man
page.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:08 p.m.
On Wed, Jul 21, 2010 at 03:13:12PM +0200, Lennart Poettering wrote:
On Tue, 20.07.10 20:24, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> On Wed, Jul 14, 2010 at 2:50 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote:
> >
> >> Perhaps someone could put together a wiki page for lazy sysadmins with
> >> a Q&A? ie, I used to do this in upstart/sysvinit, how do I do it with
> >> systemd?
> >
> > Jóhann Guðmundsson (viking_ice) has been working on something along
> > these lines:
> >
> > http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd
> >
> > it was mentioned in the QA meeting a few weeks back.
>
> I have a few requests for things to add to that page :-)
>
> * What replaces chkconfig
> * What replaces /etc/init.d/SERVICENAME start | stop ?
>
> Similarly, for packaging guidelines updates, how do we install
> packages that provide services and have them not start up?
The longer answers for most of these questions you find in Jóhann's
reply. But a few additional notes:
- If you only install a SysV init script, then continue to use chkconfig
as usual. It works as intended to enable/disable SysV init
scripts. Only if you use native systemd unit files you should use
systemd-install instead. Note that most operations systemd-install
executes are very easy however, as all it does is creating/removing a
few suggested symlinks which are listed in a [Install] section in
the unit file. It is OK and even expected to manually create
additional symlinks, or remove symlinks, as the administrator likes.
- Regardless whether systemd or SysV init scripts/unit files are used,
"systemctl start" and "systemctl stop" are the recommended
replacements for "service foo start" and "service foo stop".
Howver,
as soon as https://bugzilla.redhat.com/show_bug.cgi?id=612728 is fixed
you can use the old syntax for SysV scripts too in which case the
right thing happens, but you'll get a blurb printed that suggests you
to use "systemctl" instead, the next time.
- If you want to enable and possibly start a service from the %post of
an RPM then use the "systemd-install enable" command, which will
create a few symlinks as listed in the [Install] section of the unit
file. On top of that you may also pass --realize=... to the command,
which allows you to not only enable the unit for the next boot, but
also have the changes take effect immediately: i.e. --realize=reload
is the very least you should use, which simply makes systemd aware of
the changed symlinks. Then, at time of %preun you should use
--realize=yes which makes sure the daemon is stopped in
deinstallation. For a few daemons it makes sense to restart them if
they are running already during upgrade. Use --realize=minimal for
those. For even others (usually very low-level ones) it might even
make sense to start them right-away after installation, even if they
were not running before. For those use --realize=maybe. But which
option you use really depends on the package. Most packages
should probably stick to --realize=yes on %preun and --realize=reload
in %post. Suggested .spec file fragments you find in the daemon(7) man
page.
Normally, we don't want a service to be started just because the package has
been installed:
https://fedoraproject.org/wiki/Packaging/SysVInitScript.
This is the current recommended scriptlets:
%post
# This adds the proper /etc/rc*.d links for the script
/sbin/chkconfig --add <script>
%preun
if [ $1 = 0 ] ; then
/sbin/service <script> stop >/dev/null 2>&1
/sbin/chkconfig --del <script>
fi
%postun
if [ "$1" -ge "1" ] ; then
/sbin/service <script> condrestart >/dev/null 2>&1 || :
fi
I think I've got the %preun translated correctly but I'm not sure about
either the %post or %postun::
%post
# Don't need a %post as systemd automatically knows about the defaults?
%preun
if [ $1 = 0 ] ; then
/usr/bin/systemd-install disable %{unit name}.service --realize=disable > /dev/null
2>&1 || :
fi
%postun
if [ "$1" -ge "1" ] ; then
# Can't figure out how to do a conditional restart here. Help?
fi
-Toshio
8:30 p.m.
On Wed, 21.07.10 20:08, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> - If you want to enable and possibly start a service from the
%post of
> an RPM then use the "systemd-install enable" command, which will
> create a few symlinks as listed in the [Install] section of the unit
> file. On top of that you may also pass --realize=... to the command,
> which allows you to not only enable the unit for the next boot, but
> also have the changes take effect immediately: i.e. --realize=reload
> is the very least you should use, which simply makes systemd aware of
> the changed symlinks. Then, at time of %preun you should use
> --realize=yes which makes sure the daemon is stopped in
> deinstallation. For a few daemons it makes sense to restart them if
> they are running already during upgrade. Use --realize=minimal for
> those. For even others (usually very low-level ones) it might even
> make sense to start them right-away after installation, even if they
> were not running before. For those use --realize=maybe. But which
> option you use really depends on the package. Most packages
> should probably stick to --realize=yes on %preun and --realize=reload
> in %post. Suggested .spec file fragments you find in the daemon(7) man
> page.
>
Normally, we don't want a service to be started just because the package has
been installed:
Yepp, which is why I said "very low-level ones", i.e. as low-level as
for example udev, which you really want to be running.
https://fedoraproject.org/wiki/Packaging/SysVInitScript.
This is the current recommended scriptlets:
%post
# This adds the proper /etc/rc*.d links for the script
/sbin/chkconfig --add <script>
%preun
if [ $1 = 0 ] ; then
/sbin/service <script> stop >/dev/null 2>&1
/sbin/chkconfig --del <script>
fi
%postun
if [ "$1" -ge "1" ] ; then
/sbin/service <script> condrestart >/dev/null 2>&1 || :
fi
I think I've got the %preun translated correctly but I'm not sure about
either the %post or %postun::
%post
# Don't need a %post as systemd automatically knows about the defaults?
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places via symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
else
# For old installations, just reload the configuration, don't change symlinks
/bin/bin/systemd-install realize --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
fi
%preun
if [ $1 = 0 ] ; then
/usr/bin/systemd-install disable %{unit name}.service --realize=disable >
/dev/null 2>&1 || :
fi
Almost:
if [ $1 -eq 0 ] ; then
/usr/bin/systemd-install disable --realize=yes %{unit name}.service > /dev/null
2>&1 || :
fi
%postun
if [ "$1" -ge "1" ] ; then
# Can't figure out how to do a conditional restart here. Help?
fi
If you want to restart the service on upgrade I'd do that in %post. It
should be sufficient to replace --realize=reload by --realize=minimal
which will restart the unit if it is running, and only then.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:55 p.m.
On Wed, Jul 21, 2010 at 19:30, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 21.07.10 20:08, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places via symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
else
# For old installations, just reload the configuration, don't change symlinks
/bin/bin/systemd-install realize --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
fi
Ok from dealing with many years of technical support it has been
hammered into me that if you are replacing a command, make sure the
replacement makes more sense than the thing it 'replaces' (in this
case chkconfig which people seem to intuit means check configuration).
Putting my head into a customers head the first thing before the
complicated syntax is "why am I running something called install to
change a service?"
I will forego the bikeshedding and say it should be sysconfig or
syssetup but I do believe it will cause a lot of complaints.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
11:11 p.m.
On Wed, Jul 21, 2010 at 5:55 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
I will forego the bikeshedding and say it should be sysconfig or
syssetup but I do believe it will cause a lot of complaints.
sys-armyknife
system-get-me-a-beer
More seriously systemctl has been bantered around on this list
already and naively I would have thought it would encompass some of
the functionality being talked about that systemd-install does.
I have concerns about the split in functionality and the cohesiveness
of command naming scheming, but I don't think we are going to find an
optimal solution. I certainly don't know enough about all the
functionality to make any concrete suggestions. Though I would like to
see someone who does know more than me think set up some strawman use
cases that represent common usage scenarios and try to think through
the functionality split in a way that minimizes the number of
different commands needed for the common case. That'd probably help
all of us get a feel for the normal level of complexity here.
I think part of the subconscious red flags that are going off is an
inherent trend towards flexibility==complexity. I think everyone sees
there's enhanced flexibility here. The question is can we dice it up
in such a way that it doesn't show up as unnecessary complexity. A
packager workflow case would be interesting to see. A local sysadmin
usage scenario would be interesting to see talked through.
I think whatever we see shipped is going to end up being re-adjusted
after some real world usage. Obviously providing service and
chkconfig tools which provide a subset of available functionality at
the cost of not being able to get access to the extra flexibility is
one part of the equation..sort of a comfort zone fallback. But as
more people use and get confused by the new command structure, there
will undoubtly be some areas where functionality could be
repartitioned or expressed in a different manner.
-jef
9:06 p.m.
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places via symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
else
# For old installations, just reload the configuration, don't change
symlinks
/bin/bin/systemd-install realize --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
fi
Wow thats pretty special... both an option called realize and a
argument, that won't get confusing no matter how long it lives, also
realize doesn't seem to be conveying a useful meaning, I'm a native
speaker and I'm not sure what you actually mean by realize in this
context.
I'm going with:
to make real; give reality to (a hope, fear, plan, etc.).
but its seems quite an abstract term to associate reality with an
abstract computer object.
Dave.
9:25 p.m.
On Thu, 22.07.10 12:06, Dave Airlie (airlied(a)redhat.com) wrote:
>
> It is needed:
>
> if [ $1 -eq 1 ] ; then
> # For new installations, hook unit file into the appropriate places via
symlinks
> /usr/bin/systemd-install enable --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
> else
> # For old installations, just reload the configuration, don't change
symlinks
> /bin/bin/systemd-install realize --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
> fi
Wow thats pretty special... both an option called realize and a
argument, that won't get confusing no matter how long it lives, also
realize doesn't seem to be conveying a useful meaning, I'm a native
speaker and I'm not sure what you actually mean by realize in this
context.
I'm going with:
to make real; give reality to (a hope, fear, plan, etc.).
but its seems quite an abstract term to associate reality with an
abstract computer object.
Well, I am not a native speaker. We were looking for a verb that
basically means "make this take effect immediately".
i.e. the "enable"/"disable" commands makes some changes for the next
time they are looked at, and then adding --realize on top makes those
changes take effect immediately, i.e. so that the unit is start/stopped
according to those changes. We actually used "--start=" first (which
however is very confusing when you'd write "disable --start" to disable
something and then have it stop...) We then considered "--now", because
it is not a verb. But eventually we stuck with --realize. It's not
great, yes. But we couldnt think of anything better. Happy to take
suggestions. But no, --take-effect-immediately is not really an option.
Also, in the excerpt above this would actually suffice:
/bin/bin/systemd-install realize %{unit name}.service > /dev/null 2>&1 || :
But then I couldn't have referred to the --realize=foo changing further
down in the mail, so I added that. Maybe I shouldn't have done that for
simplicity's sake.
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:36 p.m.
On Thu, 2010-07-22 at 04:25 +0200, Lennart Poettering wrote:
On Thu, 22.07.10 12:06, Dave Airlie (airlied(a)redhat.com) wrote:
>
>
> >
> > It is needed:
> >
> > if [ $1 -eq 1 ] ; then
> > # For new installations, hook unit file into the appropriate places via
symlinks
> > /usr/bin/systemd-install enable --realize=reload %{unit name}.service
> /dev/null 2>&1 || :
> > else
> > # For old installations, just reload the configuration, don't
change symlinks
> > /bin/bin/systemd-install realize --realize=reload %{unit name}.service
> /dev/null 2>&1 || :
> > fi
>
> Wow thats pretty special... both an option called realize and a
> argument, that won't get confusing no matter how long it lives, also
> realize doesn't seem to be conveying a useful meaning, I'm a native
> speaker and I'm not sure what you actually mean by realize in this
> context.
>
> I'm going with:
>
> to make real; give reality to (a hope, fear, plan, etc.).
>
> but its seems quite an abstract term to associate reality with an
> abstract computer object.
Well, I am not a native speaker. We were looking for a verb that
basically means "make this take effect immediately".
i.e. the "enable"/"disable" commands makes some changes for the next
time they are looked at, and then adding --realize on top makes those
changes take effect immediately, i.e. so that the unit is start/stopped
according to those changes. We actually used "--start=" first (which
however is very confusing when you'd write "disable --start" to disable
something and then have it stop...) We then considered "--now", because
it is not a verb. But eventually we stuck with --realize. It's not
great, yes. But we couldnt think of anything better. Happy to take
suggestions. But no, --take-effect-immediately is not really an option.
Why have two verbs in a command structure? isn't enable or disable the
order, --now seems like it would be correct, the thing with English is
its flexible about these sort of things.
Also you have --realize=reload and --realize=minimal, again
non-representative, minimal means reload if running, whereas reload
means start if not running otherwise reload? I would expect reload means
reload if running, otherwise do nothing, the other option would probably
be better specified as reload,start.
Dave.
10:29 p.m.
On Thu, Jul 22, 2010 at 12:36:34PM +1000, Dave Airlie wrote:
On Thu, 2010-07-22 at 04:25 +0200, Lennart Poettering wrote:
> i.e. the "enable"/"disable" commands makes some changes for the
next
> time they are looked at, and then adding --realize on top makes those
> changes take effect immediately, i.e. so that the unit is start/stopped
> according to those changes. We actually used "--start=" first (which
> however is very confusing when you'd write "disable --start" to
disable
> something and then have it stop...) We then considered "--now", because
> it is not a verb. But eventually we stuck with --realize. It's not
> great, yes. But we couldnt think of anything better. Happy to take
> suggestions. But no, --take-effect-immediately is not really an option.
Why have two verbs in a command structure? isn't enable or disable the
order, --now seems like it would be correct, the thing with English is
its flexible about these sort of things.
Also you have --realize=reload and --realize=minimal, again
non-representative, minimal means reload if running, whereas reload
means start if not running otherwise reload? I would expect reload means
reload if running, otherwise do nothing, the other option would probably
be better specified as reload,start.
I notice that the man page takes great pains to distinguish
enable/disable and start/stop (activate/deactivate). This makes sense --
the current commands separate into "chkconfig on/off" and "service
start/stop".
So why are the concepts being blurred here? There's already a systemctl
start/stop/... (as mentioned in the systemd-install description).
Maybe what you want is an --if-enabled option to systemctl
start/restart/...?
11:38 p.m.
On 07/21/2010 09:36 PM, Dave Airlie wrote:
> Well, I am not a native speaker. We were looking for a verb that
> > basically means "make this take effect immediately".
> >
> > i.e. the "enable"/"disable" commands makes some changes for
the next
> > time they are looked at, and then adding --realize on top makes those
> > changes take effect immediately, i.e. so that the unit is start/stopped
> > according to those changes. We actually used "--start=" first (which
> > however is very confusing when you'd write "disable --start" to
disable
> > something and then have it stop...) We then considered "--now",
because
> > it is not a verb. But eventually we stuck with --realize. It's not
> > great, yes. But we couldnt think of anything better. Happy to take
> > suggestions. But no, --take-effect-immediately is not really an option.
Why have two verbs in a command structure? isn't enable or disable the
order, --now seems like it would be correct, the thing with English is
its flexible about these sort of things.
I'm part of the native English group. For me, --now would be an almost
self explanatory option, and so easy to remember!
If --now is unacceptable, how about --immed.
-Jeff
4:37 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 12:06, Dave Airlie (airlied(a)redhat.com) wrote:
[...]
> Wow thats pretty special... both an option called realize and a
> argument, that won't get confusing no matter how long it lives, also
> realize doesn't seem to be conveying a useful meaning, I'm a native
> speaker and I'm not sure what you actually mean by realize in this
> context.
>
> I'm going with:
>
> to make real; give reality to (a hope, fear, plan, etc.).
>
> but its seems quite an abstract term to associate reality with an
> abstract computer object.
Well, I am not a native speaker. We were looking for a verb that
basically means "make this take effect immediately".
i.e. the "enable"/"disable" commands makes some changes for the next
time they are looked at, and then adding --realize on top makes those
changes take effect immediately, i.e. so that the unit is start/stopped
according to those changes. We actually used "--start=" first (which
however is very confusing when you'd write "disable --start" to disable
something and then have it stop...) We then considered "--now", because
it is not a verb.
What is wrong with that? "enable --now" and "disable --now" read right
(to
me at least).
But eventually we stuck with --realize. It's
not
great, yes. But we couldnt think of anything better. Happy to take
suggestions. But no, --take-effect-immediately is not really an option.
What do other commands use for "do it now" (instead of "later")?
Perhaps
the ubiquitous "-f/--force" will do?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
4:43 p.m.
On Thu, 2010-07-22 at 17:37 -0400, Horst H. von Brand wrote:
> however is very confusing when you'd write "disable
--start" to disable
> something and then have it stop...) We then considered "--now", because
> it is not a verb.
What is wrong with that? "enable --now" and "disable --now" read
right (to
me at least).
> But eventually we stuck with --realize. It's not
> great, yes. But we couldnt think of anything better. Happy to take
> suggestions. But no, --take-effect-immediately is not really an option.
What do other commands use for "do it now" (instead of "later")?
Perhaps
the ubiquitous "-f/--force" will do?
I think --now is fine. There's even precedent: the famous 'shutdown -h
now'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:48 p.m.
On 07/23/2010 03:13 AM, Adam Williamson wrote:
On Thu, 2010-07-22 at 17:37 -0400, Horst H. von Brand wrote:
> What do other commands use for "do it now" (instead of "later")?
Perhaps
> the ubiquitous "-f/--force" will do?
>
I think --now is fine. There's even precedent: the famous 'shutdown -h
now'.
Reading the rest of the thread, you would see this has all been
discussed and changed already.
Rahul
4:59 p.m.
On Fri, 2010-07-23 at 03:18 +0530, Rahul Sundaram wrote:
On 07/23/2010 03:13 AM, Adam Williamson wrote:
> On Thu, 2010-07-22 at 17:37 -0400, Horst H. von Brand wrote:
>> What do other commands use for "do it now" (instead of
"later")? Perhaps
>> the ubiquitous "-f/--force" will do?
>>
> I think --now is fine. There's even precedent: the famous 'shutdown -h
> now'.
>
Reading the rest of the thread, you would see this has all been
discussed and changed already.
I've read the whole thing, but it's easy to lose track of what option is
for what command.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:18 p.m.
On Thu, Jul 22, 2010 at 02:43:47PM -0700, Adam Williamson wrote:
I think --now is fine. There's even precedent: the famous
'shutdown -h
now'.
Bonus points if it also allows midnight, noon, and teatime a la `at`.
:)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:05 a.m.
On Thu, 22 Jul 2010 12:06:34 +1000
Dave Airlie <airlied(a)redhat.com> wrote:
>
> It is needed:
>
> if [ $1 -eq 1 ] ; then
> # For new installations, hook unit file into the
> appropriate places via symlinks /usr/bin/systemd-install enable
> --realize=reload %{unit name}.service > /dev/null 2>&1 || : else
> # For old installations, just reload the configuration,
> don't change symlinks /bin/bin/systemd-install realize
> --realize=reload %{unit name}.service > /dev/null 2>&1 || :
> fi
Wow thats pretty special... both an option called realize and a
argument, that won't get confusing no matter how long it lives, also
realize doesn't seem to be conveying a useful meaning, I'm a native
speaker and I'm not sure what you actually mean by realize in this
context.
I'm going with:
to make real; give reality to (a hope, fear, plan, etc.).
but its seems quite an abstract term to associate reality with an
abstract computer object.
Dave, I am not a native speaker, but I have the exact (or may be even
worse) problem. For as much as I try the syntax there is so obscure I
cannot "realize" what it means *at all*, just by looking at it.
Lennart, "realize" really is a bad bad bad choice, please consider
changing it while there is still time.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:40 p.m.
On Thu, 22.07.10 08:05, Simo Sorce (ssorce(a)redhat.com) wrote:
> to make real; give reality to (a hope, fear, plan, etc.).
>
> but its seems quite an abstract term to associate reality with an
> abstract computer object.
Dave, I am not a native speaker, but I have the exact (or may be even
worse) problem. For as much as I try the syntax there is so obscure I
cannot "realize" what it means *at all*, just by looking at it.
Lennart, "realize" really is a bad bad bad choice, please consider
changing it while there is still time.
Kay and I have discussed this now. We agreed to fold systemd-install
into systemctl entirely, and replace --realize by --now. Also, we'll
drop some of the options --realize had, and always imply that the init
system configuration shall be reloaded after all changes took
place. This basically means that this
is what will be done in %post in the general case:
if [ $1 -eq 1 ] ; then
systemctl enable foo.service
else
systemctl daemon-reload
# Optionally, make the update daemon restart or reload its configuration
systemctl reload-or-try-restart foo.service
fi
And for %preun it'll be:
if [ $1 -eq 0 ] ; then
systemctl disable --now foo.service
fi
Rationale:
"systemctl enable" installs the unit file in the system by creating the
symlinks suggested in the unit file. It also implicitly reloads the
configuration so that the init system knows about the changes.
"systemctl daemon-reload" simply tells the init system to reload its
configuration, no new symlinks are created.
"systemctl reload-or-try-restart" tells the specified service to reload
its configuration if it supports that. If it doesn't the daemon is
restarted. This is identical to the LSB "force-reload" verb. However we
chose to name this differently because we found "force-reload" not very
descriptive. That said, the tool actually understands "force-reload"
too, as equivalent (but it's not docuemnted). Something similar actually
applies to condrestart. LSB calls Fedora's condrestart try-restart. We
found the LSB name more descriptive and are advertising that, but we
actually understand "condrestart" as an alias for it too. Anyway, all I
wanna say here is that this nomenclature mostly stems from LSB though
with some minimal changes, and we also understand the unmodified LSB and
RH names for compat.
"systemctl disable --now" removes the unit file symlinks from
/etc/systemd/system, terminates the unit before this and reloads the
init system configuration after this. The "--now" controls whether the
unit is stopped or not.
I hope this simplification sounds good to many of you.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:43 p.m.
On Thu, 2010-07-22 at 20:40 +0200, Lennart Poettering wrote:
Kay and I have discussed this now. We agreed to fold systemd-install
into systemctl entirely, and replace --realize by --now. Also, we'll
drop some of the options --realize had, and always imply that the init
system configuration shall be reloaded after all changes took
place. This basically means that this
is what will be done in %post in the general case:
if [ $1 -eq 1 ] ; then
systemctl enable foo.service
else
systemctl daemon-reload
# Optionally, make the update daemon restart or reload its configuration
systemctl reload-or-try-restart foo.service
fi
And for %preun it'll be:
if [ $1 -eq 0 ] ; then
systemctl disable --now foo.service
fi
I hope this simplification sounds good to many of you.
I've not been in this thread but following along - and to me the above
is a great improvement in the command line syntax and naming.
-sv
2:23 p.m.
On Thu, 22 Jul 2010 20:40:53 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 08:05, Simo Sorce (ssorce(a)redhat.com) wrote:
> > to make real; give reality to (a hope, fear, plan, etc.).
> >
> > but its seems quite an abstract term to associate reality with an
> > abstract computer object.
>
> Dave, I am not a native speaker, but I have the exact (or may be
> even worse) problem. For as much as I try the syntax there is so
> obscure I cannot "realize" what it means *at all*, just by looking
> at it.
>
>
> Lennart, "realize" really is a bad bad bad choice, please consider
> changing it while there is still time.
Kay and I have discussed this now. We agreed to fold systemd-install
into systemctl entirely, and replace --realize by --now. Also, we'll
drop some of the options --realize had, and always imply that the init
system configuration shall be reloaded after all changes took
place. This basically means that this
is what will be done in %post in the general case:
if [ $1 -eq 1 ] ; then
systemctl enable foo.service
else
systemctl daemon-reload
# Optionally, make the update daemon restart or reload its
configuration systemctl reload-or-try-restart foo.service
fi
And for %preun it'll be:
if [ $1 -eq 0 ] ; then
systemctl disable --now foo.service
fi
Rationale:
"systemctl enable" installs the unit file in the system by creating
the symlinks suggested in the unit file. It also implicitly reloads
the configuration so that the init system knows about the changes.
"systemctl daemon-reload" simply tells the init system to reload its
configuration, no new symlinks are created.
"systemctl reload-or-try-restart" tells the specified service to
reload its configuration if it supports that. If it doesn't the
daemon is restarted. This is identical to the LSB "force-reload"
verb. However we chose to name this differently because we found
"force-reload" not very descriptive. That said, the tool actually
understands "force-reload" too, as equivalent (but it's not
docuemnted). Something similar actually applies to condrestart. LSB
calls Fedora's condrestart try-restart. We found the LSB name more
descriptive and are advertising that, but we actually understand
"condrestart" as an alias for it too. Anyway, all I wanna say here is
that this nomenclature mostly stems from LSB though with some minimal
changes, and we also understand the unmodified LSB and RH names for
compat.
"systemctl disable --now" removes the unit file symlinks from
/etc/systemd/system, terminates the unit before this and reloads the
init system configuration after this. The "--now" controls whether the
unit is stopped or not.
I hope this simplification sounds good to many of you.
Thanks, it looks *much* more understandable now!
Simo.
--
Simo Sorce * Red Hat, Inc * New York
2:25 p.m.
On 07/23/2010 12:10 AM, Lennart Poettering wrote:
Kay and I have discussed this now. We agreed to fold systemd-install
into systemctl entirely, and replace --realize by --now. Also, we'll
drop some of the options --realize had, and always imply that the init
system configuration shall be reloaded after all changes took
place. This basically means that this
is what will be done in %post in the general case:
if [ $1 -eq 1 ] ; then
systemctl enable foo.service
else
systemctl daemon-reload
Is there a particular reason why systemctl enable foo shouldn't work?
why am I specifying foo.service there?
Rahul
6:16 p.m.
On Fri, 23.07.10 00:55, Rahul Sundaram (metherid(a)gmail.com) wrote:
On 07/23/2010 12:10 AM, Lennart Poettering wrote:
> Kay and I have discussed this now. We agreed to fold systemd-install
> into systemctl entirely, and replace --realize by --now. Also, we'll
> drop some of the options --realize had, and always imply that the init
> system configuration shall be reloaded after all changes took
> place. This basically means that this
> is what will be done in %post in the general case:
>
> if [ $1 -eq 1 ] ; then
> systemctl enable foo.service
> else
> systemctl daemon-reload
>
Is there a particular reason why systemctl enable foo shouldn't work?
why am I specifying foo.service there?
Well, because you mean the service, not the socket or the timer or any
other kind of unit?
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:43 a.m.
On 07/22/2010 07:16 PM, Lennart Poettering wrote:
On Fri, 23.07.10 00:55, Rahul Sundaram (metherid(a)gmail.com) wrote:
>
> On 07/23/2010 12:10 AM, Lennart Poettering wrote:
>> Kay and I have discussed this now. We agreed to fold systemd-install
>> into systemctl entirely, and replace --realize by --now. Also, we'll
>> drop some of the options --realize had, and always imply that the init
>> system configuration shall be reloaded after all changes took
>> place. This basically means that this
>> is what will be done in %post in the general case:
>>
>> if [ $1 -eq 1 ] ; then
>> systemctl enable foo.service
>> else
>> systemctl daemon-reload
>>
>
> Is there a particular reason why systemctl enable foo shouldn't work?
> why am I specifying foo.service there?
Well, because you mean the service, not the socket or the timer or any
other kind of unit?
It would be nice if systemctl enable foo implies foo.service, presumably
services are going to be the most common unit type manipulated with
systemctl, and it's closer to service/chkconfig behavior.
Coupled with a clear error message like 'No unit file found
/etc/systemd/foo.blah', there wouldn't be any user confusion if someone
tries systemctl enable foo for foo.socket.
- Cole
2:34 p.m.
On Thu, Jul 22, 2010 at 08:40:53PM +0200, Lennart Poettering wrote:
I hope this simplification sounds good to many of you.
It does. Thanks.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
4:51 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 08:05, Simo Sorce (ssorce(a)redhat.com) wrote:
> > to make real; give reality to (a hope, fear, plan, etc.).
> >
> > but its seems quite an abstract term to associate reality with an
> > abstract computer object.
>
> Dave, I am not a native speaker, but I have the exact (or may be even
> worse) problem. For as much as I try the syntax there is so obscure I
> cannot "realize" what it means *at all*, just by looking at it.
>
>
> Lennart, "realize" really is a bad bad bad choice, please consider
> changing it while there is still time.
Nodz vigorously.
Kay and I have discussed this now. We agreed to fold systemd-install
into systemctl entirely, and replace --realize by --now. Also, we'll
drop some of the options --realize had, and always imply that the init
system configuration shall be reloaded after all changes took
place. This basically means that this
is what will be done in %post in the general case:
if [ $1 -eq 1 ] ; then
systemctl enable foo.service
else
systemctl daemon-reload
Huh? One you have to tell about the affected service, the other not?
Why not just "systemctl reload foo.service"?
Why not just "systemctl frob foo" (no ".service")?
# Optionally, make the update daemon restart or reload its
configuration
systemctl reload-or-try-restart foo.service
Too verbose... "restart" would do for me (if changed, start the new one; if
old, just do a "killall -HUP service" or some such)
fi
And for %preun it'll be:
if [ $1 -eq 0 ] ; then
systemctl disable --now foo.service
fi
Rationale:
"systemctl enable" installs the unit file in the system by creating the
symlinks suggested in the unit file. It also implicitly reloads the
configuration so that the init system knows about the changes.
OK.
"systemctl daemon-reload" simply tells the init system to
reload its
configuration, no new symlinks are created.
Oh, now I get it. But this doesn't jibe. It is talking about _init_, not
the _services_ it manages. Perhaps this demands another command (name), or
a special argument? I.e., "systemctl reload init"?
"systemctl reload-or-try-restart" tells the specified
service to reload
its configuration if it supports that. If it doesn't the daemon is
restarted. This is identical to the LSB "force-reload" verb. However we
chose to name this differently because we found "force-reload" not very
descriptive. That said, the tool actually understands "force-reload"
too, as equivalent (but it's not docuemnted). Something similar actually
applies to condrestart. LSB calls Fedora's condrestart try-restart. We
found the LSB name more descriptive and are advertising that, but we
actually understand "condrestart" as an alias for it too. Anyway, all I
wanna say here is that this nomenclature mostly stems from LSB though
with some minimal changes, and we also understand the unmodified LSB and
RH names for compat.
"systemctl disable --now" removes the unit file symlinks
from
/etc/systemd/system, terminates the unit before this and reloads the
init system configuration after this. The "--now" controls whether the
unit is stopped or not.
I hope this simplification sounds good to many of you.
Much better. Tghanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
6:25 p.m.
On Thu, 22.07.10 17:51, Horst H. von Brand (vonbrand(a)inf.utfsm.cl) wrote:
> Kay and I have discussed this now. We agreed to fold
systemd-install
> into systemctl entirely, and replace --realize by --now. Also, we'll
> drop some of the options --realize had, and always imply that the init
> system configuration shall be reloaded after all changes took
> place. This basically means that this
> is what will be done in %post in the general case:
>
> if [ $1 -eq 1 ] ; then
> systemctl enable foo.service
> else
> systemctl daemon-reload
Huh? One you have to tell about the affected service, the other not?
Yes, because we reload init system configuration globally, not
partially. This otherwise creates all kind of messes with problems where
configuration changes might be half loaded and half not loaded.
And the enable command already implicitly reloads the init system config
to make sure the symlinks created are taken into account by the init
system. When we upgrade packages we don't change anything howevber, and
hence do only the init system reload.
Why not just "systemctl reload foo.service"?
Because that reloads the configuration of the service, not the
configuration of the init system.
Why not just "systemctl frob foo" (no
".service")?
Because there are different kinds of units, 10 to be precise. Services,
sockets, devices, mounts, automounts, timers, swaps, paths, target and
snapshots.
> # Optionally, make the update daemon restart or reload its
configuration
> systemctl reload-or-try-restart foo.service
Too verbose... "restart" would do for me (if changed, start the new one; if
old, just do a "killall -HUP service" or some such)
No, I think it would suck departing from the LSB definitions here. And
for LSB init scripts the verb "restart" means "restart when running,
start when not running". LSB also defines what "try-restart" means and
"reload" means, And I think it we should not go directly against that.
> "systemctl daemon-reload" simply tells the init system
to reload its
> configuration, no new symlinks are created.
Oh, now I get it. But this doesn't jibe. It is talking about _init_, not
the _services_ it manages. Perhaps this demands another command (name), or
a special argument? I.e., "systemctl reload init"?
"reload" reloads the configurations of the services
specified. "daemon-reload" reloads the configuration of the init daemon
itself. i.e. equivalent to SIGHUP on traditional sysvinit.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:28 a.m.
On Fri, Jul 23, 2010 at 01:25:23AM +0200, Lennart Poettering wrote:
On Thu, 22.07.10 17:51, Horst H. von Brand (vonbrand(a)inf.utfsm.cl)
wrote:
> > Kay and I have discussed this now. We agreed to fold systemd-install
> > into systemctl entirely, and replace --realize by --now. Also, we'll
> > drop some of the options --realize had, and always imply that the init
> > system configuration shall be reloaded after all changes took
> > place. This basically means that this
> > is what will be done in %post in the general case:
> >
> > if [ $1 -eq 1 ] ; then
> > systemctl enable foo.service
> > else
> > systemctl daemon-reload
>
> Huh? One you have to tell about the affected service, the other not?
Yes, because we reload init system configuration globally, not
partially. This otherwise creates all kind of messes with problems where
configuration changes might be half loaded and half not loaded.
And the enable command already implicitly reloads the init system config
to make sure the symlinks created are taken into account by the init
system. When we upgrade packages we don't change anything howevber, and
hence do only the init system reload.
Do you really mean this, then? ::
%post
if [ $1 -gt 1 ] ; then
systemctl enable foo.service
elif [ $1 -eq 1 ] ; then
systemctl daemon-reload
fi
(in %post and %pre, there are two packages installed when doing an upgrade.
Thus, the value of $1 will be 2 for an upgrade and 1 for an install).
-Toshio
7:43 p.m.
On Thu, 22.07.10 20:40, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
On Thu, 22.07.10 08:05, Simo Sorce (ssorce(a)redhat.com) wrote:
> > to make real; give reality to (a hope, fear, plan, etc.).
> >
> > but its seems quite an abstract term to associate reality with an
> > abstract computer object.
>
> Dave, I am not a native speaker, but I have the exact (or may be even
> worse) problem. For as much as I try the syntax there is so obscure I
> cannot "realize" what it means *at all*, just by looking at it.
>
>
> Lennart, "realize" really is a bad bad bad choice, please consider
> changing it while there is still time.
Kay and I have discussed this now. We agreed to fold systemd-install
into systemctl entirely, and replace --realize by --now. Also, we'll
drop some of the options --realize had, and always imply that the init
system configuration shall be reloaded after all changes took
place. This basically means that this
is what will be done in %post in the general case:
Kay and I discussed that even further now and decided to scrap --now
entirely now. There's little reason left to keep this as flag around. I
think it is more descriptive to do this on %preun:
systemctl stop postfix.service
systemctl disable postfix.service
then it would be to do this:
systemctl disable --now postfix.service.
Especially for "enable" this is even more the case, since depending on the
case you might or might not want to restart, or reload the service on
package upgrade. For example, restarting D-Bus or the gettys on package
uprgade would be a really bad idea, but restarting ntpd might be a good
idea. Given that packagers would have to specifiy anyway whether they
want to reload, or restart or nothing at all a service on upgrade we
think it would make more sense if they simply delcare their choice
explicitly and do either one fo this in %post:
systemctl enable foobar.service
systemctl try-restart foobar.service ### restart if running
or:
systemctl enable foobar.service
systemctl reload foobar.service ### reload if running
or just:
systemctl enable foobar.service
or, for debian folks which want to start services after package installation:
systemctl enable foobar.service
systemctl restart foobar.service ### restart if runnning, start if not
running
I think this scheme is really simply now, as the operations issued are
first class commands, and no switches necessary. Also, the verbs here
are 1:1 from the LSB specs, and hence should offer no surprises to
anybody.
Everybody happy?
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:25 p.m.
On Fri, 23 Jul 2010 02:43:45 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 22.07.10 20:40, Lennart Poettering (mzerqung(a)0pointer.de)
wrote:
>
> On Thu, 22.07.10 08:05, Simo Sorce (ssorce(a)redhat.com) wrote:
>
> > > to make real; give reality to (a hope, fear, plan, etc.).
> > >
> > > but its seems quite an abstract term to associate reality with
> > > an abstract computer object.
> >
> > Dave, I am not a native speaker, but I have the exact (or may be
> > even worse) problem. For as much as I try the syntax there is so
> > obscure I cannot "realize" what it means *at all*, just by
> > looking at it.
> >
> >
> > Lennart, "realize" really is a bad bad bad choice, please consider
> > changing it while there is still time.
>
> Kay and I have discussed this now. We agreed to fold systemd-install
> into systemctl entirely, and replace --realize by --now. Also, we'll
> drop some of the options --realize had, and always imply that the
> init system configuration shall be reloaded after all changes took
> place. This basically means that this
> is what will be done in %post in the general case:
Kay and I discussed that even further now and decided to scrap --now
entirely now. There's little reason left to keep this as flag around.
I think it is more descriptive to do this on %preun:
systemctl stop postfix.service
systemctl disable postfix.service
then it would be to do this:
systemctl disable --now postfix.service.
Especially for "enable" this is even more the case, since depending
on the case you might or might not want to restart, or reload the
service on package upgrade. For example, restarting D-Bus or the
gettys on package uprgade would be a really bad idea, but restarting
ntpd might be a good idea. Given that packagers would have to
specifiy anyway whether they want to reload, or restart or nothing at
all a service on upgrade we think it would make more sense if they
simply delcare their choice explicitly and do either one fo this in
%post:
systemctl enable foobar.service
systemctl try-restart foobar.service ### restart if running
or:
systemctl enable foobar.service
systemctl reload foobar.service ### reload if running
or just:
systemctl enable foobar.service
or, for debian folks which want to start services after package
installation:
systemctl enable foobar.service
systemctl restart foobar.service ### restart if runnning,
start if not running
I think this scheme is really simply now, as the operations issued are
first class commands, and no switches necessary. Also, the verbs here
are 1:1 from the LSB specs, and hence should offer no surprises to
anybody.
Everybody happy?
I am personally quite happy, this looks much much better.
Juyst one very minor nitpick, why
systemctl enable foo.service
instead of
systemctl enable service foo ?
And of course
systemctl enable socket bar
etc...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
6:31 a.m.
On Thu, 22.07.10 23:25, Simo Sorce (ssorce(a)redhat.com) wrote:
> I think this scheme is really simply now, as the operations
issued are
> first class commands, and no switches necessary. Also, the verbs here
> are 1:1 from the LSB specs, and hence should offer no surprises to
> anybody.
>
> Everybody happy?
I am personally quite happy, this looks much much better.
Juyst one very minor nitpick, why
systemctl enable foo.service
instead of
systemctl enable service foo ?
And of course
systemctl enable socket bar
etc...
For simplicity's sake we thought it would be smart to ensure that the
unit names are actually identical to the unit configuration files they
are configured in on disk. i.e. you'll find the configuration for a unit
"foobar.service" in the configuration file "foobar.service". And for
a
socket "waldo.socket" in the file "waldo.socket". And so on.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:43 a.m.
On Fri, Jul 23, 2010 at 01:31:47PM +0200, Lennart Poettering wrote:
For simplicity's sake we thought it would be smart to ensure that
the
unit names are actually identical to the unit configuration files they
are configured in on disk. i.e. you'll find the configuration for a unit
"foobar.service" in the configuration file "foobar.service". And for
a
socket "waldo.socket" in the file "waldo.socket". And so on.
Presumably we'll have smart tab completion which will make that less
painful. I actually like the explicitness of the .service extention, as it
makes a distinction between running a given binary daemon and running a
_specific configuration for_ that daemon.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:26 p.m.
On Fri, Jul 23, 2010 at 02:43:45AM +0200, Lennart Poettering wrote:
On Thu, 22.07.10 20:40, Lennart Poettering (mzerqung(a)0pointer.de)
wrote:
systemctl stop postfix.service
systemctl disable postfix.service
systemctl enable foobar.service
systemctl try-restart foobar.service ### restart if running
systemctl reload foobar.service ### reload if running
systemctl restart foobar.service ### restart if runnning, start if not
running
I think this scheme is really simply now, as the operations issued are
first class commands, and no switches necessary. Also, the verbs here
are 1:1 from the LSB specs, and hence should offer no surprises to
anybody.
Everybody happy?
MUCH nicer, thanks!
11:18 p.m.
On Thu, Jul 22, 2010 at 18:43, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
systemctl enable foobar.service
systemctl reload foobar.service ### reload if running
or just:
systemctl enable foobar.service
or, for debian folks which want to start services after package installation:
systemctl enable foobar.service
systemctl restart foobar.service ### restart if runnning, start if not
running
I think this scheme is really simply now, as the operations issued are
first class commands, and no switches necessary. Also, the verbs here
are 1:1 from the LSB specs, and hence should offer no surprises to
anybody.
Everybody happy?
I like them a lot better. I will go read through the blog to figure
out why there is a .service at the end of things...
Thankyou.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
9:34 p.m.
Lennart Poettering writes:
On Wed, 21.07.10 20:08, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> Normally, we don't want a service to be started just because the package has
> been installed:
>
Yepp, which is why I said "very low-level ones", i.e. as low-level as
for example udev, which you really want to be running.
I'm not sure it's a good idea for udev to come up as soon as Anaconda
installs the rpm on a freshly-partitioned and formatted disk, before the
rest of the system gets installed.
Or, when Anaconda is in the middle of updating a system from a previous
version of Fedora.
Existing udev rules in /lib/udev/rules.d may result in udev attempting to
execute commands or scripts that have not yet been updated from a previous
fedora release. Hillarity ensues. Or, some of these rules may not yet be
installed, in the case of a fresh install. More hillarity ensues.
9:46 p.m.
On Wed, 21.07.10 22:34, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
Or, when Anaconda is in the middle of updating a system from a
previous version of Fedora.
Existing udev rules in /lib/udev/rules.d may result in udev
attempting to execute commands or scripts that have not yet been
updated from a previous fedora release. Hillarity ensues. Or, some
of these rules may not yet be installed, in the case of a fresh
install. More hillarity ensues.
I am not entirely sure how anaconda works, but let me say that
systemd-install is actually kinda smart and figures out if it is run in
a chroot (or on a non-systemd system) and then will only apply the
configuration changes but not actually start or stop anything. So
assuming that anaconda chroot()s into the installed system then
everything should be fine.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:32 a.m.
Once upon a time, Sam Varshavchik <mrsam(a)courier-mta.com> said:
I'm not sure it's a good idea for udev to come up as soon as
Anaconda
installs the rpm on a freshly-partitioned and formatted disk, before the
rest of the system gets installed.
Isn't it against the packaging guidelines to actually start something
from %post? I thought it was only okay to _re_start something that was
already running.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
7:31 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
if [ $1 -eq 0 ] ; then
/usr/bin/systemd-install disable --realize=yes %{unit name}.service >
/dev/null 2>&1 || :
fi
Umm, that's copying one of the much-mocked things of Windows, where you
click "Start" to shutdown. "systemd-install" to remove?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:36 a.m.
On Thu, Jul 22, 2010 at 07:31:22AM -0500, Chris Adams wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> if [ $1 -eq 0 ] ; then
> /usr/bin/systemd-install disable --realize=yes %{unit name}.service >
/dev/null 2>&1 || :
> fi
Umm, that's copying one of the much-mocked things of Windows, where you
click "Start" to shutdown. "systemd-install" to remove?
Shouldn't it be possible to have a similar "systemd-remove" that
resolves to the appropriate option?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
6:41 p.m.
On Thu, Jul 22, 2010 at 03:30:42AM +0200, Lennart Poettering wrote:
On Wed, 21.07.10 20:08, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> > - If you want to enable and possibly start a service from the %post of
> > an RPM then use the "systemd-install enable" command, which will
> > create a few symlinks as listed in the [Install] section of the unit
> > file. On top of that you may also pass --realize=... to the command,
> > which allows you to not only enable the unit for the next boot, but
> > also have the changes take effect immediately: i.e. --realize=reload
> > is the very least you should use, which simply makes systemd aware of
> > the changed symlinks. Then, at time of %preun you should use
> > --realize=yes which makes sure the daemon is stopped in
> > deinstallation. For a few daemons it makes sense to restart them if
> > they are running already during upgrade. Use --realize=minimal for
> > those. For even others (usually very low-level ones) it might even
> > make sense to start them right-away after installation, even if they
> > were not running before. For those use --realize=maybe. But which
> > option you use really depends on the package. Most packages
> > should probably stick to --realize=yes on %preun and --realize=reload
> > in %post. Suggested .spec file fragments you find in the daemon(7) man
> > page.
> >
> Normally, we don't want a service to be started just because the package has
> been installed:
>
Yepp, which is why I said "very low-level ones", i.e. as low-level as
for example udev, which you really want to be running.
> https://fedoraproject.org/wiki/Packaging/SysVInitScript.
>
> This is the current recommended scriptlets:
>
> %post
> # This adds the proper /etc/rc*.d links for the script
> /sbin/chkconfig --add <script>
>
> %preun
> if [ $1 = 0 ] ; then
> /sbin/service <script> stop >/dev/null 2>&1
> /sbin/chkconfig --del <script>
> fi
>
> %postun
> if [ "$1" -ge "1" ] ; then
> /sbin/service <script> condrestart >/dev/null 2>&1 || :
> fi
>
>
> I think I've got the %preun translated correctly but I'm not sure about
> either the %post or %postun::
>
> %post
> # Don't need a %post as systemd automatically knows about the defaults?
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places via symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
else
# For old installations, just reload the configuration, don't change
symlinks
/bin/bin/systemd-install realize --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
fi
My impression from the documentation is that systemd-install enable will
cause the service to be enabled on the next reboot. Is that not correct?
>
> %preun
> if [ $1 = 0 ] ; then
> /usr/bin/systemd-install disable %{unit name}.service --realize=disable >
/dev/null 2>&1 || :
> fi
Almost:
if [ $1 -eq 0 ] ; then
/usr/bin/systemd-install disable --realize=yes %{unit name}.service >
/dev/null 2>&1 || :
fi
Ah -- I see you wrote that above. The spec file example in the man page
seemed to use --realize=disable, though. What's the difference and should
the man page be changed? (Or perhaps I misread it.)
> %postun
> if [ "$1" -ge "1" ] ; then
> # Can't figure out how to do a conditional restart here. Help?
> fi
If you want to restart the service on upgrade I'd do that in %post. It
should be sufficient to replace --realize=reload by --realize=minimal
which will restart the unit if it is running, and only then.
%postun is better because the old package has been uninstalled at that
point. For many packages, that probably won't matter but it's easier to
give one script than to explain that %post will usually work but some
packages will need to use an equivalent action in %postun.
And the same question here about systemd-install enable causing the service
to be enabled on reboot.
-Toshio
6:49 p.m.
On Thu, 22.07.10 19:41, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> if [ $1 -eq 1 ] ; then
> # For new installations, hook unit file into the appropriate places via
symlinks
> /usr/bin/systemd-install enable --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
> else
> # For old installations, just reload the configuration, don't change
symlinks
> /bin/bin/systemd-install realize --realize=reload %{unit name}.service >
/dev/null 2>&1 || :
> fi
>
My impression from the documentation is that systemd-install enable will
cause the service to be enabled on the next reboot. Is that not
correct?
Yes, unless you aks the init system to reload.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:59 p.m.
On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote:
> My impression from the documentation is that systemd-install
enable will
> cause the service to be enabled on the next reboot. Is that not
> correct?
Yes, unless you aks the init system to reload.
Wait, am I correct in understanding that (pseudocode -- actual commands may
be wrong):
systemctl enable apache.service
will not cause apache to be started immediately, but
systemctl enable postfix.service
systemctl daemon-reload
will cause postfix to start, and as a side-effect also start the apache that
was enabled earlier but not intended to start?
That would be surprising!
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:31 p.m.
On Thu, 22.07.10 19:59, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote:
> > My impression from the documentation is that systemd-install enable will
> > cause the service to be enabled on the next reboot. Is that not
> > correct?
> Yes, unless you aks the init system to reload.
Wait, am I correct in understanding that (pseudocode -- actual commands may
be wrong):
systemctl enable apache.service
will not cause apache to be started immediately, but
systemctl enable postfix.service
systemctl daemon-reload
will cause postfix to start, and as a side-effect also start the apache that
was enabled earlier but not intended to start?
That would be surprising!
Well, part of the changes I was now suggesting is that we do the init
daemon configuration reload always and implicitly by default. I think
doing that is smart since it removes the chance that people can go wrong
and might be confused why the change that they just made is not taken
into account. That would mean that the lines above would actually be
mostly equivalent, except that the init daemon configuration in the
first example is reloaded once, and in the second example twice.
Note that "systemctl enable foo.service" will (with my suggested changes
in place) result in foo.service to be started. For Fedora we generally
wouldn't want that anyway except for very few niche cases. Other distros
have other policies there, and for example on Debian servcies that are
installed are started right-away. Those distros should then simply place
an additional "systemctl start foo.service" in their %post section (or
however that is called for .deb)
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:21 p.m.
On Fri, Jul 23, 2010 at 02:31:49AM +0200, Lennart Poettering wrote:
Note that "systemctl enable foo.service" will (with my
suggested changes
in place) result in foo.service to be started. For Fedora we generally
Is that "will not result"? Otherwise I'm having trouble parsing this
paragraph.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:31 p.m.
On Thu, 22.07.10 22:21, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Fri, Jul 23, 2010 at 02:31:49AM +0200, Lennart Poettering wrote:
> Note that "systemctl enable foo.service" will (with my suggested changes
> in place) result in foo.service to be started. For Fedora we generally
Is that "will not result"? Otherwise I'm having trouble parsing this
paragraph.
Oops, yes, you're right. Sorry for the confusion.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:15 a.m.
On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote:
On Thu, 22.07.10 19:41, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> > if [ $1 -eq 1 ] ; then
> > # For new installations, hook unit file into the appropriate places via
symlinks
> > /usr/bin/systemd-install enable --realize=reload %{unit name}.service
> /dev/null 2>&1 || :
> > else
> > # For old installations, just reload the configuration, don't
change symlinks
> > /bin/bin/systemd-install realize --realize=reload %{unit name}.service
> /dev/null 2>&1 || :
> > fi
> >
> My impression from the documentation is that systemd-install enable will
> cause the service to be enabled on the next reboot. Is that not
> correct?
Yes, unless you aks the init system to reload.
So we don't want to do systemd-install enable in most spec files.
What systemd doesn't provide is an equivalent of the chkconfig add command.
I'm not sure if we don't need that in the systemd world or if it's an
oversight that we need to have added into systemd. What do you think?
Basically what we're trying to replicate is:
* User can install a service
* That does not enable the service to start, even on the next reboot; other
service asks for the socket, etc.
* However, the init system knows that the service is available for the user
to explicitly turn on.
-Toshio
6:42 a.m.
On Fri, 23.07.10 07:15, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> Yes, unless you aks the init system to reload.
>
So we don't want to do systemd-install enable in most spec files.
Dunno.
There are three levels of installation thinkable:
1) on package installation a .service file is placed in
/lib/systemd/system, but not otherwise hooked into anything, i.e. it is
not made sure it is actviated at startup or any other event. It is left
to the user/admin to enable the unit, or even start it.
2) on package installation a .service file is placed in
/lib/systemd/system, and "systemctl enable blabla.service" is called, to
hook it into one or more well-known units, for example to start it on
next boot automatically. It is left to the user/admin to start it after
installation if he wants to.
3) on package installation a .service file is placed in
/lib/systemd/system, and "systemctl enable blabla.service" is called,
and "systemctl start blabla.service" or "systemctl restart
blabla.service" is called, which not only hooks the service unit into
other units, but also starts it right-away.
In Fedora we generally try to avoid level 3, however it might be handy
for a few very very low-level daemons, such as udev, possibly. For other
distros (such as Debian), which have different policies level 3 might be
a more likely choice. Depending on the package in Fedora we'll stick
more often to level 1 or 2.
What systemd doesn't provide is an equivalent of the chkconfig
add command.
I'm not sure if we don't need that in the systemd world or if it's an
oversight that we need to have added into systemd. What do you think?
I don't see why that woulöd be necessary.
Basically what we're trying to replicate is:
* User can install a service
* That does not enable the service to start, even on the next reboot; other
service asks for the socket, etc.
* However, the init system knows that the service is available for the user
to explicitly turn on.
Yupp, that would be level 1 from the list above.
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:03 a.m.
On Fri, Jul 23, 2010 at 01:42:03PM +0200, Lennart Poettering wrote:
On Fri, 23.07.10 07:15, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> > Yes, unless you aks the init system to reload.
> >
> So we don't want to do systemd-install enable in most spec files.
Dunno.
There are three levels of installation thinkable:
1) on package installation a .service file is placed in
/lib/systemd/system, but not otherwise hooked into anything, i.e. it is
not made sure it is actviated at startup or any other event. It is left
to the user/admin to enable the unit, or even start it.
2) on package installation a .service file is placed in
/lib/systemd/system, and "systemctl enable blabla.service" is called, to
hook it into one or more well-known units, for example to start it on
next boot automatically. It is left to the user/admin to start it after
installation if he wants to.
3) on package installation a .service file is placed in
/lib/systemd/system, and "systemctl enable blabla.service" is called,
and "systemctl start blabla.service" or "systemctl restart
blabla.service" is called, which not only hooks the service unit into
other units, but also starts it right-away.
In Fedora we generally try to avoid level 3, however it might be handy
for a few very very low-level daemons, such as udev, possibly. For other
distros (such as Debian), which have different policies level 3 might be
a more likely choice. Depending on the package in Fedora we'll stick
more often to level 1 or 2.
In Fedora currently, we should really only be using level 1 and level 3 from
above with the current sysVinit guidelines.
> What systemd doesn't provide is an equivalent of the
chkconfig add command.
> I'm not sure if we don't need that in the systemd world or if it's an
> oversight that we need to have added into systemd. What do you think?
I don't see why that woulöd be necessary.
> Basically what we're trying to replicate is:
>
> * User can install a service
> * That does not enable the service to start, even on the next reboot; other
> service asks for the socket, etc.
> * However, the init system knows that the service is available for the user
> to explicitly turn on.
Yupp, that would be level 1 from the list above.
Excellent. So is this the proper scriptlets for the common cases? (For
instance, apache):
Requires(preun): systemd
Requires(postun): systemd
%post
# Don't do anything. systemd doesn't require this
%preun
if [ 0$1 -eq 0 ] ; then
# Package removal, not upgrade
# Don't allow errors when stopping service to prevent things like data
# corruption.
/bin/systemctl stop httpd.service >/dev/null 2>&1
/bin/systemctl disable httpd.service > /dev/null 2>&1 || :
fi
%postun
if [ 0$1 -ge 1 ] ; then
systemctl try-restart httpd.service
fi
That seems close to what te current guidelines specify for systemVinit
scripts. One thing that I'm not sure of is what happens on reboot after
running "systemctl try-restart". Does "systemctl try-restart" imply
"systemctl enable" and so the program would be started on next reboot? Or
does it not get enabled because try-restart does not hook it into the more
well-known units?
-Toshio
6:24 a.m.
On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote:
On Thu, 22.07.10 19:41, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> > if [ $1 -eq 1 ] ; then
> > # For new installations, hook unit file into the appropriate places via
symlinks
> > /usr/bin/systemd-install enable --realize=reload %{unit name}.service
> /dev/null 2>&1 || :
> > else
> > # For old installations, just reload the configuration, don't
change symlinks
> > /bin/bin/systemd-install realize --realize=reload %{unit name}.service
> /dev/null 2>&1 || :
> > fi
> >
> My impression from the documentation is that systemd-install enable will
> cause the service to be enabled on the next reboot. Is that not
> correct?
Yes, unless you aks the init system to reload.
Note: I've added a Requirement for packaging guidelines to be added for
systemd to the Feature page:
https://fedoraproject.org/wiki/Features/systemd#Dependencies
-Toshio
4:53 p.m.
On Wed, 14.07.10 15:42, Kevin Fenzi (kevin(a)scrye.com) wrote:
On Wed, 14 Jul 2010 23:30:44 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> Well, if this is all this is about then I wonder why this is there
> anyway? If no gdm is installed, then runlevel 5 and 3 should be
> identical anyway, so what's the point of fixing the default runlevel
> there?
Because you may have gdm installed and not wish to currently boot with
it? I just tried systemd on a test machine here... it came up fine, but
it started gdm, even though I normally don't want it to do so.
But anaconda doesn't even offer you that functionality...
How can I tell systemd not to boot in graphical?
rm /etc/systemd/system/default.target
ln
-s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Yepp. I'd do it with ln -sf however, makes it shorter:
$ ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Isnt there some real beauty in the simplicity of this line? ;-)
Perhaps someone could put together a wiki page for lazy sysadmins
with
a Q&A? ie, I used to do this in upstart/sysvinit, how do I do it with
systemd?
I have added this now to our Tips & Tricks list:
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
Anyhow, the machine came up fine, so thats pretty nice compatibility
wise. ;)
Yay!
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:59 p.m.
ons 2010-07-14 klockan 23:53 +0200 skrev Lennart Poettering:
On Wed, 14.07.10 15:42, Kevin Fenzi (kevin(a)scrye.com) wrote:
> Because you may have gdm installed and not wish to currently
boot with
> it? I just tried systemd on a test machine here... it came up fine, but
> it started gdm, even though I normally don't want it to do so.
But anaconda doesn't even offer you that functionality...
Actually in kickstart scripts you can specify "text" which will run the
installation in text mode and also make runlevel 3 the default. It's
pretty useless though since if you do "semi-interactive" kickstarts
(manual partitioning, everything else automatic for example) you want to
install in graphical mode because text mode lacks some features but you
still often want to boot into runlevel 3, so you end up specifying
"graphical" instead of "text" and sed:ing inittab in the kickstart
%post
script.
/Alexander
1:28 a.m.
On Wed, Jul 14, 2010 at 11:42 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Wed, 14 Jul 2010 23:30:44 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> Well, if this is all this is about then I wonder why this is there
> anyway? If no gdm is installed, then runlevel 5 and 3 should be
> identical anyway, so what's the point of fixing the default runlevel
> there?
Because you may have gdm installed and not wish to currently boot with
it? I just tried systemd on a test machine here... it came up fine, but
it started gdm, even though I normally don't want it to do so.
How can I tell systemd not to boot in graphical?
Pass "3" to the kernel cmdline ... that is how I always do it and
systemd supports it just fine.
2:34 p.m.
On Wed, 2010-07-14 at 20:13 +0200, Lennart Poettering wrote:
On Wed, 14.07.10 13:44, Bill Nottingham (notting(a)redhat.com) wrote:
>
> Lennart Poettering (mzerqung(a)0pointer.de) said:
> > There's also the systemd.unit= kernel command line option which you may
> > use to boot into different targets. See the feature page for details.
>
> Does it pull this from inittab if there's no other configuration for
> this?
Ok. You got me on this one. Systemd does actually not parse the
inittab. That cruft looked a bit too ugly and clumsy and old for us to
support.
Vaguely a propos - does systemd execute /etc/rc.local ?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:42 p.m.
Adam Williamson (awilliam(a)redhat.com) said:
> > Does it pull this from inittab if there's no other
configuration for
> > this?
>
> Ok. You got me on this one. Systemd does actually not parse the
> inittab. That cruft looked a bit too ugly and clumsy and old for us to
> support.
Vaguely a propos - does systemd execute /etc/rc.local ?
Yes.
Bill
2:47 p.m.
On Wed, 14.07.10 12:34, Adam Williamson (awilliam(a)redhat.com) wrote:
> Ok. You got me on this one. Systemd does actually not parse the
> inittab. That cruft looked a bit too ugly and clumsy and old for us to
> support.
Vaguely a propos - does systemd execute /etc/rc.local ?
Yes, there is a service unit for that we install by default. Can't say I
am a big fan of /etc/rc.local though... ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:50 p.m.
On Wed, Jul 14, 2010 at 9:47 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Wed, 14.07.10 12:34, Adam Williamson (awilliam(a)redhat.com) wrote:
> > Ok. You got me on this one. Systemd does actually not parse the
> > inittab. That cruft looked a bit too ugly and clumsy and old for us to
> > support.
>
> Vaguely a propos - does systemd execute /etc/rc.local ?
Yes, there is a service unit for that we install by default. Can't say I
am a big fan of /etc/rc.local though... ;-)
While we are changing stuff anyway can we rename it to /etc/rc.randomhacks ;)
4:51 p.m.
On 07/14/2010 09:13 PM, Lennart Poettering wrote:
/etc/systemd/system/default.target →
/lib/systemd/system/graphical.target
to boot into the graphical stuff by default. This is the default as we
package it.
Lets say the admin (or Anaconda) has modified the default.target
symlink. What happens when systemd rpm is updated? Does the symlink get
replaced with the one in the rpm?
--
Kalev
5:01 p.m.
On Thu, 15.07.10 00:51, Kalev Lember (kalev(a)smartlink.ee) wrote:
On 07/14/2010 09:13 PM, Lennart Poettering wrote:
> /etc/systemd/system/default.target → /lib/systemd/system/graphical.target
>
> to boot into the graphical stuff by default. This is the default as we
> package it.
Lets say the admin (or Anaconda) has modified the default.target
symlink. What happens when systemd rpm is updated? Does the symlink get
replaced with the one in the rpm?
Yes, that is what currently happens. But we probably should fix that so
that the symlinks are not recreated on upgrade. A possible solution
could be to %ghost them and create them in %post.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:32 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
Well, I am not sure what you mean by 95% coverage case. Minus bugs
we
should have 99.9% compatibility with SysV init right now. And those bugs
we don't find if people don't use things. Feature-wise systemd is
definitely "complete", bug-wise not really since it got only limited testing
so far.
My concern is things that aren't done via sysvinit services, but
are currently done via upstart. Off the top of my head, that includes:
1. normal gettys
2. single-user mode
3. ctrl-alt-delete
4. prefdm starting
5. automatically starting gettys on serial consoles
6. plymouth interactions
7. ConsoleKit logging
8. system-setup-keyboard
9. readahead
Obviously, most of these are handled now, but I would suspect there are
still some gaps.
Bill
3:09 p.m.
On Wed, 14.07.10 14:32, Bill Nottingham (notting(a)redhat.com) wrote:
1. normal gettys
2. single-user mode
3. ctrl-alt-delete
4. prefdm starting
These four things should be covered for alraedy.
5. automatically starting gettys on serial consoles
This is currently not dealt with, I have added this to my todo list
now. We'll come up with something. Most likely the tty devices should
then just pull in the indivdual gettys via dependencies. Probably
something we should have done anyway...
6. plymouth interactions
There's https://bugzilla.redhat.com/show_bug.cgi?id=614245 which
currently is an issue when using plymouth in conjunction with
systemd. Ray promised to look into this every day now ;-)
7. ConsoleKit logging
These should become unit files like any other, however marked for use in
early boot or late shutdown. I'll prep something and file bugs.
8. system-setup-keyboard
This should become a normal unit file, though ordered to be executed
before X/prefdm. I'll prep something and file bugs.
9. readahead
I have some ideas on this, but this isn't fixed yet. This is not
finished yet. But then again, it's not really something that makes the
system unusable, is it? ;-)
Obviously, most of these are handled now, but I would suspect there
are
still some gaps.
Yepp, indeed.
The only other package that installs something in /etc/init i know if is
vpnc. Is anybody aware of any other packages that need some replacement
script? Hands up!
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:16 p.m.
On Wed, 2010-07-14 at 22:09 +0200, Lennart Poettering wrote:
> 6. plymouth interactions
There's https://bugzilla.redhat.com/show_bug.cgi?id=614245 which
currently is an issue when using plymouth in conjunction with
systemd. Ray promised to look into this every day now ;-)
Plymouth is the default, so if you make systemd the default, almost
everyone is going to be using plymouth in conjunction with systemd. If
that's currently broken, I don't really think it makes sense to flip the
switch on systemd.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:26 p.m.
On Wed, 14.07.10 13:16, Adam Williamson (awilliam(a)redhat.com) wrote:
On Wed, 2010-07-14 at 22:09 +0200, Lennart Poettering wrote:
> > 6. plymouth interactions
>
> There's https://bugzilla.redhat.com/show_bug.cgi?id=614245 which
> currently is an issue when using plymouth in conjunction with
> systemd. Ray promised to look into this every day now ;-)
Plymouth is the default, so if you make systemd the default, almost
everyone is going to be using plymouth in conjunction with systemd. If
that's currently broken, I don't really think it makes sense to flip the
switch on systemd.
Well, it's not as broken that your system won't boot up. All that
happens is that you will get a text bootup instead of a graphical
one. Not a big deal. But yes, this should be fixed. And it is probably
even very easy to fix it. But nothing that should stop us from flipping
the switch now.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:30 p.m.
On Wed, 2010-07-14 at 22:26 +0200, Lennart Poettering wrote:
On Wed, 14.07.10 13:16, Adam Williamson (awilliam(a)redhat.com) wrote:
>
> On Wed, 2010-07-14 at 22:09 +0200, Lennart Poettering wrote:
>
> > > 6. plymouth interactions
> >
> > There's https://bugzilla.redhat.com/show_bug.cgi?id=614245 which
> > currently is an issue when using plymouth in conjunction with
> > systemd. Ray promised to look into this every day now ;-)
>
> Plymouth is the default, so if you make systemd the default, almost
> everyone is going to be using plymouth in conjunction with systemd. If
> that's currently broken, I don't really think it makes sense to flip the
> switch on systemd.
Well, it's not as broken that your system won't boot up. All that
happens is that you will get a text bootup instead of a graphical
one. Not a big deal. But yes, this should be fixed. And it is probably
even very easy to fix it. But nothing that should stop us from flipping
the switch now.
Ah, OK, that seems alright then.
Did you see the post a while back from someone who tried systemd and
found it wouldn't boot their system? Just curious. I will try this
myself later today.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:08 p.m.
On Wed, 14.07.10 13:30, Adam Williamson (awilliam(a)redhat.com) wrote:
On Wed, 2010-07-14 at 22:26 +0200, Lennart Poettering wrote:
> On Wed, 14.07.10 13:16, Adam Williamson (awilliam(a)redhat.com) wrote:
>
> >
> > On Wed, 2010-07-14 at 22:09 +0200, Lennart Poettering wrote:
> >
> > > > 6. plymouth interactions
> > >
> > > There's https://bugzilla.redhat.com/show_bug.cgi?id=614245 which
> > > currently is an issue when using plymouth in conjunction with
> > > systemd. Ray promised to look into this every day now ;-)
> >
> > Plymouth is the default, so if you make systemd the default, almost
> > everyone is going to be using plymouth in conjunction with systemd. If
> > that's currently broken, I don't really think it makes sense to flip
the
> > switch on systemd.
>
> Well, it's not as broken that your system won't boot up. All that
> happens is that you will get a text bootup instead of a graphical
> one. Not a big deal. But yes, this should be fixed. And it is probably
> even very easy to fix it. But nothing that should stop us from flipping
> the switch now.
Ah, OK, that seems alright then.
Did you see the post a while back from someone who tried systemd and
found it wouldn't boot their system? Just curious. I will try this
myself later today.
I think I have responded to all mails and bugzilla bugs. Or have I
missed something?
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:22 p.m.
On Wed, 2010-07-14 at 23:08 +0200, Lennart Poettering wrote:
> Did you see the post a while back from someone who tried systemd
and
> found it wouldn't boot their system? Just curious. I will try this
> myself later today.
I think I have responded to all mails and bugzilla bugs. Or have I
missed something?
Nope, it was me who missed it, actually - it's the SELinux problem -
https://bugzilla.redhat.com/show_bug.cgi?id=614574 . (Again, I'd note
that having SELinux enabled is the default, so if systemd doesn't boot
with SELinux enabled, we shouldn't switch to it until that's fixed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:27 p.m.
On Wed, 14.07.10 14:22, Adam Williamson (awilliam(a)redhat.com) wrote:
On Wed, 2010-07-14 at 23:08 +0200, Lennart Poettering wrote:
> > Did you see the post a while back from someone who tried systemd and
> > found it wouldn't boot their system? Just curious. I will try this
> > myself later today.
>
> I think I have responded to all mails and bugzilla bugs. Or have I
> missed something?
Nope, it was me who missed it, actually - it's the SELinux problem -
https://bugzilla.redhat.com/show_bug.cgi?id=614574 . (Again, I'd note
that having SELinux enabled is the default, so if systemd doesn't boot
with SELinux enabled, we shouldn't switch to it until that's fixed.
That is probably true.
Daniel, please please please can you look into this?
Thanks a lot!
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:26 p.m.
On Wed, 2010-07-14 at 13:01 -0400, Bill Nottingham wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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.)
> > 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.
I'm not sure if this is good systemd syntax, but for mkdir you'd want
something like:
ExecStartPre=-/bin/mkdir -p -Z $(matchpathcon -n /var/run/foo) /var/run/foo
...but I think "install" does the right thing, so if we know /usr exists
it could be:
ExecStartPre=-/usr/bin/install /var/run/foo
12:32 p.m.
Once upon a time, James Antill <james(a)fedoraproject.org> said:
...but I think "install" does the right thing, so if we
know /usr exists
it could be:
ExecStartPre=-/usr/bin/install /var/run/foo
I don't think install sets context by default, but in any case, you'd
need a -d in there to create a directory.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:47 p.m.
On 07/14/2010 01:01 PM, Bill Nottingham wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> 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.)
>> 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
Not sure this works, but this would be preferable.
ExecStartPre=-"/bin/mkdir -p /var/run/foo; restorecon /var/run/foo"
But I can write policy to make the tools do apps do the right think and
label the directory correctly, with no hard coding.
myapp_t creating a directory in var_run_t will be labeled
myapp_var_run_t. I would just need to go through all the policy that
uses var_run_t directories and make sure it has this rule.
1:19 p.m.
On Wed, 14.07.10 13:47, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> Hardcoding foo_t is bad if they ever switch policy (MLS, etc.).
But
> it is an option.
>
> Bill
Not sure this works, but this would be preferable.
ExecStartPre=-"/bin/mkdir -p /var/run/foo; restorecon /var/run/foo"
Yes this would work, though in a different syntax:
ExecStartPre=-/bin/mkdir -p /var/run/foo ; -/sbin/restorecon /var/run/foo
(The initial - btw means that the exit code of the command is ignored)
But I can write policy to make the tools do apps do the right think
and
label the directory correctly, with no hard coding.
myapp_t creating a directory in var_run_t will be labeled
myapp_var_run_t. I would just need to go through all the policy that
uses var_run_t directories and make sure it has this rule.
Hmm, if you would be willing to do that, then it would be great to find
somebody who fixed the .specs and makes a list of packages whose selinux
policy needs fixing. Anyone? Rahul you should vague interest on IRC?
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:24 p.m.
On 07/14/2010 02:19 PM, Lennart Poettering wrote:
On Wed, 14.07.10 13:47, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
>> Hardcoding foo_t is bad if they ever switch policy (MLS, etc.). But
>> it is an option.
>>
>> Bill
> Not sure this works, but this would be preferable.
> ExecStartPre=-"/bin/mkdir -p /var/run/foo; restorecon /var/run/foo"
Yes this would work, though in a different syntax:
ExecStartPre=-/bin/mkdir -p /var/run/foo ; -/sbin/restorecon /var/run/foo
(The initial - btw means that the exit code of the command is ignored)
> But I can write policy to make the tools do apps do the right think and
> label the directory correctly, with no hard coding.
>
> myapp_t creating a directory in var_run_t will be labeled
> myapp_var_run_t. I would just need to go through all the policy that
> uses var_run_t directories and make sure it has this rule.
Hmm, if you would be willing to do that, then it would be great to find
somebody who fixed the .specs and makes a list of packages whose selinux
policy needs fixing. Anyone? Rahul you should vague interest on IRC?
Lennart
What is the big benefit of changing to tmpfs for /var/run?
2:20 p.m.
On Wed, 14.07.10 14:24, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
>> myapp_t creating a directory in var_run_t will be labeled
>> myapp_var_run_t. I would just need to go through all the policy that
>> uses var_run_t directories and make sure it has this rule.
>
> Hmm, if you would be willing to do that, then it would be great to find
> somebody who fixed the .specs and makes a list of packages whose selinux
> policy needs fixing. Anyone? Rahul you should vague interest on IRC?
>
> Lennart
>
What is the big benefit of changing to tmpfs for /var/run?
Well, various little things:
The reboot cleanup of those dirs will become unnecessary and automatic.
Socket accesses won't put pressure on the HDD due to atime updates.
Security reg. left-over files
Stateless bootup
Multi-instance root fs with r/o mounts.
And stuff like this. And of course this is just cleaner this way, since
the files in /var/run and /var/lock are runtime objects that are used
for synchronization and establishment of communication channels
only. They happen to live in the file system namespace because that is
how Unix works, but there is really no point at all to ever write them
to disk.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:23 p.m.
On 07/14/2010 03:20 PM, Lennart Poettering wrote:
On Wed, 14.07.10 14:24, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
>>> myapp_t creating a directory in var_run_t will be labeled
>>> myapp_var_run_t. I would just need to go through all the policy that
>>> uses var_run_t directories and make sure it has this rule.
>>
>> Hmm, if you would be willing to do that, then it would be great to find
>> somebody who fixed the .specs and makes a list of packages whose selinux
>> policy needs fixing. Anyone? Rahul you should vague interest on IRC?
>>
>> Lennart
>>
> What is the big benefit of changing to tmpfs for /var/run?
Well, various little things:
The reboot cleanup of those dirs will become unnecessary and automatic.
Socket accesses won't put pressure on the HDD due to atime updates.
Security reg. left-over files
Stateless bootup
Multi-instance root fs with r/o mounts.
And stuff like this. And of course this is just cleaner this way, since
the files in /var/run and /var/lock are runtime objects that are used
for synchronization and establishment of communication channels
only. They happen to live in the file system namespace because that is
how Unix works, but there is really no point at all to ever write them
to disk.
Lennart
Ok that is what I thought, I was just wondering if there was some
magical boot speedup. I also run with /tmp as a tmpfs for a lot of the
same reasons.
2:45 p.m.
On Wed, 14.07.10 15:23, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> And stuff like this. And of course this is just cleaner this
way, since
> the files in /var/run and /var/lock are runtime objects that are used
> for synchronization and establishment of communication channels
> only. They happen to live in the file system namespace because that is
> how Unix works, but there is really no point at all to ever write them
> to disk.
>
> Lennart
>
Ok that is what I thought, I was just wondering if there was some
magical boot speedup. I also run with /tmp as a tmpfs for a lot of the
same reasons.
Well, there might be some speed ups, because we never have to spawn a
process for rm -rf on the contents of /var/run and /var/lock. But those
are certainly more in the range of "neglible" than in the range of
"magical". ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:31 p.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
Yes this would work, though in a different syntax:
ExecStartPre=-/bin/mkdir -p /var/run/foo ; -/sbin/restorecon /var/run/foo
(The initial - btw means that the exit code of the command is ignored)
Why would you ignore the exit code? If you can't make the directory and
set the context, you shouldn't start the service.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:54 p.m.
On Wed, 14.07.10 13:31, Chris Adams (cmadams(a)hiwaay.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
> Yes this would work, though in a different syntax:
>
> ExecStartPre=-/bin/mkdir -p /var/run/foo ; -/sbin/restorecon /var/run/foo
>
> (The initial - btw means that the exit code of the command is ignored)
Why would you ignore the exit code? If you can't make the directory and
set the context, you shouldn't start the service.
Well, dunno, maybe if SELinux is disabled via selinux=0 restorcon fails?
And we don't want that? Dunno?
Generally I think it is a good idea to ignore errors like this if they
are clearly caught by later commands, simply for robustness
reasons. i.e. if the command really fails to label the dir properly,
then the daemon won't be able to access the dir and will then terminate
with an error.
But well, this may of course be left to the maintainers, what they
prefer. I have no strong opinions on this.
The default is of course to check all return values, i.e. you have to
explicitly prefix the commands with "-" to ignore them.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:03 p.m.
On 07/14/2010 02:54 PM, Lennart Poettering wrote:
On Wed, 14.07.10 13:31, Chris Adams (cmadams(a)hiwaay.net) wrote:
>
> Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
>> Yes this would work, though in a different syntax:
>>
>> ExecStartPre=-/bin/mkdir -p /var/run/foo ; -/sbin/restorecon /var/run/foo
>>
>> (The initial - btw means that the exit code of the command is ignored)
>
> Why would you ignore the exit code? If you can't make the directory and
> set the context, you shouldn't start the service.
Well, dunno, maybe if SELinux is disabled via selinux=0 restorcon fails?
And we don't want that? Dunno?
Generally I think it is a good idea to ignore errors like this if they
are clearly caught by later commands, simply for robustness
reasons. i.e. if the command really fails to label the dir properly,
then the daemon won't be able to access the dir and will then terminate
with an error.
But well, this may of course be left to the maintainers, what they
prefer. I have no strong opinions on this.
The default is of course to check all return values, i.e. you have to
explicitly prefix the commands with "-" to ignore them.
Lennart
BTW: restorecon exits silently if SELinux is disabled.
6:47 a.m.
On Wed, Jul 14, 2010 at 08:54:13PM +0200, Lennart Poettering wrote:
Generally I think it is a good idea to ignore errors like this if
they
are clearly caught by later commands, simply for robustness
reasons. i.e. if the command really fails to label the dir properly,
then the daemon won't be able to access the dir and will then terminate
with an error.
Is it ensured that a wrong label will only decrease access to the dir?
If not, then the label could still allow the daemon and something
unwanted to access the dir.
Regards
Till
7:39 a.m.
On 07/15/2010 07:47 AM, Till Maas wrote:
On Wed, Jul 14, 2010 at 08:54:13PM +0200, Lennart Poettering wrote:
> Generally I think it is a good idea to ignore errors like this if they
> are clearly caught by later commands, simply for robustness
> reasons. i.e. if the command really fails to label the dir properly,
> then the daemon won't be able to access the dir and will then terminate
> with an error.
Is it ensured that a wrong label will only decrease access to the dir?
If not, then the label could still allow the daemon and something
unwanted to access the dir.
Regards
Till
Well the wrong label would be var_run_t, which most confined domains
should not be allowed to read/write. If they are allowed to do this, it
is a bug. A confined domain that is allowed to write to /var/run could
create a directory in /var/run with the wrong label, creating a denial
of service.
For example,
hacked_app1 running as app1_t is allowed to created app1_var_run_t under
/var/run. It could create /var/run/app2 directory with the label
app1_var_run_t, when app2 (app2_t) starts it will try to write to
/var/run/app2 and be denied do to the bad label.
4:32 p.m.
ons 2010-07-14 klockan 20:54 +0200 skrev Lennart Poettering:
On Wed, 14.07.10 13:31, Chris Adams (cmadams(a)hiwaay.net) wrote:
> Once upon a time, Lennart Poettering
<mzerqung(a)0pointer.de> said:
> > ExecStartPre=-/bin/mkdir -p /var/run/foo ;
-/sbin/restorecon /var/run/foo
> Why would you ignore the exit code? If you can't make the
directory and
> set the context, you shouldn't start the service.
Well, dunno, maybe if SELinux is disabled via selinux=0 restorcon fails?
Nah, please don't hide errors like that. It just makes things harder to
debug.
It could be done properly in a shell command but ExecStartPre probably
doesn't take a shell command, just arguments for exec(), so you'd have
to do "ExecStartPre=bash -c 'blahblah....'". Anyway, we're trying
to
avoid starting a shell for every daemon.
The solution is to rewrite it in C code and have a "RunDir=/var/run/foo"
option in the unit file which creates the directory and calls restorecon
if necessary. For complicated cases where a shell command really is
needed you can use the bash -c trick or put the command in a shell
script file and just specify
"ExecStartPre=/usr/share/foo/daemon-startpre.sh".
The default is of course to check all return values, i.e. you have
to
explicitly prefix the commands with "-" to ignore them.
Is this feature really necessary? I think it would be best to avoid
using it...
/Alexander
4:58 p.m.
On Thu, 15.07.10 23:32, Alexander Boström (abo(a)root.snowtree.se) wrote:
> > Why would you ignore the exit code? If you can't make
the directory and
> > set the context, you shouldn't start the service.
>
> Well, dunno, maybe if SELinux is disabled via selinux=0 restorcon fails?
Nah, please don't hide errors like that. It just makes things harder to
debug.
Oh, we just ignore them for the sake of control flow, we do record them
for each each command we exectute and make them easily accessible in via
"systemctl status foo.service". i.e. i think we are well advised often
to let those errors go through will still keeping track of them
> The default is of course to check all return values, i.e. you
have to
> explicitly prefix the commands with "-" to ignore them.
Is this feature really necessary? I think it would be best to avoid
using it...
It is actually a very recent feature we added. The reason was basically
that we want to invoke 'plymouth' to disable the splash screen when
showing the emergency or rescue prompt. however, if the system was
not booted up with plymouth enabled that command will fail, and that's
completely fine.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:53 p.m.
On Wed, 14.07.10 20:19, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
Hmm, if you would be willing to do that, then it would be great to
find
somebody who fixed the .specs and makes a list of packages whose selinux
policy needs fixing. Anyone? Rahul you should vague interest on IRC?
One addition: The Suse volks have an rpmlint check for /var/run and
/var/lock, to ensure the appropriate %ghost.
We should have that too, would certainly help to track down misbheving
daemons.
Anyone wants to look into this?
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:43 a.m.
Bill Nottingham <notting(a)redhat.com> writes:
I suspect the biggest issue here is confined daemons, as they may
not have permissions to create their own directories in /var/run
is this really an issue? upstart (and systemd probably too) work best
with non forking daemons so that the pidfile hack is not needed anymore.
Enrico
9:49 a.m.
On Thu, 15.07.10 15:43, Enrico Scholz (enrico.scholz(a)informatik.tu-chemnitz.de) wrote:
Bill Nottingham <notting(a)redhat.com> writes:
> I suspect the biggest issue here is confined daemons, as they may
> not have permissions to create their own directories in /var/run
is this really an issue? upstart (and systemd probably too) work best
with non forking daemons so that the pidfile hack is not needed anymore.
systemd doesn't care about PID files. If daemons still write them it's
fine, but they don't matter.
I think what's more interesting here is socket creation in
/var/run. i.e. it's the primarily used place to put client communication
sockets of system daemons.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:45 a.m.
On Thu, 15 Jul 2010 16:49:59 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 15.07.10 15:43, Enrico Scholz
(enrico.scholz(a)informatik.tu-chemnitz.de) wrote:
>
> Bill Nottingham <notting(a)redhat.com> writes:
>
> > I suspect the biggest issue here is confined daemons, as they may
> > not have permissions to create their own directories in /var/run
>
> is this really an issue? upstart (and systemd probably too) work
> best with non forking daemons so that the pidfile hack is not
> needed anymore.
systemd doesn't care about PID files. If daemons still write them it's
fine, but they don't matter.
You are completely disregarding the case an admin starts daemons
manually. Often pid files are checked so that an admin starting a
daemon manually does not make a mess, if the daemon was already running.
I think what's more interesting here is socket creation in
/var/run. i.e. it's the primarily used place to put client
communication sockets of system daemons.
Yes, this is indeed the case, there are daemons that create sockets
in /var/run/<something> and they need to be abel to create those
sockets with the correct permissions and selinux labels
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:40 p.m.
On Thu, 15.07.10 11:45, Simo Sorce (ssorce(a)redhat.com) wrote:
> > is this really an issue? upstart (and systemd probably
too) work
> > best with non forking daemons so that the pidfile hack is not
> > needed anymore.
>
> systemd doesn't care about PID files. If daemons still write them it's
> fine, but they don't matter.
You are completely disregarding the case an admin starts daemons
manually. Often pid files are checked so that an admin starting a
daemon manually does not make a mess, if the daemon was already
running.
Well, if daemon writers still care about PID files they can do so. I am
just saying that systemd doesn't care, and has the information anyway.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:07 p.m.
I've been trying to test systemd on my dev box but without success so
far. My system boots up and I get the usual GDM login screen and VTs
but I can't login. SSH fails as well. SSH gives me "Unable to get
valid context for jcollie" shows me the last login date and closes the
connection. I think I'm seeing a similar message on the console but
it flashes too quickly for me to be sure.
I haven't gone as far as removing upstart and installing
systemd-sysvinit yet. Is this my problem? I've just been adding
"init=/bin/systemd" to the kernel boot line to try out systemd. I'd
rather not brick this system so I thought that I'd check here to see
if I had missed anything before removing upstart.
--
Jeff Ollie
2:13 p.m.
On Wed, 14.07.10 14:07, Jeffrey Ollie (jeff(a)ocjtech.us) wrote:
I've been trying to test systemd on my dev box but without success so
far. My system boots up and I get the usual GDM login screen and VTs
but I can't login. SSH fails as well. SSH gives me "Unable to get
valid context for jcollie" shows me the last login date and closes the
connection. I think I'm seeing a similar message on the console but
it flashes too quickly for me to be sure.
Hmm, this smells a bit like policy problem. Could you try selinux=0 on
the kernel cmdline to figure out if that makes things work?
And please file a bug against systemd which I'll then reassign to
selinux should this really be the problem.
I haven't gone as far as removing upstart and installing
systemd-sysvinit yet. Is this my problem? I've just been adding
"init=/bin/systemd" to the kernel boot line to try out systemd. I'd
rather not brick this system so I thought that I'd check here to see
if I had missed anything before removing upstart.
Yes, init=/bin/systemd should be fine to use.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:02 p.m.
On Wed, Jul 14, 2010 at 2:13 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Wed, 14.07.10 14:07, Jeffrey Ollie (jeff(a)ocjtech.us) wrote:
>
> I've been trying to test systemd on my dev box but without success so
> far. My system boots up and I get the usual GDM login screen and VTs
> but I can't login. SSH fails as well. SSH gives me "Unable to get
> valid context for jcollie" shows me the last login date and closes the
> connection. I think I'm seeing a similar message on the console but
> it flashes too quickly for me to be sure.
Hmm, this smells a bit like policy problem. Could you try selinux=0 on
the kernel cmdline to figure out if that makes things work?
And please file a bug against systemd which I'll then reassign to
selinux should this really be the problem.
It looks like Bill Nottingham beat me to filing a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=614574
but at least with selinux in permissive mode I now have my rawhide
system booting up with systemd.
--
Jeff Ollie
8:32 a.m.
On 07/14/2010 05:02 PM, Jeffrey Ollie wrote:
On Wed, Jul 14, 2010 at 2:13 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> On Wed, 14.07.10 14:07, Jeffrey Ollie (jeff(a)ocjtech.us) wrote:
>
>>
>> I've been trying to test systemd on my dev box but without success so
>> far. My system boots up and I get the usual GDM login screen and VTs
>> but I can't login. SSH fails as well. SSH gives me "Unable to get
>> valid context for jcollie" shows me the last login date and closes the
>> connection. I think I'm seeing a similar message on the console but
>> it flashes too quickly for me to be sure.
>
> Hmm, this smells a bit like policy problem. Could you try selinux=0 on
> the kernel cmdline to figure out if that makes things work?
>
> And please file a bug against systemd which I'll then reassign to
> selinux should this really be the problem.
It looks like Bill Nottingham beat me to filing a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=614574
but at least with selinux in permissive mode I now have my rawhide
system booting up with systemd.
I thought I had checked it in, but I was leaving on Vacation and dropped
the ball.
Fixed in selinux-policy-3.8.7-1.fc14.noarch
chcon -t init_exec_t /bin/systemd
Will also fix it so you can boot in enforcing mode. I am changing my
laptop to boot full time systemd to see what other gotchas.
The biggest SELinux problem will be as we go to systemd impersonating
other services. For example, if systemd was going to start mysql by
listening on /var/run/mysql.socket. SELinux would expect the
/var/run/mysql.socket to be labeled mysqld_var_run_t. Currently if
systemd creates this socket it would be labeled init_var_run_t.
Secondly if httpd tried to connect to this socket, SELinux enforces the
rule that
httpd_t can read/write a sock_file labeled mysqld_var_run_t and
connectto services labeled mysqld_t.
SELinux will deny httpd_t read/write sock_files labeled init_var_run_t
and will not allow it to connectto processes labeled init_t.
The best solution to this would be to get sysstemd process that is
creating the sock_file and listening to impersonate mysqld_t.
fork()
setexec("system_u:system_r:mysqld_t:s0")
create_sock_file()
listen()
accept()
exec mysqld
9:48 a.m.
On Thu, 15.07.10 09:32, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
I thought I had checked it in, but I was leaving on Vacation and
dropped
the ball.
Fixed in selinux-policy-3.8.7-1.fc14.noarch
I'll bump up the dependency.
chcon -t init_exec_t /bin/systemd
Will also fix it so you can boot in enforcing mode. I am changing my
laptop to boot full time systemd to see what other gotchas.
Thanks a lot. Much appreciated!
The best solution to this would be to get sysstemd process that is
creating the sock_file and listening to impersonate mysqld_t.
fork()
setexec("system_u:system_r:mysqld_t:s0")
create_sock_file()
listen()
accept()
exec mysqld
Hmm, but that's not really how it works. i.e. we first create all
sockets, and then when a connection comes in (or something else happens)
we fork and exec. I don't know the selinux APIS that well but something
like this would be more along what I'd want:
create_sock_file("/var/run/foo", "...:foo_t:...");
create_sock_file("/var/run/bar", "...:bar_t:...");
create_sock_file("/var/run/waldo", "...:waldo_t:...");
.....
....
accept() -- if systemd is configured to accept
fork()
exec()
....
Is this doable with selinux? i.e. label sockets we create one-by-one
without necessarily forking off anything like that?
How has inetd been handled in this respect so far?
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:25 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
Heya,
as many of you probably know systemd got accepted as feature for F-14 by
FESCO a few weeks back.
Congratulations.
Just a question: Why isn't it /sbin/systemd, /sbin/systemctl,
/sbin/systemd-notify, /usr/sbin/systemd-cgls? This definitely isn't
"normal-user" stuff (yes, I know that /sbin and /usr/sbin are on the
default $PATH now, but still).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
3:52 p.m.
On Wed, 14.07.10 16:25, Horst H. von Brand (vonbrand(a)inf.utfsm.cl) wrote:
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> Heya,
>
> as many of you probably know systemd got accepted as feature for F-14 by
> FESCO a few weeks back.
Congratulations.
Just a question: Why isn't it /sbin/systemd, /sbin/systemctl,
/sbin/systemd-notify, /usr/sbin/systemd-cgls? This definitely isn't
"normal-user" stuff (yes, I know that /sbin and /usr/sbin are on the
default $PATH now, but still).
In the long run systemd should also augment gnome-session in a way:
i.e. you would have one systemd running for the system and then one
for each user/session. The details of this have not been completely
hashed out but big parts of this are actually working already. This is
very similar to how MacOS launchd does things.
Or in other words: system and session managers do very very similar
jobs, and we are planning to use the same codebase for them, like other
OSes already do it. This is not on the plate for F14, but it will
come eventually.
Or in even other words: you can run those tools as user just fine,
including /bin/systemd itself. If the PAM module of systemd is activated
(https://bugzilla.redhat.com/show_bug.cgi?id=612712) then you should
have all the right perms to run systemd as a user. It's kinda neat
actually, since the cgroup hierarchy of the user then simply becomes a
subhierarchy of the main tree. i.e. "tree -d /cgroup/systemd" becomes
even more superduper sexy... ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:36 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
as many of you probably know systemd got accepted as feature for F-14
by
FESCO a few weeks back.
Perhaps I'm being unusually dense, but...
How do I go ahead and switch over to check this out? Spell it out for a
somewhat moronic rawhide user...
How do I get back if the result explodes in my face?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
4:21 p.m.
On Wed, 14.07.10 16:36, Horst H. von Brand (vonbrand(a)inf.utfsm.cl) wrote:
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> as many of you probably know systemd got accepted as feature for F-14 by
> FESCO a few weeks back.
Perhaps I'm being unusually dense, but...
How do I go ahead and switch over to check this out? Spell it out for a
somewhat moronic rawhide user...
How do I get back if the result explodes in my face?
You can install systemd from rawhide. This should give you everything
you need. Then, to boot into systemd pass "init=/bin/systemd" on the
kernel command line. To change back to upstart just boot normally.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
So, here's my call for help, in order to make this all a big
success:
So, I've actually played with this now, instead of just asking questions
and operating on knowledge from the initial announcement.
I must admit... at first glance, I'm not the hugest fan, simply because of the
interface it presents to the admin.
1) Jargon/Renaming of concepts
systemd is heavily invested in jargon specific to systemd. For example,
the main unit of configuration is:
- sysv: service file
- upstart: job file
- systemd: unit file
'service' and 'job' are fairly well-understood (and similar) concepts.
'unit' has no overall meaning... it's just a generic word.
Even if you go to explore that, it states:
A unit configuration file encodes information about a service, a socket, a
device, a mount point, an automount point, a swap file or partition, a
start-up target, a file system path or a timer controlled and supervised by
systemd(1).
I do realize that it's essentially operating as an abstract class here, but
that's a complicated distinction to make, as the docs are essentially
telling the admin that an unit can be anything or nothing.
Similarly, the redefinition of the concept of 'runlevel' as 'target'
(well,
amalgamations of targets) is replacing a concrete concept with a generic word, and
replacing 'enabled/disabled' with 'active/inactive' seems random.
2) Complexity
While there's a certain level of complexity to doing complex things, systemd
seems to go overboard.
Example 1:
# of jobs/events/whatever files shipped by default (not counting SysV services):
- sysv: 1
- upstart: 19
- systemd: 62
And in this case, we're not using systemd for much natively. It's a lot of
data to sort through if you're trying to just figure out what's going on,
and if you're not clear with all of the systemd concepts, a lot of it looks
strange, such as:
- why does everything need *both* mount and automount files?
- if swap, local-fs, etc. are all bookkept internally, what's the point of
having a target file?
- why does setting of Alias *also* require a symlink? (It may not, but
local vs. rc.local seems to imply it might.)
I do wonder if perhaps this could be simplified by:
- Keeping services and targets separate on the filesystem
- Merging services and sockets into the same file where appropriate... given
that they're tied together inherently anyway, I'm not sure why they
need to be separate.
Example 2:
I want to configure the number of gettys on the system.
- sysvinit
Edit /etc/inittab. Add/delete some obvious lines.
- upstart
Edit /etc/sysconfig/init (discoverable by looking in /etc/init at the
start-ttys.conf file, which is documented in inittab if people look there
first.)
- systemd
Use systemd-install to add or delete the
/etc/systemd/system/getty.target.wants/getty(a)tty4.service (or whatever)
symlink.
This requires knowledge of:
- what systemd targets are
- what the target name is that starts gettys
- what 'wants' means in this systemd context
- the proper systemd interface to install/remove commands
At least, if it doesn't *require* that knowledge, it *exposes* you to that
complexity in terms of the path names, the random '@' which I'm sure has
meaning, but isn't obvious, etc. (And, as neat trick, you can't find
these getty services via systemctl, as far as I can tell.)
...
In any case, that's just a first impression. I'll play with it and try and
wrap my head around it some more. But I can't help but think that systemd
presents as much more complex/baroque than it needs to.
Bill
6:29 p.m.
On Wed, 14.07.10 18:00, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> So, here's my call for help, in order to make this all a big success:
So, I've actually played with this now, instead of just asking questions
and operating on knowledge from the initial announcement.
I must admit... at first glance, I'm not the hugest fan, simply because of the
interface it presents to the admin.
1) Jargon/Renaming of concepts
systemd is heavily invested in jargon specific to systemd. For example,
the main unit of configuration is:
- sysv: service file
- upstart: job file
- systemd: unit file
'service' and 'job' are fairly well-understood (and similar) concepts.
'unit' has no overall meaning... it's just a generic word.
Well, the word "job" was introduced by upstart and was previously not
used anywhere. And it also introduced "event" and "goal".
systemd uses "job", and introduces "unit". Wow. New software uses
different terms.
And that comparison is not even fair. The thing that was called service
file in sysv is called service file in systemd too (it even has .service
is suffix, how obvious!). However since in contrast to sysv we not only
maintain services, but also mount points, devices, yadda yadda, we came
up with a more generic term for all these kinds of things, where
"service" is one kind of, and that term is "unit". How else would you
have done this?
If you want to blame somebody, blame upstart for calling what was
previously called a service a job. In systemd we just went back to the
roots in this area and call it services again, and then added one level of
abstraction on top of that, because our focus is not only daemons but a
lot more.
Similarly, the redefinition of the concept of 'runlevel' as
'target' (well,
amalgamations of targets) is replacing a concrete concept with a generic word, and
replacing 'enabled/disabled' with 'active/inactive' seems random.
Well, targets are supersets of runlevels. That's why there is
"runlevel2.target".
The chkconfig man page uses the term enable/disable the same way
as we do:
enable/disable is used to say whether a service or other unit shall be
started during boot.
active/inactive is just a more generic term for started/stopped, simply
because you cannot really say a device is "started", can you?
When you speak of services you start and stop them. When you speak of
the more generic form of units (which can be any of service, socket,
device, mount point whatever), then you activate or deactivate them.
We basically took the terms that have been used in SysV for maintaining
daemons, (i.e. you "start" or "stop" entities called
"service"), and
reuse them in systemd for daemons. And for the more generic units we have
generalized this. (i.e. you "activate" or "deactivate" entities
called
"units").
Or to explain this with a table, showing you what verbs most people
would probably use for four kinds (of the ten) of objects that are
managed by systemd:
Services: Started | Stopped
Socket: Bound | Unbound
Devices: Plugged In | Plugged Out
Mounts: Mounted | Unmounted
And we noticed that, and when we looked for more abstract terms that
could cover all three cases, we cam up with this:
Units: Active | Inactive
And to be honest, I find this very understandable. Maybe not obvious,
but figuring this out should not require a nobel prize. And this is
actually documented in the man page, though in terser words, it's right
the first paragraph under "Concepts" in the systemd man page:
"systemd provides a dependency system between various entities called
'units'. Units encapsulate various objects that are relevant for system
boot-up and maintainance. The majority of units are configured in unit
configuration files, whose syntax and basic set of options is described
in systemd.unit(5), however some are created automatically from other
configuration or dynamically from system state. Units may be active
(meaning started, bound, plugged in, ... depending on the unit type), or
inactive (meaning stopped, unbound, unplugged, ...), as well as in the
process of being activated or deactivated, i.e. between the two states."
2) Complexity
While there's a certain level of complexity to doing complex things, systemd
seems to go overboard.
Does it? But it also does a lot more...
Example 1:
# of jobs/events/whatever files shipped by default (not counting SysV services):
- sysv: 1
Oh, that's really not fair... SysV only covers a tiny fraction of what
Upstart cover or even systemd cover.
- upstart: 19
- systemd: 62
Well, but the systemd unit files are trivial to understand. If you
honestly claim that the systemd unit files are harder to understand than
shell monsters you find ind /etc/init.d then I'll go and shoot myself.
Look at the contents of those files. See how tiny they are!
If you prefer few huge script monsters over a number of tiny
configuration fragments, then I guess this is a matter of taste.
And in this case, we're not using systemd for much natively.
It's a lot of
data to sort through if you're trying to just figure out what's going on,
and if you're not clear with all of the systemd concepts, a lot of it looks
strange, such as:
- why does everything need *both* mount and automount files?
It doesn't. Dude, this is so not fair.
Systemd has all kinds of magic tricks for you. For example we set up
automount points for various directories like /sys/kernel/security, or
/proc/sys/fs/binfmt_misc, /dev/hugepages and more. Only when people
access them the backing kernel modules will be loaded and the real fs
mounted. How awesome is that?
Note that by default we install those automount points only for kernel
virtual "API" file systems. Because it was an obvious choice. But if you
then compare that with Upstart then you should love systemd, because it
will establish all the filesystem hierachies that they are readily
accessible and that even without loading the kernel modules backing
them. How awesome is that, really? And Upstart doesn't have that.
Or in other words: that Upstart doesn't do automounting like this is a
limitation of Upstart, not a limitation of systemd.
BTW, I think I mentioned this a couple of times, but it would be awesome
to read the blog story I wrote... It explains the logic behind the
automount... http://0pointer.de/blog/projects/systemd.html
So, to say this explicitly: NO YOU DON'T NEED BOTH MOUNT AND AUTOMOUNT
FILES! You don't even mount files, and certainly not automount
files. You can list all mounts you want in /etc/fstab and systemd will
honour them. And then if you want to create an automount point you can
*optionally* create an automount unit for it as well. But that's
OPTIONAL! And please don't blame me that systemd has more features than
sysvinit or upstart.
And btw, you can even create automount points via
comment=systemd.automount as mount option in /etc/fstab. You don't even
have to place an .automount file anywhere. For the API file systems
however we decided to do just that because it is way easier to just drop
those additional files in there than it is to patch /etc/fstab.
- if swap, local-fs, etc. are all bookkept internally, what's the
point of
having a target file?
Well, it's called "compatiblity". Because we keep compat with existing
stuff we automatically populate swap.target, local-fs.target and
remote-fs.target with the data from /etc/fstab. How amazing is that? We
treat the existing configuration just as another source of configurationn
that is used alongside native configuration, and then make it appear as
if it was natively configured.
If you don't want /etc/fstab anymore you can also define native unit
files for swaps and mount points. Note sure that makes sense at this
time, but hey, I won't stop you.
- why does setting of Alias *also* require a symlink? (It may not,
but
local vs. rc.local seems to imply it might.)
Well, in systemd we only read files that are requested, for perfomance
reasons. if something or somebody requests "foo.service" we load that
file. And if we then find an alias configured in that file we install
that alias too. However, if somebody looks up things under the alias
first then he will only end up with the unit file if there's a symlink
for it.
And that' s actually a feature, not only in minimizing disk
accesses. i.e. postfix.service and sendmail.service could both have an
internally configured alias of mta.service, which makes them mutually
exclusive. And then, in the fs you could use the symlink to select which
of the two units is started when something or somebody requests
"mta.service". That way, if you have running either of them the mta dep
will be fulfilled. And if you have neither running then the symlink
decides which one is started.
I do wonder if perhaps this could be simplified by:
- Keeping services and targets separate on the filesystem
Well, we have 10 types of units. If you say every type should get its
own dir then the next guy will come and say "oh, my god, this
complexity, wouldn't one dir suffice?"
I think this is mostly a matter of taste.
- Merging services and sockets into the same file where
appropriate... given
that they're tied together inherently anyway, I'm not sure why they
need to be separate.
Well, they have different lifecycles and dependencies and can be started
and stopped independently.
Example: Service "dbus.service" wants to be started after
"syslog.service". The former is a socket-activated service (i.e. as in
current Rawhide), the latter is a not socket-activated (i.e. as in
current Rawhide). The dbus socket can be established very early, before
syslog is started, but dbus can only be started if syslog is actually
around and has established its socket itself. Establishing the dbus
socket early has numerous advantages, in particular since everybody can
then just go and use it (it's part if the whole idea of socket
activation).
That's why you want to have independent entities here for sockets and
services: they can be independently activated and when one eventually
triggers activation of the other that can even pull a completely
different slew of dependencies.
Also, there is not even a 1:1 relation between services and sockets. For
example, for ssh we probably should run one sshd instance per
connection. This results in units like these appearing in the system:
sshd.socket
sshd@2-127.0.0.1:22-127.0.0.1:46660.service
sshd@3-172.31.0.50:22-172.31.0.4:43289.service
"sshd.socket" is a unit for the socket. And the other two services are
instances of sshd, for two incoming connections. And those two instances
are even labelled after there connection credentials (i.e. IP addresses
local and remote, how awesome is that? the admin can kill those services
individually and by there name). i.e. sshd.socket triggered creation of
two .service units here.
Example 2:
I want to configure the number of gettys on the system.
- sysvinit
Edit /etc/inittab. Add/delete some obvious lines.
- upstart
Edit /etc/sysconfig/init (discoverable by looking in /etc/init at the
start-ttys.conf file, which is documented in inittab if people look there
first.)
- systemd
Use systemd-install to add or delete the
/etc/systemd/system/getty.target.wants/getty(a)tty4.service (or whatever)
symlink.
Well systemd-install will install the *suggested* configuration for you,
that's all. If you deviate from that you can just create or remove
symlinks as you wish.
I.e. to remove a tty from tty4:
$ rm /etc/systemd/system/gettys.target/wants/getty(a)tty4.service
To add one for tty9:
$ ln -sf /lib/systemd/getty@.service
/etc/systemd/system/gettys.target/wants/getty(a)tty9.service
And you can easily figure that out simply by duplicating what is already
there for the other ttys.
This requires knowledge of:
- what systemd targets are
- what the target name is that starts gettys
- what 'wants' means in this systemd context
- the proper systemd interface to install/remove commands
I think you are misunderstand what systemd-install is about. I have now
added an additional sentence to the man page that explains that
systemd-install is for the *suggested* installation only, and that you
are always welcome to deviate from that.
I have also made sure that attempts to use systemd-install like yours just
did result in a clean error message with suggestions what to do instead.
And also, if we ship an inittab that points people to creating those
symlinks your criticism would go away and things would be the same or
even simpler then with Upstart, right?
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:42 p.m.
On Thu, 2010-07-15 at 01:29 +0200, Lennart Poettering wrote:
[long comparsion elided...]
Or to explain this with a table, showing you what verbs most people
would probably use for four kinds (of the ten) of objects that are
managed by systemd:
Services: Started | Stopped
Socket: Bound | Unbound
Devices: Plugged In | Plugged Out
Mounts: Mounted | Unmounted
And we noticed that, and when we looked for more abstract terms that
could cover all three cases, we cam up with this:
Units: Active | Inactive
Hey Lennart, instead of going all defensive here, I think it would be
good to simply acknowledge that we are currently missing a 'friendly
introduction to systemd' targeting sysadmins (or even regular users).
The paragraph I cited above could be a nice start for a section in that
document.
Oh, that's really not fair... SysV only covers a tiny fraction of
what
Upstart cover or even systemd cover.
> - upstart: 19
> - systemd: 62
Well, but the systemd unit files are trivial to understand. If you
honestly claim that the systemd unit files are harder to understand than
shell monsters you find ind /etc/init.d then I'll go and shoot myself.
Look at the contents of those files. See how tiny they are!
Well, I have to agree with notting that the sheer number of them is
confusing, and if I look at how tiny they are, it makes me scratch my
head even more: e.g. dbus.target:
[Unit]
Description=D-Bus
Whats the point of all these empty targets ? Who are they good for ? My
understanding so far was that targets collect groups of units for pure
convenience, but this target does not collect anything...
7:37 p.m.
On Wed, 14.07.10 19:42, Matthias Clasen (mclasen(a)redhat.com) wrote:
On Thu, 2010-07-15 at 01:29 +0200, Lennart Poettering wrote:
[long comparsion elided...]
> Or to explain this with a table, showing you what verbs most people
> would probably use for four kinds (of the ten) of objects that are
> managed by systemd:
>
> Services: Started | Stopped
> Socket: Bound | Unbound
> Devices: Plugged In | Plugged Out
> Mounts: Mounted | Unmounted
>
> And we noticed that, and when we looked for more abstract terms that
> could cover all three cases, we cam up with this:
>
> Units: Active | Inactive
>
Hey Lennart, instead of going all defensive here, I think it would be
good to simply acknowledge that we are currently missing a 'friendly
introduction to systemd' targeting sysadmins (or even regular users).
The paragraph I cited above could be a nice start for a section in that
document.
I kinda hoped that the Concepts part in the man page would actually
cover that already to enough detail:
"systemd provides a dependency system between various entities
called "units". Units encapsulate various objects that are relevant
for system boot-up and maintainance. The majority of units are
configured in unit configuration files, whose syntax and basic set
of options is described in systemd.unit(5), however some are created
automatically from other configuration or dynamically from system
state. Units may be active (meaning started, bound, plugged in,
... depending on the unit type), or inactive (meaning stopped,
unbound, unplugged, ...), as well as in the process of being
activated or deactivated, i.e. between the two states. The following
unit types are available:"
And then there's a list of the 10 types.
It's actually right the first paragraph after the list of options. Not
sure how I can make this any more obvious to find.
http://0pointer.de/public/systemd-man/systemd.html
Well, I have to agree with notting that the sheer number of them is
confusing, and if I look at how tiny they are, it makes me scratch my
head even more: e.g. dbus.target:
[Unit]
Description=D-Bus
Whats the point of all these empty targets ? Who are they good for ? My
understanding so far was that targets collect groups of units for pure
convenience, but this target does not collect anything...
Well, those targets are suggested hook points for units, i.e. they tend
to have special semantics:
http://0pointer.de/public/systemd-man/systemd.special.html
And those target files only exist to make clear that they exist, and so
that they get a pretty description assigned.
Note that "systemctl list-units" will only show active and referenced
units. No unreferenced ones. Hence I find it really useful that the
admin can browse through /lib/systemd/system and /etc/systemd/system to
see what units exist he could start or enable or whatever. If we would
not expose all units we have in the file system it would be much harder
to discover them.
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:43 p.m.
On Thu, 2010-07-15 at 02:37 +0200, Lennart Poettering wrote:
It's actually right the first paragraph after the list of
options. Not
sure how I can make this any more obvious to find.
http://0pointer.de/public/systemd-man/systemd.html
No-one reads man pages any more, it's all about the wikis ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:38 p.m.
Stepping back, this is the situation I started with that led me to these
observations:
Incoming knowledge:
- Upstart and init experience
- A reading of the initial 'why I did systemd, and what it intends to
support' document
Testing methodology:
- Install it
- Boot it
- Poke around
Is this the best way to approach it? Probably not. But, realistically,
people are going to just try things and kick the tires before reading
manuals. It's human nature.
So, that's where I'm coming from. The idea was to determine how much
of its behavior, configuration, and user interface could be logically
intuited. Ideally, the administrator should not have to read the man
pages to figure out beforehand how the software works... the man pages
would be for reference.
Now, I realize that this software is still in the fairly early stages,
and I'm likely to hit warts. So some of this criticism may not be fair.
But I did/do feel that the learning curve I hit when trying this out was
higher than when going from sysv -> upstart. Perhaps this can be solved
with more guides/faqs.
Lennart Poettering (mzerqung(a)0pointer.de) said:
systemd uses "job", and introduces "unit". Wow.
New software uses
different terms.
And that comparison is not even fair. The thing that was called service
file in sysv is called service file in systemd too (it even has .service
is suffix, how obvious!). However since in contrast to sysv we not only
maintain services, but also mount points, devices, yadda yadda, we came
up with a more generic term for all these kinds of things, where
"service" is one kind of, and that term is "unit". How else would
you
have done this?
As stated below, I'd probably have separated them in the layout. Dumping
all services/mounts/sockets/etc. in one place seemed overkill.
The chkconfig man page uses the term enable/disable the same way
as we do:
enable/disable is used to say whether a service or other unit shall be
started during boot.
active/inactive is just a more generic term for started/stopped, simply
because you cannot really say a device is "started", can you?
I think some of this is just the tools being inconsistent in terminology.
Take systemctl:
- It has a LOAD column (which is always 'loaded', in observation)
- It says things like:
'78 live units listed. Pass --all to see dead units, too.'
when presumably, it should be talking active/inactive
- It has JOB column (which is always empty, in observation)
etc.
(re: 60-odd service files)
I think part of my confusion stems from (as we discussed on IRC) some
of the shipped units aren't wired up to anything that runs/starts something yet,
and would be to work with .service, etc. files that you're intending to push
into other packages.
Well, but the systemd unit files are trivial to understand. If you
honestly claim that the systemd unit files are harder to understand than
shell monsters you find ind /etc/init.d then I'll go and shoot myself.
They are not easier to understand *in isolation*. For example,
even though I may not understand it all, it's fairly easy to understand what
/etc/init.d/iptables' purpose in life is from reading it. I can't say
that about any of the 'special' task files, as they contain no data
in and of themselves. Honestly, it's probably better for them just
to be either:
- self-documenting and contain the relevant man page segment
- not exist, and only be documented in the man page (with the
understanding that certain targets/services/automounts are
'internal' to systemd.)
> - why does everything need *both* mount and automount files?
It doesn't. Dude, this is so not fair.
... all the shipped ones do. Perhaps I'm being obtuse, but it seems
a matter of design to me. I'm not seeing why we just don't have
Automount=yes (or OnDemand=yes, or whatever) in the .mount files, rather
than another separate file that requires a matching .mount file,
much like how bluetooth has 'StopWhenUnneeded'. While you describe below
the reasoning for separate entries for socket & service, I'm not seeing
an obvious reason for the separation here.
> - if swap, local-fs, etc. are all bookkept internally,
what's the point of
> having a target file?
Well, it's called "compatiblity". Because we keep compat with existing
stuff we automatically populate swap.target, local-fs.target and
remote-fs.target with the data from /etc/fstab. How amazing is that? We
treat the existing configuration just as another source of configurationn
that is used alongside native configuration, and then make it appear as
if it was natively configured.
Yes, that I understand. I'm just not understanding why the swap.target
*file* exists. I may be being overly picky, but if the 'meat' of the
file is only automatically determined by the daemon itself, I'm not
sure the file itself serves much purpose.
> - why does setting of Alias *also* require a symlink? (It may
not, but
> local vs. rc.local seems to imply it might.)
Well, in systemd we only read files that are requested, for perfomance
reasons. if something or somebody requests "foo.service" we load that
file. And if we then find an alias configured in that file we install
that alias too. However, if somebody looks up things under the alias
first then he will only end up with the unit file if there's a symlink
for it.
OK, I was missing a detail here - I was conflating alias with name. What I
was noticing was the local.service -> rc.local.service link in /lib/systemd.
This is actually just bookkeeping to make sure it overrides the /etc/init.d/
service, if I'm now reading this right. I wonder if there's a better way to
handle this case other than just creating more Name entries/symlinks (have
the daemon do this without the symlink?), but... *shrug*.
> I do wonder if perhaps this could be simplified by:
>
> - Keeping services and targets separate on the filesystem
Well, we have 10 types of units. If you say every type should get its
own dir then the next guy will come and say "oh, my god, this
complexity, wouldn't one dir suffice?"
I think this is mostly a matter of taste.
Yeah, likely. Although I think that targets may be different enough that
they qualify.
> - Merging services and sockets into the same file where
appropriate... given
> that they're tied together inherently anyway, I'm not sure why they
> need to be separate.
Well, they have different lifecycles and dependencies and can be started
and stopped independently.
Example: Service "dbus.service" wants to be started after
"syslog.service". The former is a socket-activated service (i.e. as in
current Rawhide), the latter is a not socket-activated (i.e. as in
current Rawhide). The dbus socket can be established very early, before
syslog is started, but dbus can only be started if syslog is actually
around and has established its socket itself. Establishing the dbus
socket early has numerous advantages, in particular since everybody can
then just go and use it (it's part if the whole idea of socket
activation).
That's why you want to have independent entities here for sockets and
services: they can be independently activated and when one eventually
triggers activation of the other that can even pull a completely
different slew of dependencies.
OK. My taste preference is to have that be configured in two sections
in one file rather than two separate-but-dependent files, but I can
also see the benefits of separation for consistency.
Also, there is not even a 1:1 relation between services and sockets.
For
example, for ssh we probably should run one sshd instance per
connection. This results in units like these appearing in the system:
sshd.socket
sshd@2-127.0.0.1:22-127.0.0.1:46660.service
sshd@3-172.31.0.50:22-172.31.0.4:43289.service
Sure, but those service entries wouldn't be files in the system (unless
you're planning to write them on demand somewhere...?)
> - systemd
>
> Use systemd-install to add or delete the
> /etc/systemd/system/getty.target.wants/getty(a)tty4.service (or whatever)
> symlink.
Well systemd-install will install the *suggested* configuration for you,
that's all.
If you deviate from that you can just create or remove
symlinks as you wish.
I.e. to remove a tty from tty4:
$ rm /etc/systemd/system/gettys.target/wants/getty(a)tty4.service
To add one for tty9:
$ ln -sf /lib/systemd/getty@.service
/etc/systemd/system/gettys.target/wants/getty(a)tty9.service
And you can easily figure that out simply by duplicating what is already
there for the other ttys.
Sure, but there's a lot of syntatical noise in the pathname that's
important (it needs to be under getty.target.wants, it needs to be of
that form), that to explain opens up a much bigger can of worms. I just
wonder if that sort of long path will lead to more people cut-and-pasting
than actually understanding why it's that way. (It's along the lines of
why I dislike things like 'dbus-send --system --print-reply \
--dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager \
org.freedesktop.ConsoleKit.Manager.CanRestart' - it feels that it's
more baroque than it needs to be.)
I think you are misunderstand what systemd-install is about. I have
now
added an additional sentence to the man page that explains that
systemd-install is for the *suggested* installation only, and that you
are always welcome to deviate from that.
Given that knowledge, it makes me then wonder what exactly 'systemd-install
disable' is supposed to do. I'll check out git.
And also, if we ship an inittab that points people to creating those
symlinks your criticism would go away and things would be the same or
even simpler then with Upstart, right?
Well, I like what we have with upstart in that it just requires changing
a variable in a config file, rather than filesystem-level changes. Perhaps
there's a way to hack that in.
More later, maybe,
Bill
1:43 p.m.
On Wed, 14.07.10 21:38, Bill Nottingham (notting(a)redhat.com) wrote:
> And that comparison is not even fair. The thing that was called
service
> file in sysv is called service file in systemd too (it even has .service
> is suffix, how obvious!). However since in contrast to sysv we not only
> maintain services, but also mount points, devices, yadda yadda, we came
> up with a more generic term for all these kinds of things, where
> "service" is one kind of, and that term is "unit". How else
would you
> have done this?
As stated below, I'd probably have separated them in the layout. Dumping
all services/mounts/sockets/etc. in one place seemed overkill.
Well, you criticised that we use the term "unit" for this, which was
previously unused, that is unrelated to the installation directories for
them.
I think some of this is just the tools being inconsistent in
terminology.
Take systemctl:
- It has a LOAD column (which is always 'loaded', in observation)
Well, that is a hint whether the unit file was loaded properly. It can
happen that a running service has an invalid unit file (i.e. you started
service with a valid file, then edited and reloaded the config file), so
the "load" state is independendant of the runtime state. That said, we
probably could suppress this column for services which loaded fine
(which should be the usual case)
- It says things like:
'78 live units listed. Pass --all to see dead units, too.'
when presumably, it should be talking active/inactive
Actually it shows active units and inactive units that failed. But
indeed the the term "live" for this is confusing and not used elsewhere
and I have removed it now.
- IT has JOB column (which is always empty, in observation)
Well, its empty if there's nothing started or being stooped right now,
or is waiting for some dependencies to start/stop. It will be empty if
your systemd started up completely, because there is nothing to do.
> Well, but the systemd unit files are trivial to understand. If
you
> honestly claim that the systemd unit files are harder to understand than
> shell monsters you find ind /etc/init.d then I'll go and shoot myself.
They are not easier to understand *in isolation*. For example,
even though I may not understand it all, it's fairly easy to understand what
/etc/init.d/iptables' purpose in life is from reading it. I can't say
that about any of the 'special' task files, as they contain no data
in and of themselves. Honestly, it's probably better for them just
to be either:
- self-documenting and contain the relevant man page segment
Well, funny you are asking for this, because the special units actually
include a line telling you where to find more information about what
makes them special.
Example: /lib/systemd/system/syslog.target has this line:
# See systemd.special(7) for details
I am not sure I want to duplicate all documentation in the man pages and
in the spec fails a second time. If you think a referal like that in the
unit files won't work then I don't think that anything will ever work.
- not exist, and only be documented in the man page (with the
understanding that certain targets/services/automounts are
'internal' to systemd.)
Well, it's kinda hard symlinking non-existing unit files. If we
remove let's say "multi-user.target" from /lib/systemd/units, and the
admin wants to create a new system 'profile' by adding a target that
pulls in 'multi-user' and adds a bit more on top, then he can just
achieve that with a .wants/ symlink onto multi-user.target.
> > - why does everything need *both* mount and automount
files?
>
> It doesn't. Dude, this is so not fair.
... all the shipped ones do.
That's actually not true. We ship var-run.mount and var-lock.mount
(which is not enabled), which comes without automount unit. There would
be no point in doing automounting for those dirs.
Perhaps I'm being obtuse, but it seems a matter of design to me.
I'm
not seeing why we just don't have Automount=yes (or OnDemand=yes, or
whatever) in the .mount files, rather than another separate file that
requires a matching .mount file, much like how bluetooth has
'StopWhenUnneeded'. While you describe below the reasoning for
separate entries for socket & service, I'm not seeing an obvious
reason for the separation here.
Oh, the argument for the sockets actually applies even more on mount
points. Note that the ordering for mount points and automount points is
really key. I.e. you cannot mount /var/run before you mounted
/var. systemd implicitly creates all those dependencies for you. Also,
mounting /home might require rpcbind around or some uid mapping
daemon. Which means that the point in time an automount point is
established is very different from the point in time where it is
actually replaced by the mount itself -- in terms of dependencies. Both
automatic and explicitly configured dependencies that is. And that means
you want to treat them as seperate units, that live in different places
in the dependency tree.
Of course you could still encode all meta data for both units in the
same file, but this would be more confusing i guess, since you'd have to do:
<snip>
[Unit Mount]
After=foobar.service
...
[Unit Socket]
After=waldo.service
...
</snip>
Which is kinda confusing, especially since then one of the sexy things
in systemd would go away: that the runtime object name for everything we
maintain is actually identical to the file name. Because suddenly
foo.mount would create a runtime object foo.mount and another one
foo.automount. I think for simplicity reasons it is really nice to
always have a 1:1 relationship betwee the runtime objects and the files
they are configured in, and have them have the same names.
To visualize the dependencies between the units, and in particular the
automatically generated ones (i.e. the majority) I have now added a bit
of code to systemctl which can generate data suitable for graphviz. I*ll
publish an example garphic soon. Thanks to Mathias for the suggestion.
> > - if swap, local-fs, etc. are all bookkept internally,
what's the point of
> > having a target file?
>
> Well, it's called "compatiblity". Because we keep compat with
existing
> stuff we automatically populate swap.target, local-fs.target and
> remote-fs.target with the data from /etc/fstab. How amazing is that? We
> treat the existing configuration just as another source of configurationn
> that is used alongside native configuration, and then make it appear as
> if it was natively configured.
Yes, that I understand. I'm just not understanding why the swap.target
*file* exists. I may be being overly picky, but if the 'meat' of the
file is only automatically determined by the daemon itself, I'm not
sure the file itself serves much purpose.
One example: a user creates his own target "my-special-boot.target". In
which he says, "I want local file systems, I want swaps, I don't want
remote file systems and I want these three services". He can now easily
do this like this:
<snip>
echo -e "[Unit]\nDescription=Lennart's awesome boot target" >
/etc/systemd/system/my-special-boot.target
mkdir -p /etc/systemd/system/my-special-boot.target.wants
cd /etc/systemd/system/my-special-boot.target.wants
ln -sf /lib/systemd/system/swaps.target \
/lib/systemd/system/local-fs.target \
/lib/systemd/system/foo.service \
/lib/systemd/system/bar.service \
/lib/systemd/system/waldo.service .
</snip>
And done. Now he can boot into this mode by passing
systemd.unit=my-special-boot.target on the kernel cmdline, or switch for
and back to and from it by using "systemctl isolate
my-special-boot.target".
If the target files wouldn't exist, it would by difficult to create
those symlinks.
> Well, in systemd we only read files that are requested, for
perfomance
> reasons. if something or somebody requests "foo.service" we load that
> file. And if we then find an alias configured in that file we install
> that alias too. However, if somebody looks up things under the alias
> first then he will only end up with the unit file if there's a symlink
> for it.
OK, I was missing a detail here - I was conflating alias with name. What I
was noticing was the local.service -> rc.local.service link in /lib/systemd.
This is actually just bookkeeping to make sure it overrides the /etc/init.d/
service, if I'm now reading this right. I wonder if there's a better way to
handle this case other than just creating more Name entries/symlinks (have
the daemon do this without the symlink?), but... *shrug*.
Well, it's just there because the old fedora sysv system is a bit weird
and used both names at different places. And so we inherited that in a way.
> That's why you want to have independent entities here for
sockets and
> services: they can be independently activated and when one eventually
> triggers activation of the other that can even pull a completely
> different slew of dependencies.
OK. My taste preference is to have that be configured in two sections
in one file rather than two separate-but-dependent files, but I can
also see the benefits of separation for consistency.
See my further comments above on why having them seperate is nice.
Note that launchd actually has everything in one file for each
service. However they do much less than systemd, and they don't launchd
for early boot, where manual dependencies actually matter.
> sshd.socket
> sshd@2-127.0.0.1:22-127.0.0.1:46660.service
> sshd@3-172.31.0.50:22-172.31.0.4:43289.service
Sure, but those service entries wouldn't be files in the system (unless
you're planning to write them on demand somewhere...?)
They actually are. i.e. there is a template file both of those
connection services are instantiated from. It's called
sshd@.service. I.e. with the instance name removed (where the instance
name is everything from the first "@" to the last ".").
Sure, but there's a lot of syntatical noise in the pathname
that's
important (it needs to be under getty.target.wants, it needs to be of
that form), that to explain opens up a much bigger can of worms.
Well, it's a link from one place to another place. And nothing forces
you to put that in getty.target.wants. We just thought it would be cool
to group the gettys under one target, but that's just our
taste. gettys.target is in no way special, other than we install that
target by default because we thought that was good style and because it
allows you to start up all gettys with a single command.
I just
wonder if that sort of long path will lead to more people cut-and-pasting
than actually understanding why it's that way. (It's along the lines of
why I dislike things like 'dbus-send --system --print-reply \
--dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager \
org.freedesktop.ConsoleKit.Manager.CanRestart' - it feels that it's
more baroque than it needs to be.)
I am sorry, but if you argue that an "ln -sf" line with two arguments is
as complex as this dbu-send line, then I don't think I follow anymore.
Given that knowledge, it makes me then wonder what exactly
'systemd-install
disable' is supposed to do. I'll check out git.
Currently it undos the suggested installation, but leaves everything you
manually added enabled. Might be worth extending to remove all symlinks,
i.e. for package uninstall. This is now on my todo list.
> And also, if we ship an inittab that points people to creating
those
> symlinks your criticism would go away and things would be the same or
> even simpler then with Upstart, right?
Well, I like what we have with upstart in that it just requires changing
a variable in a config file, rather than filesystem-level changes. Perhaps
there's a way to hack that in.
But that again is a matter of taste, isn't it?
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:11 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Wed, 14.07.10 21:38, Bill Nottingham (notting(a)redhat.com) wrote:
[...]
> I think some of this is just the tools being inconsistent in
terminology.
>
> Take systemctl:
>
> - It has a LOAD column (which is always 'loaded', in observation)
Well, that is a hint whether the unit file was loaded properly. It can
happen that a running service has an invalid unit file (i.e. you started
service with a valid file, then edited and reloaded the config file), so
the "load" state is independendant of the runtime state. That said, we
probably could suppress this column for services which loaded fine
(which should be the usual case)
Better mark them off-band somehow (i.e., a extra column (normally empty, no
header) that shows failures/abnormal cases).
[...]
> - IT has JOB column (which is always empty, in observation)
Well, its empty if there's nothing started or being stooped right now,
or is waiting for some dependencies to start/stop. It will be empty if
your systemd started up completely, because there is nothing to do.
Ditto.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
3:55 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
Example: /lib/systemd/system/syslog.target has this line:
# See systemd.special(7) for details
I am not sure I want to duplicate all documentation in the man pages and
in the spec fails a second time. If you think a referal like that in the
unit files won't work then I don't think that anything will ever work.
Honestly, I think that if all systemd.special(7) is is one
by one descriptions of each special target, then it's better
to document them in the targets themselves and drop the man
page entirely.
Again, matter of taste.
> OK, I was missing a detail here - I was conflating alias with
name. What I
> was noticing was the local.service -> rc.local.service link in /lib/systemd.
> This is actually just bookkeeping to make sure it overrides the /etc/init.d/
> service, if I'm now reading this right. I wonder if there's a better way to
> handle this case other than just creating more Name entries/symlinks (have
> the daemon do this without the symlink?), but... *shrug*.
Well, it's just there because the old fedora sysv system is a bit weird
and used both names at different places. And so we inherited that in a way.
Can't this be solved by just having rc.local executed by a native systemd
file and dropping the explicit Sxx SysV link? (Similar for some other
items.)
> Given that knowledge, it makes me then wonder what exactly
'systemd-install
> disable' is supposed to do. I'll check out git.
Currently it undos the suggested installation, but leaves everything you
manually added enabled. Might be worth extending to remove all symlinks,
i.e. for package uninstall. This is now on my todo list.
Yeah, I think we'll need that just to avoid dangling symlinks getting left
around in some cases - even if the user doesn't create random new targets,
they might enable the service in one of the default targets.
> Well, I like what we have with upstart in that it just requires
changing
> a variable in a config file, rather than filesystem-level changes. Perhaps
> there's a way to hack that in.
But that again is a matter of taste, isn't it?
Sort of. I wonder if it's equally similar to represent in config management
systems like puppet. Something to look at later...
Bill
3:51 p.m.
On Thu, Jul 15, 2010 at 01:29:03AM +0200, Lennart Poettering wrote:
And btw, you can even create automount points via
comment=systemd.automount as mount option in /etc/fstab. You don't even
have to place an .automount file anywhere. For the API file systems
however we decided to do just that because it is way easier to just drop
those additional files in there than it is to patch /etc/fstab.
I'd like to support /etc/fstab.d/ in F-15, so you don't have to
modify /etc/fstab and you don't have to use any systemd specific
config files for this stuff.
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
12:08 p.m.
On 07/13/2010 07:24 PM, Lennart Poettering wrote:
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
I just want to say that I am excited to explore this new system, but very
concerned about its current user interface (disclosure - I'm a sysadmin :-) as
it strikes me (from a very quick first impression only) as overly complex and
a bit clunky. I am doubly concerned that as soon as this lands in a released
version of a distro, it's interface will become fixed. So, I would counsel
patience in working through these issues, and that if this means slipping a
release, so be it.
I'm also wondering where would be the best place to discuss these issues, as
this thread is quite unwieldy. Here? systemd-devel? bugzilla?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
5016
days inactive
5028
days old
303 comments
49 participants
participants (49)
-
Adam Williamson -
Alexander Boström -
Bill Nottingham -
Chris Adams -
Chris Lumens -
Christof Damian -
Chuck Anderson -
Cleaver, Japheth -
Cliff Nadler -
Cole Robinson -
Colin Walters -
Daniel J Walsh -
Daniel P. Berrange -
David Airlie -
drago01 -
Enrico Scholz -
Hans de Goede -
Horst H. von Brand -
James Antill -
Jason L Tibbitts III -
Jef Spaleta -
Jeff Garzik -
Jeff Raber -
Jeffrey Ollie -
Jesse Keating -
John Reiser -
Jon Masters -
Jóhann B. Guðmundsson -
Kalev Lember -
Karel Zak -
Kevin Fenzi -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
Michael Christie -
Mike McGrath -
Miloslav Trmač -
Orion Poplawski -
Paul W. Frields -
Rahul Sundaram -
Rudolf Kastl -
Sam Varshavchik -
Scott Schmit -
Seth Vidal -
Simo Sorce -
Stephen John Smoogen -
Till Maas -
Tomasz Torcz -
Toshio Kuratomi