The 23/07/12, Kevin Chadwick wrote:

> Ignoring systemctl output which is still less clear and slowed me down.

I don't agree.

> Show what daemons will be running if you were to boot a filesystem
> which isn't running and tell me it's as quick to work out on a systemd
> system.

http://fedoraproject.org/wiki/How_to_debug_Systemd_problems
http://0pointer.de/blog/projects/self-documented-boot.html

--
Nicolas Sebrecht

As far as I can tell from the systemd blog and people's reactions
here, the only advantages systemd offers are:
- Splitting the configuration files, which increases the robustness of
the configuration files
- Daemon supervision
- Bootup speedup by parallelizing the daemons.
However, from the responses of some people, like Jorge Almeida, I see
that the benefits of systemd are also given by other programs.
- It has been suggested in a different thread to implement support for
rc.conf to source other files - which would allow rc.conf to split
cleanly
- As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can
supply daemon supervision *without* changing the init scheme
- A patch [4] has been posted, and possibly added, to NetBSD's
rcorder, which allows daemons to be started concurrently.

As far as init systems go, it seems to me that while Arch touts using
a BSD-style init, it's actually hacking around sysvinit to
provide a BSD-like interface. This seems wrong to me, as BSD already
provides a robust init framework.
Why simulate that which you can use?

In addition, people have cried out against several problems with
systemd, which include:
- ini-style configuration vs. shell-style configuration
- Large, monolithic binary

It seems to me that in addition to adding support for systemd could
ease compatibility with other distro's,
it would be beneficial to add sourcing to rc.conf (or alternatively to
symlink the new systemd configuration files to files in rc.d).
However, the only reason to do so is because systemd is widely used -
i.e. I do not suggest doing this for every init system around.

In addition, it may be considered to move from systemv to NetBSD's
init, which stays in-line with the simple interface of rc.conf
but adds parallelization and modularity.

Lastly, it may be beneficial to suggest to users to install one of the
daemon monitors.

In sum, systemd offers some benefits that are covered by other
programs and patches, while drawing much controversy and exacting
a toll which seems a bit too large in the eyes of some users. For this
reason, while we should add compatibility for systemd, we shouldn't
force it down the users throats.

Just my two cents.

M

[1] - http://cr.yp.to/daemontools.html
[2] - http://b0llix.net/perp/
[3] - http://www.skarnet.org/software/s6/
[4] - http://forums.freebsd.org/showthread.php?t=25822 (Concurrent
execution of rc-scripts with rcorder(8) )

* Menachem Moystoviz <moystovi@g.jct.ac.il> wrote:
> As far as I can tell from the systemd blog and people's reactions
> here, the only advantages systemd offers are:
> - Splitting the configuration files, which increases the robustness of
> the configuration files
> - Daemon supervision
> - Bootup speedup by parallelizing the daemons.
> However, from the responses of some people, like Jorge Almeida, I see
> that the benefits of systemd are also given by other programs.
> - It has been suggested in a different thread to implement support for
> rc.conf to source other files - which would allow rc.conf to split
> cleanly
> - As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can
> supply daemon supervision *without* changing the init scheme

Also minit by fefe does this, but than we have to put some work into the
/etc/minit script system... which may also break the easy arch way,
which we have now.

> - A patch [4] has been posted, and possibly added, to NetBSD's
> rcorder, which allows daemons to be started concurrently.

That thing seems to be the right one, for me

> As far as init systems go, it seems to me that while Arch touts using
> a BSD-style init, it's actually hacking around sysvinit to
> provide a BSD-like interface. This seems wrong to me, as BSD already
> provides a robust init framework.
> Why simulate that which you can use?
>
> In addition, people have cried out against several problems with
> systemd, which include:
> - ini-style configuration vs. shell-style configuration
> - Large, monolithic binary
>
> It seems to me that in addition to adding support for systemd could
> ease compatibility with other distro's,
> it would be beneficial to add sourcing to rc.conf (or alternatively to
> symlink the new systemd configuration files to files in rc.d).
> However, the only reason to do so is because systemd is widely used -
> i.e. I do not suggest doing this for every init system around.
>
> In addition, it may be considered to move from systemv to NetBSD's
> init, which stays in-line with the simple interface of rc.conf
> but adds parallelization and modularity.
>
> Lastly, it may be beneficial to suggest to users to install one of the
> daemon monitors.
>
> In sum, systemd offers some benefits that are covered by other
> programs and patches, while drawing much controversy and exacting
> a toll which seems a bit too large in the eyes of some users. For this
> reason, while we should add compatibility for systemd, we shouldn't
> force it down the users throats.


Full ACK by me.

Thanks for your two cents, I put my two to them

--
regards, TR

On Sat, Jul 28, 2012 at 4:20 PM, Menachem Moystoviz <moystovi@g.jct.ac.il>wrote:

> As far as I can tell from the systemd blog and people's reactions
> here, the only advantages systemd offers are:
> - Splitting the configuration files, which increases the robustness of
> the configuration files
> - Daemon supervision
> - Bootup speedup by parallelizing the daemons.
> However, from the responses of some people, like Jorge Almeida, I see
> that the benefits of systemd are also given by other programs.
> - It has been suggested in a different thread to implement support for
> rc.conf to source other files - which would allow rc.conf to split
> cleanly
> - As Jorge Almeida suggested, daemontools [1], perp [2] and s6 [3] can
> supply daemon supervision *without* changing the init scheme
> - A patch [4] has been posted, and possibly added, to NetBSD's
> rcorder, which allows daemons to be started concurrently.
>
> As far as init systems go, it seems to me that while Arch touts using
> a BSD-style init, it's actually hacking around sysvinit to
> provide a BSD-like interface. This seems wrong to me, as BSD already
> provides a robust init framework.
> Why simulate that which you can use?
>
> In addition, people have cried out against several problems with
> systemd, which include:
> - ini-style configuration vs. shell-style configuration
> - Large, monolithic binary
>
> It seems to me that in addition to adding support for systemd could
> ease compatibility with other distro's,
> it would be beneficial to add sourcing to rc.conf (or alternatively to
> symlink the new systemd configuration files to files in rc.d).
> However, the only reason to do so is because systemd is widely used -
> i.e. I do not suggest doing this for every init system around.
>
> In addition, it may be considered to move from systemv to NetBSD's
> init, which stays in-line with the simple interface of rc.conf
> but adds parallelization and modularity.
>

Lastly, it may be beneficial to suggest to users to install one of the
> daemon monitors.
>
> In sum, systemd offers some benefits that are covered by other
> programs and patches, while drawing much controversy and exacting
> a toll which seems a bit too large in the eyes of some users. For this
> reason, while we should add compatibility for systemd, we shouldn't
> force it down the users throats.
>
> Just my two cents.
>
> M
>
> [1] - http://cr.yp.to/daemontools.html
> [2] - http://b0llix.net/perp/
> [3] - http://www.skarnet.org/software/s6/
> [4] - http://forums.freebsd.org/showthread.php?t=25822 (Concurrent
> execution of rc-scripts with rcorder(8) )
>


here here

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/28/2012 02:20 PM, Menachem Moystoviz wrote:
>
> In sum, systemd offers some benefits that are covered by other
> programs and patches, while drawing much controversy and exacting a
> toll which seems a bit too large in the eyes of some users. For
> this reason, while we should add compatibility for systemd, we
> shouldn't force it down the users throats.
>
Having just survived the conversion to systemd, I would offer a few
comments:

1) I learned stuff on this list that didn't seem to have been
available in the documentation. And I still don't feel I really have a
mastery of systemd service files. My feeling is that the man pages and
the wiki could probably use more work.

2) It looks to me like there is some ugliness on logging. The Arch
wiki suggests a change to the syslog-ng configuration file so that
syslog-ng can work with the systemd journal. The trouble I'm having
with that is that--these are the examples I know about--apache2 and
postfix do not seem willing to log in a way that the systemd journal
can pick up; these daemons apparently will only log through the
traditional syslog-ng channel, and are not compatible with the new
socket. I actually kind of like journalctl (it has a -f option so you
can monitor it like you used to be able to do with tail -f
/var/log/everything.log), but you really now have to do multiple
commands to get everything that everything.log used to get.

3) The conversion to systemd was mostly a lot of work. It wasn't
rocket science, though as noted above, I still don't feel I fully
understand what's going on. Many, many packages, especially in the
AUR, do not yet have service files. This leads me to suspect that
there is at least as much angst among package maintainers about all
this as we've seen on this list.

- --
David Benfell
benfell@parts-unknown.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQFMgoAAoJELT202JKF+xplvYQAI6DcviIC2 y69t2uhXmadn9X
2XYX+2YHbnM4OnAU2ysdj67bgcN2vKDQiT8GrAb+JQOphx8P0Y 4NefkC1fMZUpzy
f8EMOIzRaHjfOJ4RKjM+eT9hM3Kg3qlroI9hIcEZM59UnCRMLL 1qa8RMY58Bj0lV
oOBa4Y2MAi7wNJ0ZlLDnQEFGMNhME9sWaGXYV+VRgzjVUaxAz0/MetJum+Wz5YFv
QAHyOgSl14UeB1AeenMxZrS0SDSTVvLofXJRCkus5TqvJFJ9cE akHz2RNvN1Tyft
yEW/8vgPSFz160GOvGXVxmqSh0SrYWLUGhRWQ1dLd1j4PI6dB85Sh1 u1Z8jVx7Z/
286o4HBvQHkSMALLDxmgdaltuxlKlOwEn/ZEkUB3tZHXWl3/WD8OtZ/EulUgl/DB
vOxWHFWFyt4MKU1tHqwP+UTqKI01y515+uARYmih7vQ2JsXyOX hd76nkgm13M7Pp
dTuYlQa9AKOQmyRKsMpYMqerdyo1wYflr8ZgE3vOjjCFFYYYOL Xq8jePUcepivvv
vdf7Gk2GGHoZrNrBdd82SOaVRKMyKdKEJT5TB1rPf+eiQ3LHdx kJhHNsr9s59cux
oxo+CI/bM6Vn0HR4c1Q326aG/7gs0GQd4D6nx9uAhUhI2SDxxLVpitTPGLRjo51j
BJesYdSnVPX0cMbj4L3I
=+xYY
-----END PGP SIGNATURE-----

On Sun, Jul 29, 2012 at 12:20:10AM +0300, Menachem Moystoviz wrote:
> In addition, it may be considered to move from systemv to NetBSD's
> init, which stays in-line with the simple interface of rc.conf
> but adds parallelization and modularity.

That'd win so hard.

> Lastly, it may be beneficial to suggest to users to install one of the
> daemon monitors.

Daemontools has been working sufficiently well for my purposes.
It's lean, robust, and I'm a fan of the exec chain.

> For this
> reason, while we should add compatibility for systemd, we shouldn't
> force it down the users throats.

How do you add support in this way?

Op 29 jul. 2012 17:11 schreef "Anthony &apos;&apos;Ishpeck&apos;&apos;
Tedjamulia" <archlinux@ishpeck.net> het volgende:
>
> On Sun, Jul 29, 2012 at 12:20:10AM +0300, Menachem Moystoviz wrote:
[...]

> Daemontools has been working sufficiently well for my purposes.
> It's lean, robust, and I'm a fan of the exec chain.
>
> > For this
> > reason, while we should add compatibility for systemd, we shouldn't
> > force it down the users throats.
>
> How do you add support in this way?

Use a script to parse the systemd unit files. If you let the admin
configure which daemons to start, then you mainly have to use the execstart
lines, i guess.

The arch init scripts are still suported, btw.

mvg, Guus