Bug 318365 – systemd - Replacement for sysvinit with extensive usage of parallelization

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andrey Ovcharov 2010-05-04 05:15:22 UTC]

systemd new init system, more information can be found at:

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

[Comment 1 Markos Chandras (RETIRED) 2010-05-04 13:50:39 UTC]

Hello, The Gentoo Team would like to firstly thank you for your ebuild 
submission. We also apologize for not being able to accommodate you in a timely
manner. There are simply too many new packages.

Allow me to use this opportunity to introduce you to Gentoo Sunrise. The 
sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to 
commit to and all users can have ebuilds reviewed by Gentoo devs for entry 
into the overlay. So, the sunrise team is suggesting that you look into this 
and submit your ebuild to the overlay where even *you* can commit to. =)

Thanks,
On behalf of the Gentoo Sunrise Team,
Markos.

[1]: http://www.gentoo.org/proj/en/sunrise/
[2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseF

[Comment 2 Fabian Henze 2010-05-08 08:10:36 UTC]

(In reply to comment #0)
> systemd new init system, more information can be found at:
> 
> http://0pointer.de/blog/projects/systemd.html
> 

I have a hackish/sort-of working ebuild, which requires you to disable sandbox (FEATURES="-sandbox") to install. Improvements are welcome.

[Comment 3 Fabian Henze 2010-05-08 08:11:36 UTC]

Created attachment 230771 [details]
systemd-9999.ebuild

[Comment 4 Fabian Henze 2010-05-08 08:12:07 UTC]

Created attachment 230773 [details]
systemd-9999-gentoo.patch

[Comment 5 Marc-Antoine Perennou 2010-05-08 08:35:12 UTC]

you should use
emake DESTDIR=${D} install
and then it should work with sandbox enabled ;)

[Comment 6 Fabian Henze 2010-05-08 09:31:14 UTC]

(In reply to comment #5)
> you should use
> emake DESTDIR=${D} install
> and then it should work with sandbox enabled ;)

Thanks that worked. I don't have much experience in writing ebuilds and I thought it was a bootstrap.sh related issue.
I will upload the fixed ebuild and a systemd patch to read the hostname from /etc/conf.d/hostname now.

[Comment 7 Fabian Henze 2010-05-08 09:32:29 UTC]

Created attachment 230777 [details, diff]
systemd-9999-gentoo-hostname.patch - read the hostname from /etc/conf.d/hostname

[Comment 8 Fabian Henze 2010-05-08 09:33:49 UTC]

Created attachment 230779 [details]
systemd-9999.ebuild - fixed the install function and some minor cleanups

[Comment 9 Marc-Antoine Perennou 2010-05-09 09:29:35 UTC]

Gentoo is now supported upstream, patch no longer needed
http://cgit.freedesktop.org/systemd/commit/?id=f2b4af1cd4112df6ce56f8fc1e677639935e3d0e

[Comment 10 Fabian Henze 2010-05-09 18:53:02 UTC]

Created attachment 230887 [details, diff]
patch for those who want to run systemd without "legacy" sysv init script support.

[Comment 11 Fabian Henze 2010-05-09 18:58:55 UTC]

Created attachment 230889 [details]
updated ebuild

This ebuild catches up with the latest commits in the systemd repository.
With the patches by me and Marc-Antoine Perennou now being upstream, you don't have to patch systemd anymore. However I think it's sometimes useful to disable the sysv compatibility mode for existing init scripts, so I introduced the "nosysv" useflag, which is disabled by default.

[Comment 12 Steve Herber 2010-05-11 05:58:24 UTC]

It looks like the ebuild needs to depend upon some posix feature or package:

checking if gcc -std=gnu99 supports -fdiagnostics-show-option flag... yes
checking if gcc -std=gnu99 supports -Wno-missing-field-initializers flag... yes
checking for library containing clock_gettime... -lrt
checking for library containing cap_init... no
configure: error: *** POSIX caps library not found
>>> Source configured.
>>> Compiling source in /var/tmp/portage/sys-apps/systemd-9999/work/systemd-9999 ...

[Comment 13 Steve Herber 2010-05-12 07:28:40 UTC]

To partially follow up my own question, I added caps to my USE flags
in /etc/make.conf and ran emerge --newuse world and one or more of
these should probably be checked for in the ebuild.  Also, should
the ebuild require the USE caps flag? 

emerge --ask --verbose --newuse --deep world

These are the packages that would be merged, in order:

Calculating dependencies... done!
... removed any non-caps ebuilds ....
[ebuild  N    ] sys-libs/libcap-2.17  USE="pam" 48 kB
[ebuild   R   ] sys-apps/coreutils-8.4  USE="acl caps* nls unicode -gmp (-selinux) -static -vanilla -xattr" 27 kB
[ebuild   R   ] app-misc/pax-utils-0.1.19  USE="caps*" 76 kB
[ebuild   R   ] net-misc/ntp-4.2.4_p7-r1  USE="caps* ipv6 ssl -debug -openntpd -parse-clocks (-selinux) -vim-syntax -zeroconf" 0 kB

[Comment 14 Fabian Henze 2010-05-12 08:16:39 UTC]

Created attachment 231157 [details]
systemd-9999.ebuild - libcap is a dependency

This ebuild should fix your problem. you don't have to set the caps useflag just to get systemd working.

[Comment 15 Steve Herber 2010-05-12 14:05:35 UTC]

another follow up to my previous post.
Setting the caps USE flag and recompiling the package mentioned before
allowed systemd to to compile and install.

The default install directory /usr/sbiin is inappropriate.
All boot time programs must go into /sbin as /usr is often
on a partition that is mounted later - unless working around
this convention is part of the systemd magic.

Thanks for the ebuild update.  I will revert and try that next.

[Comment 16 Fabian Henze 2010-05-13 11:17:45 UTC]

Created attachment 231305 [details]
systemd-9999.ebuild - gtk is optional, install to a proper prefix, updated dependencies

This ebuild won't install to /usr/local anymore. I also added a gtk useflag and updated the dependencies according to the projects README file.

[Comment 17 Steve Herber 2010-05-20 07:19:34 UTC]

Today I attempted to rebuild systemd using the keruspe overlay and
pulled down a new systemd version from git and this version has added
man pages but I ended up with the error below.  I don't know what gentoo
package I need to fix this.  Thanks.

  CC     src/systemd-fdset.o
  CC     src/systemd-namespace.o
  CC     src/systemd-main.o
  CCLD   systemd
  GEN    man/systemd.unit.5
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
make[1]: *** [man/systemd.unit.5] Error 4
make[1]: Leaving directory `/var/tmp/portage/sys-apps/systemd-9999/work/systemd-9999'
make: *** [all] Error 2
 * ERROR: sys-apps/systemd-9999 failed:
 *   emake failed

[Comment 18 Marc-Antoine Perennou 2010-05-20 07:50:04 UTC]

An xsl error, I saw another one like this "reported" in the irc channel.
Just tried to update dependencies, can you retry ?

[Comment 19 Steve Herber 2010-05-25 02:46:59 UTC]

To follow up, when using the ebuild from the keruspe overlay everything
compiles and installs on a system with gtk+ installed.  Still no luck
with the -gtk USE flag for systems without X.

I have started a gentoo wiki page for systemd: 

http://en.gentoo-wiki.com/wiki/Systemd

Please help out by updating the page.  Thanks.

[Comment 20 Steve Herber 2010-05-28 05:27:11 UTC]

OK, I have systemd installed using the keruspe overlay version of the ebuild.
I can boot with systemd as the init process and systemd starts.  And systemd
runs but has many failures.  When I hit ctrl-alt-delete systemd talks about
the reboot process.  So I know systemd is running.  But not enough of the
tasks succeed to get logs.  To reduce the number of messages I did remove the
getty1-5 entries.  So below are my manually entered systemd log.

I have two questions, can you tell me what is wrong and is there a way
to have a very reduced version of systemd configuration files that will
have a better chance of working so I can debug the other tasks?

Scrolling back as far as possible on the console and condensing them a bit
I have:

systemd[1]: Added job multi-user.target/start to transaction.
followed by basic.target, local-fs.target, swap.target, sockets, logger,
initctr, and so on ending with xdm.service.

These are followed by the Found redundant job....dropping messages.

Next is Garbage collecting.

Then Enqueued job graphical.target/start as 1
Autofs kernel version 1..0
Autofs protocol version 5.1
sys-fs-fuse-connections.automoutn changed dead -> waiting
job sys-fs-fuse-connections.automount/start finished, success=yes
proc-sys-fs-binfmt_misc.automoutn changed dead -> waiting
job proc-sys-fs-binfmt_misc.automount/start finished, success=yes
	and security - success=yes
	and a few others, then
dev-mqueue.automount changed dead -> waiting
Job dev-mqueue.automount/start finished, success=yes
Failed to initialize automounter: no such file or directory
sys-kernel-debug.automount changed dead -> maintenance
Job sys-kernel-debug.automount/start finished, success=no
	others run with success=yes
Forked /sbin/agetty as 4583
Forked /etc/init.d/xdm 4584

Running GC...
Got SIGCHLD for 4583, died, code=exited, status=213/SECUREBITS
	autorestart - fails again and again until the request repeated
	too quickly, refusing to start messages is posted.
	also X seems to have died.

[Comment 21 Nils Schlupp 2010-06-17 16:56:06 UTC]

I am far from an expert, but have you tried removing the extra gettys from /etc/systemd/system/getty.target.wants ?

[Comment 22 Florian Scandella 2010-06-24 12:04:04 UTC]

i have tried the keruspe overlay version too ... i think the problem is, the gentoo 'boot' runlevel does not get executed.
without the modules defined in modules.autoload (which are loaded in the boot runlevel) my system is quite useless.

[Comment 23 Oleh Kravchenko 2010-07-07 16:16:50 UTC]

>make[1]: Entering directory `/var/tmp/portage/sys-apps/systemd-9999/work/systemd-9999'
>  GEN    org.freedesktop.systemd1.Socket.xml
>Failed to mount /cgroup/systemd: No such device
>make[1]: *** [org.freedesktop.systemd1.Socket.xml] Error 1
>make[1]: Leaving directory `/var/tmp/portage/sys-apps/systemd-9999/work/systemd-9999'

[Comment 24 bay 2010-07-08 07:30:45 UTC]

Not installing due to sandbox:
ACCESS DENIED  mkdir:   ACCESS DENIED     mkdir :  /cgroup

After a make all directories manually, it not compiling due to QA: 

* 
* QA Notice: Package has poor programming practices which may compile
*            but will almost certainly crash on 64bit architectures.
* 
* Function `manager_dbus_proxy_new' implicitly converted to pointer at systemadm.vala:302
* Function `unit_dbus_proxy_new' implicitly converted to pointer at systemadm.vala:328
* Function `job_dbus_proxy_new' implicitly converted to pointer at systemadm.vala:355

[Comment 25 Marc-Antoine Perennou 2010-07-08 07:41:48 UTC]

(In reply to comment #24)
> Not installing due to sandbox:
> ACCESS DENIED  mkdir:   ACCESS DENIED     mkdir :  /cgroup
> 
> After a make all directories manually, it not compiling due to QA: 
> 
> * 
> * QA Notice: Package has poor programming practices which may compile
> *            but will almost certainly crash on 64bit architectures.
> * 
> * Function `manager_dbus_proxy_new' implicitly converted to pointer at
> systemadm.vala:302
> * Function `unit_dbus_proxy_new' implicitly converted to pointer at
> systemadm.vala:328
> * Function `job_dbus_proxy_new' implicitly converted to pointer at
> systemadm.vala:355
> 

Your problem with sandbox is because you're compiling as root, with FEATURES="userpriv usersandbox" there will not be this problem anymore (you should never be compiling as root)

For the QA stuff, I think you might want to report it to upstream

[Comment 26 Krzysztof Nowicki 2010-07-10 07:26:04 UTC]

Meanwhile the first releases have appeared. Version 1 was published 3 days ago shortly followed by v2 yesterday.

[Comment 27 Fabian Henze 2010-07-12 12:34:04 UTC]

Created attachment 238431 [details]
systemd-2.ebuild

I modified my systemd ebuild to work with systemd-2 (a -9999 version will follow). I also cleaned up the ebuild and added use flags for pam and tcp-wrapper.
btw: is the author of the ebuild in the keruspe overlay following this thread. I wonder where he got his list of dependencies from ...

[Comment 28 Marc-Antoine Perennou 2010-07-12 13:37:33 UTC]

(In reply to comment #27)
> Created an attachment (id=238431) [details]
> systemd-2.ebuild
> 
> I modified my systemd ebuild to work with systemd-2 (a -9999 version will
> follow). I also cleaned up the ebuild and added use flags for pam and
> tcp-wrapper.
> btw: is the author of the ebuild in the keruspe overlay following this thread.
> I wonder where he got his list of dependencies from ...
> 

My list of dependencies comes either from configure.ac, from #systemd, from the dev mailing list, or from mails which reported me missing deps

[Comment 29 Oleh Kravchenko 2010-07-12 13:49:17 UTC]

(In reply to comment #27)
> Created an attachment (id=238431) [details]
> systemd-2.ebuild
> 
> I modified my systemd ebuild to work with systemd-2 (a -9999 version will
> follow). I also cleaned up the ebuild and added use flags for pam and
> tcp-wrapper.
> btw: is the author of the ebuild in the keruspe overlay following this thread.
> I wonder where he got his list of dependencies from ...
> 


May be need add some checks of /usr/src/linux/.config (autofs4, devtmpfs,
cgroups) ?

[Comment 30 Alec Meyers 2010-07-12 16:26:13 UTC]

I was wondering, is syslog-ng required? Is it possible to use sysklogd instead, or is there something specific to syslog-ng that systemd wants?

[Comment 31 Andrey Ovcharov 2010-08-02 15:53:37 UTC]

Created attachment 241097 [details, diff]
systemd-3-dbus-1.3.2.patch

[Comment 32 Andrey Ovcharov 2010-08-02 15:54:40 UTC]

Created attachment 241099 [details]
systemd-3.ebuild

[Comment 33 Andrey Ovcharov 2010-08-02 16:05:21 UTC]

http://github.com/init6/init_6/blob/master/sys-apps/systemd/ 

systemd-3 full build log http://pastebin.com/2npTYgZy filed to install with error : 

"* 
 * QA Notice: Package has poor programming practices which may compile
 *            but will almost certainly crash on 64bit architectures.
 * 
 * Function `manager_dbus_proxy_new' implicitly converted to pointer at systemadm.vala:302
 * Function `unit_dbus_proxy_new' implicitly converted to pointer at systemadm.vala:328
 * Function `job_dbus_proxy_new' implicitly converted to pointer at systemadm.vala:355
 * 
 *  Please file a bug about this at http://bugs.gentoo.org/
 *  with the maintaining herd of the package.
 * 
 * ERROR: sys-apps/systemd-3 failed:
 *   install aborted due to poor programming practices shown above
 * 
 * Call stack:
 *   misc-functions.sh, line 817:  Called install_qa_check
 *   misc-functions.sh, line 492:  Called die
 * The specific snippet of code:
 *   				die "install aborted due to" \
"

systemd-4 depends on >=sys-fs/udev-160 >=sys-apps/dbus-1.3.2 and sys-libs/libselinux ??? I do not understand how it is in the fedora at all can work?

[Comment 34 Krzysztof Nowicki 2010-08-20 16:44:03 UTC]

When trying to get the latest systemd running I noticed that it needs service files from udev and dbus that are not normally installed. To install them I needed to re-emerge udev and dbus after installing systemd.

Alternatively ebuilds could use the --with-systemdsystemunitdir=/lib/systemd/system configuration option. I think it may be worth to add this option to the latest udev and dbus ebuilds (controlled by a new systemd USE flag).

[Comment 35 Matthias Gehre 2010-08-27 15:13:51 UTC]

Created attachment 244953 [details]
Dhcpcd.service file

[Comment 36 Matthias Gehre 2010-08-27 15:15:12 UTC]

Created attachment 244955 [details]
wpa_supplicant.service file

[Comment 37 Matthias Gehre 2010-08-27 15:15:37 UTC]

Created attachment 244957 [details]
iptables.service file

[Comment 38 Matthias Gehre 2010-08-27 15:15:58 UTC]

Created attachment 244959 [details]
syslog-ng.service file

[Comment 39 Matthias Gehre 2010-08-27 15:19:26 UTC]

I attached the service files I had to create to get everything running smooth.
One really SHOULD enable the service var-run.service, or sometimes services will not start on boot due to stale /var/run/*.pid files.

And currently you have to patch the gentoo-sources kernel to create the /sys/fs/cgroups directory.

In the gentoo wiki page for systemd, they propose to add real_init=/sbin/systemd, but for me only adding init=/sbin/systemd does replace the old init system.

[Comment 40 Krzysztof Nowicki 2010-08-27 18:45:54 UTC]

(In reply to comment #39)

> In the gentoo wiki page for systemd, they propose to add
> real_init=/sbin/systemd, but for me only adding init=/sbin/systemd does replace
> the old init system.
> 

That depends if you're using an initrd or not. The real_root option is for use with an initrd.

[Comment 41 Gustavo Sverzut Barbieri 2010-09-03 15:07:32 UTC]

I'm very interested in systemd support for gentoo. I'm already using openrc-0.6.3 and baselayout-2.0.1, are you using it as well or just the old baselayout?

I'm using metalog, do I have to move to syslog-ng?

My system is a desktop, so I use services such as acpid, consolekit, hald, alsasound, bluetooth, pommed, xdm... are these supported somehow? Any known to be missing? (I also use vixie-cron and udev-postmount, but I guess these are supported)

[Comment 42 Ewoud Kohl van Wijngaarden 2010-09-04 01:36:21 UTC]

I do not yet have tried it, but from http://fedoraproject.org/wiki/Features/systemd:
  Current status

    Targeted release: Fedora 14
    Last updated: 2010-08-03
    Percentage of completion: 100% 

    Systemd is currently in F14, and the default 

    Patches for various packages have been merged upstream and already found there way into F14 (dbus, udev, avahi, rtkit). Socket activation support that would be nice to have is still missing for rsyslog (submitted upstream, no comment yet), rpcbind (submitted upstream, partly merged), cups (not submitted yet). 

In other words, it should be possible to use it, but serveral gentoo packages might not include the .service files or missing some patches to perform optimal.

[Comment 43 Gustavo Sverzut Barbieri 2010-09-06 23:45:02 UTC]

I was able to run it, however udev and dbus ebuilds had to be changed to provide --with-systemdsystemunitdir=/lib/systemd/system (dbus-1.3.2 and udev-162). I also changed the systemd to be live from GIT as I'll send some patches there, given that I also changed the DEPENDS and RDEPENDS as vala-0.9 is required and only if gtk is enabled (from last configure.ac and Makefile.am), libcgroups is not required anymore, etc. I also added the kconfig checks for CGROUPS and AUTOFS4 using linux-info eclass. Last but not least, I do not use audit or selinux, so I added the use flags and have them disabled, it would be good to try it on an enabled system/profile.

I'm keeping my changes at http://barbieri-playground.googlecode.com/svn/gentoo/overlay/, but so far it is not working fully so I'll not post an attachment here until I have it. By that time I will update the wiki page as well. My system hangs at xdm without any input, probably I need to add services for hald and couple of others.

BTW, I'm running without initramfs/initrd and thus I need to add remount-rootfs.service. Do you know if it hurts to always add it? If not then I'll probably have the ebuild to do so.

[Comment 44 Mike Pagano 2010-09-14 01:17:48 UTC]

(In reply to comment #39)
> 
> And currently you have to patch the gentoo-sources kernel to create the
> /sys/fs/cgroups directory.
> 

The patch to create /sys/fs/cgroups is now included in gentoo-sources-2.6.35-r6

[Comment 45 hal 2010-09-18 14:26:13 UTC]

(In reply to comment #43)
> I was able to run it, however udev and dbus ebuilds had to be changed to
> provide --with-systemdsystemunitdir=/lib/systemd/system (dbus-1.3.2 and
> udev-162). I also changed the systemd to be live from GIT as I'll send some
> patches there, given that I also changed the DEPENDS and RDEPENDS as vala-0.9
> is required and only if gtk is enabled (from last configure.ac and
> Makefile.am), libcgroups is not required anymore, etc. I also added the kconfig
> checks for CGROUPS and AUTOFS4 using linux-info eclass. Last but not least, I
> do not use audit or selinux, so I added the use flags and have them disabled,
> it would be good to try it on an enabled system/profile.
> 
> I'm keeping my changes at
> http://barbieri-playground.googlecode.com/svn/gentoo/overlay/, but so far it is
> not working fully so I'll not post an attachment here until I have it. By that
> time I will update the wiki page as well. My system hangs at xdm without any
> input, probably I need to add services for hald and couple of others.
> 
> BTW, I'm running without initramfs/initrd and thus I need to add
> remount-rootfs.service. Do you know if it hurts to always add it? If not then
> I'll probably have the ebuild to do so.
> 

did you manage to get your network up?

[Comment 46 Gustavo Sverzut Barbieri 2010-09-18 18:47:42 UTC]

Yes, network is up with connman. Actually to improve situation i disabled the udev rule from gentoo to start /etc/init.d/net.$IFNAME as I want to stay away from openrc (/etc/init.d/*) during these tests.

I've updated my stuff with a lengthly README.txt at http://barbieri-playground.googlecode.com/svn/gentoo/overlay/sys-apps/systemd/

After I get the patch to disable sysv compatibility in systemd I guess that ebuild is ready to be send to this bug.

[Comment 47 Gustavo Sverzut Barbieri 2010-09-18 19:52:33 UTC]

As I see some @gentoo.org in the CC I'd like to ask you to consider proposing systemd as a possible alternative to openrc with a baselayout3.

The work could start by introducing IUSE=systemd and stop pacakge auto-discovery of systemdunitsdir (always forcing it to empty or /lib/systemd/system). Later on this use flag can be used to choose which files/* to use, if to install old services at /etc/init.d or /lib/systemd/system/ (this step will be the most time consuming, but will be easier when upstream packages start to get native systemd integration).

The last step would be to update documentation (handbook), replacing rc-update and friends with systemctl. At this phase we can even update references to /etc/conf.d to use more standard paths (see below), or keep them and use the gentoo-compat patches we'll send.

configuration files with systemd: core developers are trying to push for more standard base files, this does make sense as the base services are all built-in in systemd: locale, console keymap and font, hostname, etc. The non-base services are being pushed to avoid command line arguments in favor of their specific configuration files, so instead of /etc/conf.d/sshd we just have options set in /etc/ssh/sshd_config. To not be a "Gentoo has its own way", Fedora also had their own way and are moving towards this more standard configuration (no /etc/sysconfig for them anymore).

Except from political problems, the transition to Systemd in Gentoo should be super-simple. The fact that our users are more experienced and know how to read docs is a key differential for our success :-)

[Comment 48 Jason A. Donenfeld 2010-09-18 23:07:29 UTC]

(In reply to comment #47)
+1

[Comment 49 Benedikt Böhm (RETIRED) 2010-09-19 06:31:56 UTC]

(In reply to comment #47)
> As I see some @gentoo.org in the CC I'd like to ask you to consider proposing
> systemd as a possible alternative to openrc with a baselayout3.

please see http://archives.gentoo.org/gentoo-dev/msg_7aaa3c1e3fe7348c5a5bbdc6bd75af0d.xml and following. it's probably not going to happen, at least not as default init system.

[Comment 50 Sergey Kondakov 2010-09-19 07:05:27 UTC]

probably, this will upset a good deal of users, something from hundreds to thousands, depending on a maturity of systemd. pretty much everyone who ever used overlays to compensate lack of newest stuff.

not a good thinking, guys. especially, with openrc now dead.
but they right, it reeeeally "stable" that way :)
there are fools like me who use Gentoo on desktop, you know.

[Comment 51 Benedikt Böhm (RETIRED) 2010-09-19 07:09:26 UTC]

(In reply to comment #50)
> probably, this will upset a good deal of users, something from hundreds to
> thousands, depending on a maturity of systemd. pretty much everyone who ever
> used overlays to compensate lack of newest stuff.
> 
> not a good thinking, guys. especially, with openrc now dead.
> but they right, it reeeeally "stable" that way :)
> there are fools like me who use Gentoo on desktop, you know.

please don't spread such non-sense. openrc is neither dead, nor is systemd staying in an overlay forever. you can use whatever init system you like (there are already many of them in portage) - systemd just won't be the default init system in the foreseeable future.

[Comment 52 Gustavo Sverzut Barbieri 2010-09-19 07:24:02 UTC]

"default" in gentoo is a matter of documentation priority, we just need a way to have it working after a simple edit of /etc/make.conf to add the use flag and then a simple emerge. If we get there, then excellent!

[Comment 53 Sergey Kondakov 2010-09-19 07:33:15 UTC]

you have said it yourself: "it's probably not going to happen". and i just don't see Gentoo Developers making serious changes to openrc.

hopefully, now it doesn't require ones and not because it so cool but because it so simple. and GNU/Linux desktop, freedesktop, uses such ugly stuff as policekit, networkmanager and dbus and the only thing we can do with it is to use it properly. this is where systemd comes in.
it would be wise to use openrc for "stable"/server and systemd for desktop but not as one-of-those-many-otiose-from-the-portage. it's mainstream and complete official support would be in order, handbook pages and stuff.

[Comment 54 hal 2010-09-19 16:29:46 UTC]

(In reply to comment #46)
> Yes, network is up with connman. Actually to improve situation i disabled the
> udev rule from gentoo to start /etc/init.d/net.$IFNAME as I want to stay away
> from openrc (/etc/init.d/*) during these tests.
> 
> I've updated my stuff with a lengthly README.txt at
> http://barbieri-playground.googlecode.com/svn/gentoo/overlay/sys-apps/systemd/
> 
> After I get the patch to disable sysv compatibility in systemd I guess that
> ebuild is ready to be send to this bug.
> 

thanks for your efforts. maybe i didn't understand the whole system yet. i've got to digg deeper into it.
but shouldn't network come up without conman, too? or is conman a necessary dependency?

another thing. all filesystems in fstab fail to mount atm. all but the ones on sda. certain directories are located on sdb, e.g. /var, /usr/portage, /usr/src while /tmp and /var/log are in tmpfs.

[Comment 55 Gustavo Sverzut Barbieri 2010-09-19 18:27:17 UTC]

(In reply to comment #54)
> (In reply to comment #46)
> > Yes, network is up with connman. Actually to improve situation i disabled the
> > udev rule from gentoo to start /etc/init.d/net.$IFNAME as I want to stay away
> > from openrc (/etc/init.d/*) during these tests.
> > 
> > I've updated my stuff with a lengthly README.txt at
> > http://barbieri-playground.googlecode.com/svn/gentoo/overlay/sys-apps/systemd/
> > 
> > After I get the patch to disable sysv compatibility in systemd I guess that
> > ebuild is ready to be send to this bug.
> > 
> 
> thanks for your efforts. maybe i didn't understand the whole system yet. i've
> got to digg deeper into it.
> but shouldn't network come up without conman, too? or is conman a necessary
> dependency?

connman is like networkmanager, but simpler, faster. I'm helping development occasionally, the core developers are from intel/meego. It is simpler because it use less processes and depend less on the UI, they even provide lots of command line python utilities that gives you full control. It's faster because it even ships with a builtin (in process!) dhcp client, you can't believe how fast it gets IP after you plugin your ethernet cable.  It even does dns proxy, insteading of doing ugly hacks to maintain /etc/resolv.conf, all it does is direct to 127.0.0.1:53 and inside it knows about the routes and associated nameservers, doing the correct routing for you -- worth trying!

but all in all, you can have whatever you want as a bla.service, then link to this file from /etc/systemd/systemd/network.target.wants/bla.service. Everything that says "Want=network.target" will then bring up bla.service -- connman.service in my case. That bla.service may be the same as /etc/init.d/net.eth0 for die-hard users of Gentoo network scripts.


> another thing. all filesystems in fstab fail to mount atm. all but the ones on
> sda. certain directories are located on sdb, e.g. /var, /usr/portage, /usr/src
> while /tmp and /var/log are in tmpfs.

You need autofs4 and devtmpfs. The first is used to automatically mount as you use (as opposed to mount immediately at start, so /home will just be mounted later on, when it's actually used). The second is used to have kernel to automatically mount /dev as a tmpfs and populate it.

Also, if you use /var/log as tmpfs you may not care about persistent logs, right? If that's the case (as is for me) you can remove metalog/rsyslog/syslog-ng/... and use systemd's kmsg-syslogd, it will redirect all /dev/log messages to 
 /dev/kmsg (doing the proper formatting, with process name and so on). So it saves startup time and simplify maintenance :-)

[Comment 56 Gustavo Sverzut Barbieri 2010-09-19 18:42:59 UTC]

Replying to common questions and demystifying some things said:

   - systemd does NOT depend on policykit/polkit, no point to cite it. But all in all you just have something to do with it if you use DBus as it allows one to block certain messages from certain users. It is much like sudo for DBus. Do you hate sudo? Then why do you hate polkit?

   - systemd should NOT hard-depend on DBus. Right now nobody cares much if it is happening, but easily dropped as a dependency if people invest some effort. Systemd just do dbus-activation and exposes its controls over the system bus to make adminstration easier.  What systemd does is launch processes in a container as requested by DBus, IOW the dbus-activation is out from dbus-daemon to systemd. This is cleaner and more reliable, avoiding cases where a service (ie: consolekit) is started due some user request on the bus, but it was being started by openrc at the same time, ins such situation one of the startups will fail, however the required service would be working!   Don't come with "I hate dbus auto-activation" because if you use openrc you have some sort of it (you start ssh and it brings up network).

   - systemd is just for desktops is a fallacy. It is important for servers as well, after all you want to kill apache and all the processes it spawned, no? If for some reason (maybe a developer bug) a CGI double-forked to exit parent's tree, then you want it to be identifiable and killed, no? How about saving resources? If you have a server you want all its resources to be used for its main duty, what if you could have administrative services that are only started when you use (socket activation for sshd & cia -- okay you can do that with inetd, but we're centralizing the different parts of the system: /etc/init.d, /etc/rc*, /etc/inetd, ...).

But I believe that discussing about it being the main Gentoo's init system at this moment is pointless. First we need to get it running fine, then we need to get as many Gentoo developers as possible to ship SystemD units for their services, then we can write some docs to let others try more easily. JUST THEN we should go and push for "default init system".
   HOWEVER, as I asked the @gentoo.org, I'd like your consideration for a global use flag "systemd" and help to get services to ship with systemd unit files (ssh, apache, cron, cups, ...)

[Comment 57 hal 2010-09-19 18:48:45 UTC]

(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #46)
> > > Yes, network is up with connman. Actually to improve situation i disabled the
> > > udev rule from gentoo to start /etc/init.d/net.$IFNAME as I want to stay away
> > > from openrc (/etc/init.d/*) during these tests.
> > > 
> > > I've updated my stuff with a lengthly README.txt at
> > > http://barbieri-playground.googlecode.com/svn/gentoo/overlay/sys-apps/systemd/
> > > 
> > > After I get the patch to disable sysv compatibility in systemd I guess that
> > > ebuild is ready to be send to this bug.
> > > 
> > 
> > thanks for your efforts. maybe i didn't understand the whole system yet. i've
> > got to digg deeper into it.
> > but shouldn't network come up without conman, too? or is conman a necessary
> > dependency?
> 
> connman is like networkmanager, but simpler, faster. I'm helping development
> occasionally, the core developers are from intel/meego. It is simpler because
> it use less processes and depend less on the UI, they even provide lots of
> command line python utilities that gives you full control. It's faster because
> it even ships with a builtin (in process!) dhcp client, you can't believe how
> fast it gets IP after you plugin your ethernet cable.  It even does dns proxy,
> insteading of doing ugly hacks to maintain /etc/resolv.conf, all it does is
> direct to 127.0.0.1:53 and inside it knows about the routes and associated
> nameservers, doing the correct routing for you -- worth trying!
> 
> but all in all, you can have whatever you want as a bla.service, then link to
> this file from /etc/systemd/systemd/network.target.wants/bla.service.
> Everything that says "Want=network.target" will then bring up bla.service --
> connman.service in my case. That bla.service may be the same as
> /etc/init.d/net.eth0 for die-hard users of Gentoo network scripts.

ok, that brings some more light into my darkness. :)
i've got to check out conman on an occasion, this sounds realy interesting.

> > another thing. all filesystems in fstab fail to mount atm. all but the ones on
> > sda. certain directories are located on sdb, e.g. /var, /usr/portage, /usr/src
> > while /tmp and /var/log are in tmpfs.
> 
> You need autofs4 and devtmpfs. The first is used to automatically mount as you
> use (as opposed to mount immediately at start, so /home will just be mounted
> later on, when it's actually used). The second is used to have kernel to
> automatically mount /dev as a tmpfs and populate it.

i had this part in my mind already and doublechecked whether or not both options are enabled in my .config.

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

as you can see the needed configuration is present. therefore i can't imagine what's going wrong at this point.
atm i'm using baselayout2 and openrc. could this interfere with systemd in any way?

> Also, if you use /var/log as tmpfs you may not care about persistent logs,
> right? If that's the case (as is for me) you can remove
> metalog/rsyslog/syslog-ng/... and use systemd's kmsg-syslogd, it will redirect
> all /dev/log messages to 
>  /dev/kmsg (doing the proper formatting, with process name and so on). So it
> saves startup time and simplify maintenance :-)

exactly. my system server as an htpc. so there isn't any need for persistent logs. sounds quite interresting in this case. :)

[Comment 58 Gustavo Sverzut Barbieri 2010-09-19 20:05:13 UTC]

(In reply to comment #57)
> (In reply to comment #55)
> > (In reply to comment #54)
> > > (In reply to comment #46)
> > > another thing. all filesystems in fstab fail to mount atm. all but the ones on
> > > sda. certain directories are located on sdb, e.g. /var, /usr/portage, /usr/src
> > > while /tmp and /var/log are in tmpfs.
> > 
> > You need autofs4 and devtmpfs. The first is used to automatically mount as you
> > use (as opposed to mount immediately at start, so /home will just be mounted
> > later on, when it's actually used). The second is used to have kernel to
> > automatically mount /dev as a tmpfs and populate it.
> 
> i had this part in my mind already and doublechecked whether or not both
> options are enabled in my .config.
> 
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> 
> # CONFIG_AUTOFS_FS is not set
> CONFIG_AUTOFS4_FS=y
> 
> as you can see the needed configuration is present. therefore i can't imagine
> what's going wrong at this point.
> atm i'm using baselayout2 and openrc. could this interfere with systemd in any
> way?

that should be correct. I use baselayout2 and openrc myself, so that should not be a problem. Do you have your fs drivers as modules or built-in? Maybe have them as built-in and retry? You can also try from openrc to run, as root, "systemd --test --system" and check out the warnings there.

Anyway, better to join #systemd at irc.freenode.net.

[Comment 59 Matthias Gehre 2010-09-20 10:59:49 UTC]

It seems that you need to have the group "lock", so the var-lock.mount/var-lock.service can mount /var/lock to tmpfs on boot. (They use gid=lock)
Can that be added to the ebuild?

[Comment 60 Gustavo Sverzut Barbieri 2010-09-20 11:58:02 UTC]

(In reply to comment #59)
> It seems that you need to have the group "lock", so the
> var-lock.mount/var-lock.service can mount /var/lock to tmpfs on boot. (They use
> gid=lock)
> Can that be added to the ebuild?

I've added this to my ebuild, but I guess this is not his problem. At #systemd we got his /etc/fstab and seems that what is not being handled atm is his "bind" mounts. The developers added it to their todo.

[Comment 61 Steve Herber 2010-11-12 04:50:03 UTC]

Today I pulled a copy of systemd from:

http://barbieri-playground.googlecode.com/svn/gentoo/overlay/sys-apps/systemd/

and the configuration failed when checking for libnotify.
I installed libnotify by hand and systemd installed successfully.

I think libnotify should be added to the DEPENDS in the ebuild.  Thanks.

[Comment 62 Gustavo Sverzut Barbieri 2010-11-14 10:27:50 UTC]

Steve, thanks for pointing that out!

I've fixed my ebuild, also adding dbus-glib dependency for the gtk case. Actually systemd's configure.ac is wrongly always checking for that and I've sent a patch for it as well.

Also added a alert if FANOTIFY is not set in kernel config. It's not used by systemd's itself, but is by its readahead tool (which is disabled by default).

As people are having success with it, maybe we should consider asking the system-wide "systemd" use flag and start to add it to our daemons?

[Comment 63 Henry Gebhardt 2010-11-16 21:39:02 UTC]

Dear fellow Gentoo users,

There seem to be currently 3 ebuilds around for systemd.  I would like
to consolidate them into a common systemd overlay.  Basically, anyone
who asks on this bug would get commit access.

This would have the advantage of also serving as a central repository for
contributed .service files.  For this purpose I created a package
sys-apps/systemd-service-files.

So far I have merged the -9999 ebuilds from the keruspe,
barbieri-playground, and betagarden overlays, and added dbus and udev
with IUSE="systemd".

The overlay I propose is currently in the systemd branch of the kork
overlay, available at
git://git.overlays.gentoo.org/user/kork.git -b systemd

The next steps would be to:

    - Add more ebuilds with IUSE="systemd", or add .service files to
      sys-apps/systemd-service-files where upstream doesn't provide
      them.

    - Merge whatever makes sense upstream or into the main tree.  This
      would basically mean filing bugs against packages with patches for
      IUSE="systemd".

Besides consolidation, the purpose of the overlay would be to provide
both a "stable", that is, non-live version and a -9999 version of
systemd.  This means, that a user running ~arch shouldn't need to unmask
packages.

What do you think?  Would anyone participate?  Should I go forward with
the plan and ask about such an overlay at git.overlays.g.o?

Henry

[Comment 64 Gustavo Sverzut Barbieri 2010-11-17 01:45:32 UTC]

Henry, I really like this idea. SystemD's support is stable enough to move it out of my personal server to a broader public.

I'm not much interested in the maintenance of ebuilds myself, as a developer I really hate packaging. That's why I use Gentoo, the one that packaging sucks less ;-)  I can mail you whenever I spot configure options changed or some action is required, or I can apply for an account and modify those myself if you wish.

WRT your ebuilds, comments:
 - services-basic:
   - alsasound shouldn't be required these days.
   - lvm: better to not handle it like that, wait for SystemD's official support and block systemd with lvm until then. Remeber that systemd starts in parallel and you may not get the terminal for recovery and all with that way.
   - could you add my metalog.service?
   - could you add sshd* (socket, service, @.service), see Lennart's db.
 - services-desktop: 
    - most dbus services need changes to their respective dbus service file! Otherwise it is ineffective. See my systemd/files/dbus-system-services, look for SystemdService key.
   - do not need most of the "After=" keywords your services have. Remember that if the services themselves were declared correctly (dbus, socket, ...) then you gt automatic dependency and ordering as your service uses it (calling consolekit's dbus api will start consolekit.service)
   - PIDfile should be avoided whenever possible. SystemD's cgroup handling should be better and safer than that, particularly for non-forking services.
   - consolekit should ship with systemd support since 0.4.2-r4

All in all, I'd check the services with Lennart's http://0pointer.de/public/systemd-units/ or mine whenever they don't exist. If you have a new one, then mail the systemd-devel and Lennart said he's keen to help with reviewing and adopting it for his database so we don't get diverging implementations for every distro.

Last but not least, we should provide a QA helper that would trap doinitd and alert packages calling doinitd with "use systemd". Probably we could introduce a dosystemd?

[Comment 65 Peter Stuge 2010-11-17 15:58:33 UTC]

(In reply to comment #63)
> Would anyone participate?  Should I go forward with the plan and ask about
> such an overlay at git.overlays.g.o?

Please go for it. I'll try to help. Where do I send my key? If there's pushback (though I don't see why there would be) I'm happy to host a repo and give access, but I also think this should go to o.g.o.

[Comment 66 Christian Parpart (RETIRED) 2010-11-19 10:10:17 UTC]

Hey guys.

Is there any gentoo dev willing to peak into systemd getting into portage already?

Otherwise I would like to peak into it this weekend.

Many thanks,
Christian Parpart.

[Comment 67 Mike Pagano 2010-11-19 14:24:07 UTC]

(In reply to comment #66)
> Hey guys.
> 
> Is there any gentoo dev willing to peak into systemd getting into portage
> already?

On the systemd mailing list it was mentioned that Gregkh also offered his assistance to bring systemd into the tree.  But, of course, the more the merrier. Maybe reach out to him so you guys don't duplicate the effort.  And thanks!

[Comment 68 Robert Piasek (RETIRED) 2010-11-22 15:06:03 UTC]

Hi,

I would gladly help in bringing it to the tree as well.

[Comment 69 Christian Parpart (RETIRED) 2010-11-23 12:39:08 UTC]

systemd is (from the technical point of view) a very interesting piece of software.

However, I do not seem to get it up'n'running on all of my three desktop boxes (~amd64) due to some dbus oddities(!) and the upstream dev(s) refused to help since they rather blamed the distribution in use and their use of customization than helping with hints. Today I got it working on my server, very strange, as I did not expect it to be working :)

Finally, I'd like to state, that while systemd is a very nice thing, I want to vote for providing full support of systemd in our git overlay for it, that is, no sysv init scripts as they just make things difficult, since the gentoo rc scripts come with their own dependency system, which makes it just back slow again.

So why not converting the core part to systemd?
I'm especially talking about net networking (not just NetworkManager) init scripts and dependancies like apache2 and friends.

The question remains, what do you think about or why would you want to stick with the current sysv-like init scripts even when switching to systemd?

Beside all of that, util-linux will need a patch to support preserving serial line speed (via command line option -s) which I have a patch around (found in the net), and sys-process/audit will need an upgrade too in order to not break compilation with audit use-flag enabled.

[Comment 70 Gustavo Sverzut Barbieri 2010-11-23 14:35:17 UTC]

Hi Chris,

The networking bits have no reason to be in openrc, it can be easily split if required.

util-linux should be the git version until they do a release, fsck got a new flag that is used by systemd (they required the new flag to be added AFAIK).

Apache, sshd and others: the plan is to coordinate with systemd devs and upstreams to have the services into the sources. There is no point into having per-distro scripts anymore. That is one of the goals of systemd. It also gets ride of messy /etc/conf.d (/etc/sysconfig, etc) requirements.

[Comment 71 Henry Gebhardt 2010-11-23 16:33:16 UTC]

Sorry for replying a bit late, but we have a systemd overlay at g.o.g.o
now!  All devs have fast-forward-only commit access, and if you want to,
too, send me your public ssh key, and I will forward that to the g.o.g.o
maintainers.  So here it is:

    http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=summary

(In reply to comment #64)
Gustavo, thanks for your suggestions.  I didn't know about Lennart's db,
and the dbus stuff.  I have only gotten to fixing the overlay as to your
suggestions for services-basic.  For the dbus stuff, I guess
IUSE="systemd" ebuilds will need to be added, because I don't think
there is a clean way to append to files belonging to a different
package.

Other than that, I have renamed sys-apps/systemd-service-files to
sys-apps/systemd-units, as that seems more appropriate, and I have added
the ssh* units from Lennart's db.

Is vala detection working for anyone?  I had some troubles with the
configure script that I need to investigate further.  It didn't find
vala-0.12, but not using portage the error wasn't fatal with
--disable-gtk, but with the ebuild it is.

(In reply to commen #69)
It seems you are using USE=+sysv.  I haven't tested that, and I think as per
Gustavo's comment that that should just go away.

[Comment 72 Canek Peláez Valdés 2010-11-23 16:53:01 UTC]

Vala install it's binary as ${prefix}/bin/valac-${VERSION}, and the systemd configure script expects valac (without the version) to be in the PATH. If you export the VALAC variable to the right executable, everything works; no idea how to configure it for portage, but it's probably easy to do inside the systemd ebuild.

[Comment 73 Cesar Garcia 2010-11-23 23:24:50 UTC]

(In reply to comment #71)
Good to see that there is a unified systemd overlay :). Please, you can add
--localstatedir=${EPREFIX}/var
to the econf phrase? Without it pam_systemd.so is broken because it tries to create its directories under /var/lib/run/user instead of /var/run/user.

At last, maybe is a good idea to delete the symlink at /lib/systemd/system/graphical.target.wants/display-manager.service (it calls init.d scripts and not everyone wants a X session started by default, besides systemd fails to disable that unit so one has to delete the symlink by hand :/)

Those two issues are the only things that keeps me using a local overlay instead  the ones at g.o.g.o.

[Comment 74 Matthias Gehre 2010-11-25 17:52:00 UTC]

I get
 * Detected file collision(s):
 * 
 * 	/lib/systemd/system/avahi-daemon.service
 * 	/lib/systemd/system/console-kit-daemon.service
 * 	/lib/systemd/system/avahi-dnsconfd.service
 * 
 * Searching all installed packages for file collisions...
 * 
 * Press Ctrl-C to Stop
 * 
 * sys-auth/consolekit-0.4.2-r4
 * 	/lib/systemd/system/console-kit-daemon.service
 * 
 * net-dns/avahi-0.6.28
 * 	/lib/systemd/system/avahi-daemon.service
 * 	/lib/systemd/system/avahi-dnsconfd.service
 * 
 * Package 'sys-apps/systemd-units-9999' NOT merged due to file
 * collisions. If necessary, refer to your elog messages for the whole
 * content of the above message.
with the latest systemd at o.g.o.
Consolekit and avahi are from the official gentoo tree.

[Comment 75 Canek Peláez Valdés 2010-12-03 01:38:37 UTC]

In my laptop (a VAIO Core 2 Duo), I have the following problems with Systemd from the overlay:

* the fsck-root.service unit fails because my root partition is ext3, and fsck.ext3 does not recognize the options -M and -T, and the -l option needs a file with badblocks. This leads to Systemd to go into emergency mode.
* The killall.service unit fails because the ExecStart command is actually 3 commands, but the whole line is wrapped by quotes, and Systemd refuse to execute it. This causes reboot, poweroff and halt to fail.

Also, the udev ebuild from the overlay, and the ebuilds for NetworkManager and Bluez from the portage tree installs udev rules and/or scripts which call services from /etc/init.d, causing the whole OpenRC stack to be called, and slowing down (several minutes in the case of my laptop) my boot time.

I will provide patches for each one of this issues in my next comments. Each patch can be applied to the overlay independently (except for the patches for fsck and killall, because both change the Manifest for the systemd-9999 ebuild; I will provide a single patch for this two problems).

With this patches, my Gentoo Laptop works perfectly, as it did with OpenRC. But with the cooler Systemd.

I didn't know if this bug is the proper place to send the patches, but I don't want to send them to the systemd mail list, given that they are Gentoo related.

[Comment 76 Canek Peláez Valdés 2010-12-03 01:40:19 UTC]

Created attachment 256198 [details]
systemd-fsck-root..patch

Patch to remove the -l, -M and -T flags of fsck. ext3.fsck does not accept the -M and -T flags, and the -l flags expects a files with  badblocks. If the root artition is ext3, without the patch Systemd fails to boot when /sbin/fsck fails.

[Comment 77 Canek Peláez Valdés 2010-12-03 01:41:08 UTC]

Created attachment 256199 [details]
killall-gentoo.patch

Patch so the killall.service unit works in Gentoo.

[Comment 78 Canek Peláez Valdés 2010-12-03 01:42:11 UTC]

Created attachment 256201 [details]
udev-no-openrc.patch

Patch to avoid the installation of rules and scripts which call /etc/init.d scripts.

[Comment 79 Canek Peláez Valdés 2010-12-03 01:43:04 UTC]

Created attachment 256202 [details]
networkmanager-systemd.patch

NetworkManager ebuild with systemd use flag that applies a patch that avoids the use of /etc/init.d scripts in the Gentoo backend.

[Comment 80 Canek Peláez Valdés 2010-12-03 01:44:07 UTC]

Created attachment 256203 [details]
bluez-systemd.patch

Bluez ebuild with systemd use flag that avoid the installation of rules or scripts that call /etc/init.d scripts. It also contains a working bluetooth.service unit.

[Comment 81 Canek Peláez Valdés 2010-12-03 01:45:48 UTC]

Created attachment 256205 [details]
killall-gentoo-systemd-fsck-root.patch

Patch to remove the -l, -M and -T flags of fsck. ext3.fsck does not accept the -M and -T flags, and the -l flags expects a files with badblocks. If the root partition is ext3, without the patch Systemd fails to boot when /sbin/fsck fails. Also, patch the killall.service unit so it works in Gentoo. This patch is the combination (without conflicts) of patches 256198 and 256199.

[Comment 82 Peter Stuge 2010-12-03 01:56:53 UTC]

(In reply to comment #76)
> Created an attachment (id=256198) [details]
> Patch to remove the -l, -M and -T flags of fsck.

I don't agree with this patch. The service runs /sbin/fsck, which is documented to support at least -M -T in my man page.

> ext3.fsck does not accept the -M and -T flags, and the -l flags expects a
> files with badblocks. If the root artition is ext3, without the patch
> Systemd fails to boot when /sbin/fsck fails.

It seems that this is a problem in fsck rather than the .service.

[Comment 83 Canek Peláez Valdés 2010-12-03 02:08:33 UTC]

(In reply to comment #82)
> I don't agree with this patch. The service runs /sbin/fsck, which is documented to support at least -M -T in my man page.

It's documented in my man page also. But it doesn't work; I'm only trying to make my system boot.

> It seems that this is a problem in fsck rather than the .service.

Probably; util-linux has version 2.17.2 in the portage tree, with the documented -M and -T flags. e2fsprogs has version 1.41.12-r1, which is the last version available in http://e2fsprogs.sourceforge.net/, and it doesn't support -M or -T.

I don't know how to solve the problem in the e2fsprogs ebuild, but I do know how to solve it in the systemd ebuild.

I'm not (necessarily) pushing my patches for inclusion in the overlay. They just work for me, and I put them here in case someone else find them useful.

[Comment 84 jackieku 2010-12-03 02:21:25 UTC]

(In reply to comment #83)
> Probably; util-linux has version 2.17.2 in the portage tree, with the
> documented -M and -T flags. e2fsprogs has version 1.41.12-r1, which is the last
> version available in http://e2fsprogs.sourceforge.net/, and it doesn't support
> -M or -T.

I suppose the problem here is the -l flag, since it is not documented in fsck(8). fsck doesn't pass all options to the backend (fsck.ext3) as is, so -M and -T should not be the problem (openrc's /etc/init.d/fsck uses -T).

[Comment 85 Canek Peláez Valdés 2010-12-03 06:44:44 UTC]

(In reply to comment #84)
[...]
> I suppose the problem here is the -l flag, since it is not documented in
> fsck(8). fsck doesn't pass all options to the backend (fsck.ext3) as is, so -M
> and -T should not be the problem (openrc's /etc/init.d/fsck uses -T).

Certainly I tried removing only the -l flag, and fsck-root.service worked. I'll attach a new patch.

[Comment 86 Canek Peláez Valdés 2010-12-03 06:49:41 UTC]

Created attachment 256209 [details]
systemd-fsck-root..patch

Patch to remove the -l flag from fsck. /sbin/fsck does not accept this flag; without the patch Systemd goes into emergency mode.

[Comment 87 Henry Gebhardt 2010-12-03 13:35:05 UTC]

So, systemd-15 is out and in the overlay since a week ago or so.  Many
thanks to Thilo Bangert for finding mistakes in the ebuilds.

You may have noticed that I removed the EPREFIX stuff.  If you need it,
feel free to go ahead and add that.

Also, I am tending towards removing the systemd USE flag, and instead
print an elog message with a list of packages that need to be remerged
and that in the future should just unconditionally install the unit
files.

Also, I would welcome if someone wants to take over the -9999 ebuild, as
I am more interested in something slightly more stable.

(In reply to comment #64)
I don't know a really good solution how to append the dbus service files
with the relevant SystemdService entries, as those files generally
belong to the respective package.  Anyone?

(In reply to comment #72)
Thanks, VALAC is exported now.

(In reply to comment #73)
Thanks for the report, indeed systemd expects /var rather than /var/lib,
so fixed.

The display-manager.service disappeared, since xdm.service is no longer
installed.  While I think that is good, I am a bit unclear whether it is
better to have one service that chooses the DM, or to have multiple unit
files, and choose the service by systemctl.  I am leaning towards the
latter.

(In reply to comment #74)
Thanks for the report, I added consolekit-0.4.3 and avahi-0.6.28 with
IUSE=systemd to the overlay, and removed the respective files from
systemd-units.  NetworkManager is also installing a service file now,
but I'd like more information on comment #79, too.

(In reply to comment #75)
Thanks for your work.  See specific comments below.

(In reply to comment #86)
The -l actually is only part of an as yet unreleased version of
util-linux.  If fsck doesn't know an option it passes the option on to
fsck.ext{2,3,4}, where they may have different meanings.  The patch
files/0001-Revert-Revert-Revert-*.patch fixes that already, but it is
only applied to the version 15 ebuild.  By the name of that patch you
can tell, that upstream actually went back-and-forth a little on that
one :-)

(In reply to comment #77)
Right, is killall.service actually needed?  Are poweroff.service and
reboot.service still needed?  Otherwise the patch looks good.

(In reply to comment #78, comment #79, and comment #80)
udev, NetworkManager, and bluez.  Neat , I'll have to investigate your
patches a bit more.  Thanks.

[Comment 88 Canek Peláez Valdés 2010-12-03 16:15:50 UTC]

(In reply to comment #87)
[...]
> Also, I am tending towards removing the systemd USE flag, and instead
> print an elog message with a list of packages that need to be remerged
> and that in the future should just unconditionally install the unit
> files.

It would be awesome if Systemd and OpenRC could exist side-by-side, but I don't think that's the case; at least not with some ebuilds in the portage tree. As I mentioned in my message before my patches, *at least* udev, NetworkManager and bluez unconditionally call sutff in /etc/init.d.

udev installs the net.sh (which calls /etc/init/net.*) and move_tmp_persistent_rules.sh (which sources /etc/init.d/funcions.sh); bluez installs bluetooh.sh (which calls /etc/init.d/bluetooth), and NetworkManager calls /etc/init.d/net.lo hardcoded in src/backends/NetworkManagerGentoo.c.

In my (admittedly not very fast) latop, *any* call to OpenRC brings with it the whole stack, and in some cases that delays my boot for several minutes. I don't know exactly what happens; I think some script from OpenRC gets stuck in a "starting" state, and others wait for it until it timeouts. I don't know; but I think the *easiest* way to deal with this is to have a USE flag that allows us to get rid of OpenRC completely.

> (In reply to comment #86)
> The -l actually is only part of an as yet unreleased version of
> util-linux.  If fsck doesn't know an option it passes the option on to
> fsck.ext{2,3,4}, where they may have different meanings.  The patch
> files/0001-Revert-Revert-Revert-*.patch fixes that already, but it is
> only applied to the version 15 ebuild.  By the name of that patch you
> can tell, that upstream actually went back-and-forth a little on that
> one :-)

Cool; then soon the patch will be redundant.

> (In reply to comment #77)
> Right, is killall.service actually needed?  Are poweroff.service and
> reboot.service still needed?  Otherwise the patch looks good.

Without killall.service, my laptop does not reboot nor poweroff. I haven't looked deeply at it.

> (In reply to comment #78, comment #79, and comment #80)
> udev, NetworkManager, and bluez.  Neat , I'll have to investigate your
> patches a bit more.  Thanks.

Again, the patches only remove unconditional calls to the OpenRC stack. At least in my laptop that's mandatory if I want to have a reasonable boot time.

[Comment 89 Jimmy Kloss 2010-12-03 19:51:58 UTC]

(In reply to comment #87)
> Right, is killall.service actually needed?  Are poweroff.service and
> reboot.service still needed?  Otherwise the patch looks good.

systemd brings it's own {reboot,poweroff}.service which directly call systemd instead of /sbin/reboot and /sbin/shutdown. killall.service is also not needed anymore.

Here you can check for all default/needed untis
http://cgit.freedesktop.org/systemd/tree/units

(In reply to comment #88)
> Without killall.service, my laptop does not reboot nor poweroff. I haven't
> looked deeply at it.

That's because the overlay installs the obsolete {reboot.poweroff}.service files which still call killall.service and will fail if it's not there.


The bottom line 
- Please remove obsolete custom {killall,reboot,poweroff}.service files
- Keep up the migration to systemd :-)

[Comment 90 Henry Gebhardt 2010-12-04 14:56:33 UTC]

(In reply to comment #89)
Thanks for the clarification.  Custom {killall,poweroff,reboot}.service
files are gone now.

(In reply to comment #88)
> [...]
> It would be awesome if Systemd and OpenRC could exist side-by-side,
> but I don't think that's the case

For udev I think it is possible to have systemd and openrc side-by-side.
See the patch I will attach in a moment.  Does that work?  Is
move_tmp_persistent_rules.sh needed, or can we just exit from that, too?

> [..., -l flag...]

I applied the patch also in the -9999 ebuild, so we don't need to wait
for util-linux-2.19.  The -l flag will make parallel checking of file
systems more efficient.

[Comment 91 Henry Gebhardt 2010-12-04 15:06:26 UTC]

Created attachment 256319 [details, diff]
udev: Don't load openrc if running systemd

This patch enables a parallel installation of openrc and systemd, without loading much of openrc while on systemd.

[Comment 92 Roland Jax 2010-12-04 17:26:50 UTC]

emerge: there are no ebuilds to satisfy ">=x11-libs/libnotify-0.7.0".
(dependency required by "sys-apps/systemd-15" [ebuild])
(dependency required by "systemd" [argument])

Which Overlay (suka or keruspe) should be used to satisfy this dependency? 

[Comment 93 Canek Peláez Valdés 2010-12-04 19:00:41 UTC]

(In reply to comment #92)
> emerge: there are no ebuilds to satisfy ">=x11-libs/libnotify-0.7.0".
> (dependency required by "sys-apps/systemd-15" [ebuild])
> (dependency required by "systemd" [argument])
> 
> Which Overlay (suka or keruspe) should be used to satisfy this dependency? 

I think the easiest solution is to remove the gtk use flag in systemd. That's what I'm doing right now.

[Comment 94 Canek Peláez Valdés 2010-12-04 20:15:57 UTC]

(In reply to comment #91)
> Created an attachment (id=256319) [details]
> udev: Don't load openrc if running systemd

The patch works as intended; this makes redundant my udev patch. Thanks.

[Comment 95 Canek Peláez Valdés 2010-12-04 20:28:43 UTC]

(In reply to comment #89)
> The bottom line 
> - Please remove obsolete custom {killall,reboot,poweroff}.service files
> - Keep up the migration to systemd :-)

Exactly; with the latest systemd, *almost* everything works as expected. The only thing missing is the shutdown.service unit (I can't find it anywhere). I created a really simple one that calls /lib/systemd/systemd-shutdown, and everything works as expected. I'll attach it next.

[Comment 96 Canek Peláez Valdés 2010-12-04 20:29:44 UTC]

Created attachment 256349 [details]
shutdown.service

Shutdown service unit; it simply calls /lib/systemd/systemd-shutdown

[Comment 97 Canek Peláez Valdés 2010-12-04 20:34:14 UTC]

I marked as obsolete my patches, thanks to comment #89, comment #90, and comment #91.

[Comment 98 Canek Peláez Valdés 2010-12-04 20:55:06 UTC]

Created attachment 256351 [details, diff]
networkmanager-no-openrc.patch

With NetworkManager-0.8.2-r1, the NetworkManager.service unit is included in upstream. However, the Gentoo backend keeps calling /etc/init.d/net.lo to get up the lo interface. This NetworkManager ebuild has a systemd use flag that applies a patch avoiding this.

[Comment 99 Canek Peláez Valdés 2010-12-04 21:03:00 UTC]

Created attachment 256352 [details]
procps-ps-cgroups.patch

Ebuild for procps that applies a couple of patches (originally from Fedora) so ps can output cgroups information. With this, we can use in Gentoo the "ps xaf -eo pid,user,args,cgroup" example from http://0pointer.de/blog/projects/systemd.html

I don't know if this bug is the correct place to place this ebuild, but I can't think of any other place.

[Comment 100 Henry Gebhardt 2010-12-05 00:38:04 UTC]

(In reply to comment #95, comment #96)
> The
> only thing missing is the shutdown.service unit (I can't find it anywhere).

Seems like we were hunting the same bug... :-)  Actually, the only
services expecting shutdown.service are from consolekit, which upstream
has already fixed to shutdown.target in their git version.  I added the
patch to consolekit in the systemd overlay, with a revbump.

Hm, reboot works fine here, but shutdown hangs.  Somebody else have this
problem?

(In reply to comment #94)
Hm, move_tmp_persistent_rules.sh is never called by anything, in either
openrc or systemd?  Can someone confirm?

(In reply to comment #98)
Can you make this patch also work with openrc?  Like, opening
/proc/1/comm and enter 'nm_generic_enable_loopback()' if it says
systemd, otherwise spawn the /etc/init.d/net.lo thing.  That would be
great.

Also, could you post diffs relative to the version in the main tree,
rather than whole ebuilds.  That makes it easier to read and spot the
differences :)

(In reply to comment #80)
bluez.  Can you make your patch also work with openrc?  Thanks.

(In reply to comment #99)
Thanks for gathering the procps patches.  Do you know what the upstream
status is?  Have they been or will they be merged?  I would also rather
file a separate bug, because this is not directly related to systemd.

[Comment 101 Canek Peláez Valdés 2010-12-05 18:30:05 UTC]

(In reply to comment #100)
[...]
> Seems like we were hunting the same bug... :-)  Actually, the only
> services expecting shutdown.service are from consolekit, which upstream
> has already fixed to shutdown.target in their git version.  I added the
> patch to consolekit in the systemd overlay, with a revbump.
> 
> Hm, reboot works fine here, but shutdown hangs.  Somebody else have this
> problem?

Yes; I do. I have no idea what's causing it. But I will mark as obsolete my shutdown.service patch.

[...]
> (In reply to comment #98)
> Can you make this patch also work with openrc?  Like, opening
> /proc/1/comm and enter 'nm_generic_enable_loopback()' if it says
> systemd, otherwise spawn the /etc/init.d/net.lo thing.  That would be
> great.

I hadn't thought about it; it's actually the right thing to do, I think. I will try to have it ready later today.

> Also, could you post diffs relative to the version in the main tree,
> rather than whole ebuilds.  That makes it easier to read and spot the
> differences :)

I'll do that, but I thought that it will be easier for people to try the new versions by simply applying the patches to the systemd git overlay, probably in their own private branches.

> (In reply to comment #80)
> bluez.  Can you make your patch also work with openrc?  Thanks.

I suppose I can try the same approach that you took for the udev ebuild. I will try.

> (In reply to comment #99)
> Thanks for gathering the procps patches.  Do you know what the upstream
> status is?  Have they been or will they be merged?  I would also rather
> file a separate bug, because this is not directly related to systemd.

I have no idea what's the status of upstream procps; but I think the patch will make ps fail if it is called with the cgroups output option. So I don't think it will be added to upstream any soon; a use flag seems to be the right approach.

But you're right, I will open a new bug for cgroups support in procps.

Thanks for the suggestions.

[Comment 102 Canek Peláez Valdés 2010-12-05 18:30:49 UTC]

Comment on attachment 256349 [details]
shutdown.service

Marked obsolete by the new consolekit ebuild.

[Comment 103 Canek Peláez Valdés 2010-12-05 21:40:20 UTC]

Created attachment 256435 [details]
bluez-systemd-and-openrc.patch

This patch allows bluez to be used with systemd and OpenRC in parallel, by detecting at run time with which one is running.

[Comment 104 Canek Peláez Valdés 2010-12-05 21:42:47 UTC]

Created attachment 256437 [details]
bluetooth.service

Bluetooth service unit file. The bluez ebuild should install it unconditionally.

[Comment 105 Canek Peláez Valdés 2010-12-05 21:44:23 UTC]

Created attachment 256439 [details]
networkmanager-0.8.2-openrc-and-systemd.patch

Patch that allows NetworkManager to be used by systemd and OpenRC in parallel, by detecting at runtime with which one is running.

[Comment 106 Canek Peláez Valdés 2010-12-05 21:47:25 UTC]

Comment on attachment 256352 [details]
procps-ps-cgroups.patch

I filled another bug for procps: bug #347840.

[Comment 107 Canek Peláez Valdés 2010-12-05 21:50:13 UTC]

With the patches from comment #103, comment #104 and comment #105, my laptop is able to boot using both systemd and OpenRC, without any of them stepping into the other. The patches were only tested in my laptop, but I believe both are simple enough to check only by looking at them.

Thanks again to Henry for the suggestions.

[Comment 108 Jason A. Donenfeld 2010-12-05 22:09:16 UTC]

While I applaud the effort to allow simultaneous openrc and systemd installations, it seems like any implementation will necessarily introduce undesired overhead into the boot/udev process. Starting those shell scripts and forking all those commands will only add extra tax, which is precisely one of the things systemd was built to avoid. Furthermore, it does not make sense to install both openrc and systemd on the same system; there is no use case. One package SHOULD block the other.

For these reasons, it seems like rather than investing this time into developing slow hacks (which probably won't even be ever accepted into the main tree) that require shell scripts to uselessly be spawned, we should instead have the two packages block each other, and focus on streamlining everything. A systemd in Gentoo will only be achieved once there is a true native solution that supposes systemd's primacy. Any intermediate solutions will result in systemd always being a second-class citizen.

[Comment 109 Canek Peláez Valdés 2010-12-05 22:54:59 UTC]

I beg to differ; going the "systemd or nothing" route will slow down systemd adoption, specially among those users who only want to try it out and still go back to OpenRC if that is what they want.

Besides, my NetworkManager patch does not create any new process (it checks if we are running systemd inside the main process), and the scripts that Henry and I patched only call test, ps, logger and the shell script itself (if we are running systemd). That's 4 processes for script, and in my laptop the scripts are called exactly 4 times:


# dmesg | grep "You are using systemd"
/lib64/udev/net.sh[388]: You are using systemd, exiting. (wlan0 start)
/lib64/udev/bluetooth.sh[387]: You are using systemd, exiting. (bluetooth.sh)
/lib64/udev/net.sh[385]: You are using systemd, exiting. (eth0 start)
systemd/lib64/udev/net.sh[386]: [1]: Running GC...You are using systemd, exiting. (lo start)

That's 16 processes. I think that's a small price to pay for the benefit of being able to boot to systemd or OpenRC as the user wishes.

[Comment 110 Canek Peláez Valdés 2010-12-05 22:57:16 UTC]

Oh, and other thing: Lennart himself designed systemd to be a drop-in replacement for SysInitV. They can (and do) coexist.

It's just that we can't take advantage of that in Gentoo because OpenRC != SysInitV.

[Comment 111 Canek Peláez Valdés 2010-12-05 23:17:30 UTC]

Created attachment 256446 [details]
networkmanager-0.8.2-openrc-and-systemd.patch

Forgot to add sentinel to the g_strconcat function call in the NetworkManager patch. Sorry for the attachment spam.

[Comment 112 Robert Piasek (RETIRED) 2010-12-06 15:00:15 UTC]

While I personally prefer to replace sysv+openrc with systemd, I can see Canek's point.

I added networkmanager with Canek's patch to the overlay.

[Comment 113 Robert Piasek (RETIRED) 2010-12-06 15:40:28 UTC]

Hi,

Canek's patch was committed to NM master and 0.8 branch:

master:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=740dc88cb3db3f910948e50b9340016ab8c5e84c

abfea5a7008396960791d6312d1f787e89f9f4d8 (0.8.x)
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8&id=abfea5a7008396960791d6312d1f787e89f9f4d8

courtesy of Dan Williams (NM maintainer).

[Comment 114 Henry Gebhardt 2010-12-06 22:07:54 UTC]

(In reply to comment #103, #104)
I checked in bluez-4.80 with your patches.  Note that I am not able to
test these properly.  I first checked in vanilla from the main tree, and
then applied your patches.  I think that makes it easier when going
upstream.  All we need to do then is to gather the patches since that
first copy to the overlay.

(In reply to comment #108)
> it seems like any implementation will necessarily introduce
> undesired overhead into the boot/udev process.

I am with Canek's comment #109 that this is a small price to pay.  I,
for one, still boot into openrc sometimes.  Maybe we could introduce an
optimization use flag that removes the undesired udev rules.  I would
apply such a patch.

(In reply to comment #111, #112, #113)
The networkmanager patch seems more complicated than necessary, and
could be simplified using the g_file_get_contents() function reading
directly into 'comm'.  I think it is safe to assume that the format of
/proc/1/comm will be only one line that doesn't change.  Am I missing
something?

[Comment 115 Robert Piasek (RETIRED) 2010-12-07 14:35:26 UTC]

I saw that bluetooth was added. Could you please make sure systemd stuff is enabled ONLY when systemd use flag is enabled?

[Comment 116 Mehmet Giritli 2010-12-07 15:03:14 UTC]

> 
> I am with Canek's comment #109 that this is a small price to pay.  I,
> for one, still boot into openrc sometimes.  Maybe we could introduce an
> optimization use flag that removes the undesired udev rules.  I would
> apply such a patch.
> 

A use flag to choose between a strict systemd system or a mixed system is definitely the way to go. People should have the choice to be able to use systemd on a Gentoo system as it is intended to be.

[Comment 117 Matthias Gehre 2010-12-08 10:26:14 UTC]

The dhcpcd.service currently assumes that you have "background" in your dhcpcd.conf, as it calls dhcpcd -v and assumes that it will fork. This breaks on machines where you do not have "background" in your dhcpcd.conf as systemd will kill dhcpcd after a timeout.

But I think forking is not recommended for systemd at all, so please
change dhcpcd.service to
Type=simple
ExecStart=/sbin/dhcpcd -q --nobackground

[Comment 118 Canek Peláez Valdés 2010-12-09 01:14:54 UTC]

(In reply to comment #114)
[...]
> (In reply to comment #111, #112, #113)
> The networkmanager patch seems more complicated than necessary, and
> could be simplified using the g_file_get_contents() function reading
> directly into 'comm'.  I think it is safe to assume that the format of
> /proc/1/comm will be only one line that doesn't change.  Am I missing
> something?

You're right; the patch is unnecessarily complex. I'll attach a simplified version that uses g_file_get_contents.

[Comment 119 Canek Peláez Valdés 2010-12-09 01:27:29 UTC]

Created attachment 256698 [details]
networkmanager-0.8.2-openrc-and-systemd.patch

Simplified version of the patch that allows NetworkManager to decide at runtime if its running with OpenRC or systemd.

[Comment 120 Henry Gebhardt 2010-12-09 16:28:32 UTC]

(In reply to comment #119)
> Created an attachment (id=256698) [details]
> networkmanager-0.8.2-openrc-and-systemd.patch
> 
> Simplified version of the patch that allows NetworkManager to decide at runtime
> if its running with OpenRC or systemd.
> 

Some small notes:
  - You don't need to include gio.h
  - BUFFER_SIZE can go
  - If g_strstr_len handles comm=NULL gracefully (like g_strcmp0), then you could drop the first if-statement.

But that's in a way just nitpicking.  The patch looks good.  I will apply it to the overlay.

[Comment 121 Claer 2010-12-10 11:44:31 UTC]

I tried to compile NetworkManager from the systemd overlay. Currently it's failing with the following error at ./configure. Did I miss something ?

[root@papillon 2176 /var/tmp/portage/net-misc/networkmanager-0.8.2-r2/work/NetworkManager-0.8.2]# ./configure '--disable-more-warnings' '--localstatedir=/var' '--with-distro=gentoo' '--with-dbus-sys-dir=/etc/dbus-1/system.d' '--with-udev-dir=/etc/udev' '--with-iptables=/sbin/iptables' '--enable-gtk-doc' '--with-docs' '--with-resolvconf' '--without-systemdsystemunitdir=/lib/systemd/system' '--with-dhcpcd' '--without-dhclient' '--with-crypto=nss'
configure: error: invalid package name: systemdsystemunitdir=/lib/systemd/system

[Comment 122 Canek Peláez Valdés 2010-12-10 16:38:35 UTC]

(In reply to comment #121)
[...]
> configure: error: invalid package name:
> systemdsystemunitdir=/lib/systemd/system

You need to compile NetworkManager (and a couple of other packages) with the systemd use flag. Apparently some ebuilds with the --with-systemdsystemunitdir flag fail when you don't provide the systemd use flag.

[Comment 123 Henry Gebhardt 2010-12-12 15:55:38 UTC]

(In reply to comment #122)
> (In reply to comment #121)
> [...]
> > configure: error: invalid package name:
> > systemdsystemunitdir=/lib/systemd/system

Thanks for the report.  Almost all other packages in the overlay were doing it wrong, too.  Fixed, now.

[Comment 124 Claer 2010-12-12 21:09:36 UTC]

I tested with and without systemd use flag. It compiles fine now. Thanks

[Comment 125 Matthias Gehre 2010-12-17 08:49:30 UTC]

Could you please apply the following patch, as to my understanding dbus-based starting is preferred for systemd?
--- 1/wpa_supplicant.service	2010-12-12 23:45:40.939187001 +0100
+++ 2/wpa_supplicant.service	2010-10-14 13:46:06.344742004 +0200
@@ -2,9 +2,10 @@
 Description=WPA supplicant
 
 [Service]
-Type=forking
-ExecStart=/usr/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -B -P /var/run/wpa_supplicant.pid
-PIDFile=/var/run/wpa_supplicant.pid
+Type=dbus
+BusName=fi.epitest.hostap.WPASupplicant
+ExecStart=/usr/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -u -iwlan0
+StandardOutput=syslog
 
 [Install]
 WantedBy=graphical.target

[Comment 126 Matthias Gehre 2010-12-17 09:49:51 UTC]

syslog-ng does not support socket activiation yet, so using the syslog-ng.socket from systemd-units will result in breakage at different places. For me, dhcpcd would stop working, as it blocked on writing to the syslog.

Using syslog-ng.service directly does work as expected.

So we should remove syslog-ng.socket until this is fixed. Maybe someone can port the socket activiation to syslog-ng. A (short) patch for rsyslog can be found 
here: https://bugzillafiles.novell.org/attachment.cgi?id=404504

[Comment 127 Henry Gebhardt 2010-12-18 00:10:24 UTC]

(In reply to comment #125)
> Could you please apply the following patch, as to my understanding dbus-based
> starting is preferred for systemd?

Thanks for pointing this out, I added wpa_supplicant to the systemd overlay so that the dbus service file could also be updated properly. You still need to enable dbus activation by creating the symlink

    /etc/systemd/system/dbus-fi.epitest.hostap.WPASupplicant.service -> /lib64/systemd/system/wpa_supplicant.service

[Comment 128 Gustavo Sverzut Barbieri 2010-12-22 11:47:53 UTC]

Please remove the tmpwatch dependency from systemd.ebuild, it's not required for a long time already, replaced with an internal systemd code.

[Comment 129 Gustavo Sverzut Barbieri 2010-12-22 13:09:59 UTC]

Ouch! Major bug made my boot with systemd impossible on amd64! I'm not using multilib, but I doubt it would matter.

Problem is that systemd installs and reads to /lib/systemd, while everything else installs to /lib64/systemd, thus none of systemd-units services or packages supporting native systemd units will work as they end at /lib64.  I recall having similar problems with udev in the past, which I "solved" by making /lib/udev -> /lib64/udev.

[Comment 130 Canek Peláez Valdés 2010-12-22 22:43:40 UTC]

(In reply to comment #129)
[...]
> Problem is that systemd installs and reads to /lib/systemd, while everything
> else installs to /lib64/systemd

Mmmmh. Can't you link /lib64 to /lib (or viceversa)?

[Comment 131 Gustavo Sverzut Barbieri 2010-12-23 01:24:21 UTC]

I just did this link for /lib64/systemd -> /lib/systemd, but this is not the correct solution... just a hack.

What we need is to either force systemd to install to /lib64 or force --with-systemdunitsdir=/lib/systemd. Given that kernel is installed to /lib/modules, and all systemd docs will refer to /lib, I guess the second is easier.

[Comment 132 Gustavo Sverzut Barbieri 2010-12-23 02:07:09 UTC]

Ok, system is booting but I managed to find few problems with existing services:

 - /lib/systemd/system/wpa_supplicant.service is not the name in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service SystemdService, so systemd-dbus activation will not work.  I renamed my SystemdService entry to wpa_supplicant.service

 - many Type=forking could (and should) be avoided. For instance, vixie-cron can be started with -n.  This is recommended not just to avoid excess process being forked, but also to let systemd manage the lifecycle. Particularly with cron, that spawn children, if the daemon dies but there are other children alive, the cgroup is not empty thus systemd will not detect it needs to be restarted.

[Comment 133 Henry Gebhardt 2010-12-23 10:11:22 UTC]

(In reply to comment #129)
> Problem is that systemd installs and reads to /lib/systemd, while everything
> else installs to /lib64/systemd

Yeah, good point.  I made it so that they install into /lib.  What I find a bit weird
is that systemd also installs binaries into /lib, where I was under the impression
that architecture dependent code should go into /lib64.

(In reply to comment #132)
>  - /lib/systemd/system/wpa_supplicant.service is not the name in
> /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service
> SystemdService, so systemd-dbus activation will not work.  I renamed my
> SystemdService entry to wpa_supplicant.service

You need to create the symlink

    /etc/systemd/system/dbus-fi.epitest.hostap.WPASupplicant.service -> /lib64/systemd/system/wpa_supplicant.service

It wont (shouldn't) if it isn't needed.  For something very similar, see bug #347517.

[Comment 134 Gustavo Sverzut Barbieri 2010-12-23 10:30:24 UTC]

Thanks about the eclass fix.

As for /lib, I'll try to remember to ask Lennart, but I guess it's because autoconf will use the same variable and he might argue that your kernel and other low-level things do exactly the same, installing everything under /lib and not /lib${variant}

I checked #347517 and that doesn't make any sense to me. You're not just disabling "on demand start", you did that because you broke an assumption and the communication between dbus-daemon and systemd is interrupted, that is wrong. If you ever want to do this "disable on-demand start" you must do it by removing /usr/share/dbus-1/system-services/${your}.service.  That way dbus-daemon will not associate a bus-name with a service and not even try to start it. The way you did it do associate and tries to start, but systemd can't find it.
    OTOH, if you do start wpa_supplicant manually systemd will not notice it's a service that should be tracked, thus is even worse.

[Comment 135 Gustavo Sverzut Barbieri 2010-12-23 17:12:42 UTC]

Lennart (mezcalero) about the /lib64 issue:

12:23        k-s> mezcalero: any hard reason to keep arch-dependent binaries in 
                  /lib/systemd as opposed to /lib64/systemd ?
13:49  mezcalero> k-s: /lib64/ is a hack to make .so linking work properly when 
                  allowing installtion of both a 32bit and a 64bit version of 
                  the .so
13:49  mezcalero> k-s: it is not necessary for executables
13:50  mezcalero> the right place for executables is hence /lib/xxxx
13:50  mezcalero> everything else is misleading
13:50  mezcalero> k-s: ask kay about this
13:50  mezcalero> k-s: he'll give you a grand preaching why /lib/64 is wrong 
                  for that

[Comment 136 cee1 2010-12-24 04:24:36 UTC]

Created attachment 257917 [details, diff]
Some patches for getting rid of bleeding-edge stuffs

Some patches for getting rid of bleeding-edge stuffs:
1. back port fsck '-l' option support
2. merge upstream patches for supporting old version of libnotify

[Comment 137 cee1 2010-12-24 04:27:16 UTC]

Created attachment 257922 [details, diff]
Merged upstream patch for supporting old version of libnotify

[Comment 138 Tomáš "tpruzina" Pružina (amd64 [ex]AT) 2011-01-11 22:26:23 UTC]

There is an bug inside openrc-init.service file, it has empty [Install] section and this is prohibited in latest versions of systemd. Adding WantedBy=multi-user.target to section solved my problem (is there eventually any FOO or empty section workaround?).

# systemctl enable openrc-init.service 
Unit files contain no applicable installation information. Ignoring. 

File: /lib/systemd/system/openrc-init.service 
...
[Install]
WantedBy=multi-user.target

[Comment 139 Claer 2011-01-12 15:00:27 UTC]

It could be interesting to add some informations after the installation of the ebuild. Personally, the problems I had to resolve :

- moving modules from /etc/modules.autoload.d to /etc/modules-load.d
- adding /etc/tmpfiles.d/screen.conf for being able to start screen as user
file content :
------------------
d /var/run/screen 1777 root root 10d
d /var/run/uscreen 0755 root root 10d12h
------------------

Other than these 2, I'm happily run systemd without any openrc dependencies :)
Thanks for the ebuild!

Claer

[Comment 140 Gustavo Sverzut Barbieri 2011-02-27 12:25:46 UTC]

Hi all,

So we're all pretty happy using systemd with gentoo, could someone @gentoo.org to request it to be merged into the portage?

I'd first start with the basics:
 1. systemd use flag;
 2. wiki page or document to explain systemd for daemon maintainers (just quick overview, http://0pointer.de/public/systemd-man/systemd.unit.html is already done);
 3. post bugs to daemons in our sys-apps/systemd-units;
 4. add systemd ebuild.

I'm still not sure whenever we should keep the "sysv" useflag and compatibility, as we know it will cause issues with openrc, so maybe we can have a profile or just a conflict with openrc? Maybe create a sys-apps/baselayout-systemd?

[Comment 141 Greg Kroah-Hartman (RETIRED) 2011-02-27 16:03:46 UTC]

(In reply to comment #140)
> Hi all,
> 
> So we're all pretty happy using systemd with gentoo, could someone @gentoo.org
> to request it to be merged into the portage?

I've always said I will do this, just email me and I can start the
merge.  Unfortunatly, I'm on the road until Thursday of this week, and can't
check anything into portage until then.

> I'd first start with the basics:
>  1. systemd use flag;

Ok.

>  2. wiki page or document to explain systemd for daemon maintainers (just quick
> overview, http://0pointer.de/public/systemd-man/systemd.unit.html is already
> done);

Then I don't think we need a gentoo-specific one, right?

>  3. post bugs to daemons in our sys-apps/systemd-units;

I can just start patching the ebuilds, no need for separate bugs, right?

>  4. add systemd ebuild.
> 
> I'm still not sure whenever we should keep the "sysv" useflag and
> compatibility, as we know it will cause issues with openrc, so maybe we can
> have a profile or just a conflict with openrc? Maybe create a
> sys-apps/baselayout-systemd?

Hm, what's wrong with just the use flag?

[Comment 142 Gustavo Sverzut Barbieri 2011-02-27 19:06:32 UTC]

Hi Greg,

> Then I don't think we need a gentoo-specific one, right?

Well, you know the manpage is looooong and boring, we could have those nice & efficient gentoo docs that highlights what matters with some examples. People will always complain if they have to learn something new with long docs if they're not interested (ie: some random ebuild maintainer). So let's make their life simple and they may cooperate easier.


> I can just start patching the ebuilds, no need for separate bugs, right?

Technically yes, but I'm not sure people will complain.


> Hm, what's wrong with just the use flag?

It's bogus. It exists because systemd's configure flag, but for Gentoo it's dangerous as it will pull in openrc deps. That could trigger race conditions (start some daemon twice). So it would be better to not have that option and maybe a profile is the best one there, it would block installation of /etc/init.d files or something like that.

[Comment 143 Nirbheek Chauhan (RETIRED) 2011-03-02 23:05:40 UTC]

(In reply to comment #141)
> (In reply to comment #140)
> >  3. post bugs to daemons in our sys-apps/systemd-units;
> 
> I can just start patching the ebuilds, no need for separate bugs, right?
> 

I think a mail to gentoo-dev and gentoo-dev-announce with a few details + saying that you're going to start doing this is the best thing to do. That way people won't get surprised by changes to their ebuilds.

[Comment 144 Benedikt Reinartz 2011-03-26 14:41:41 UTC]

I don't know where to state this, so tell me if I'm wrong.

Currently systemd links against libdbus, which is installed in /usr/lib. On my system (and maybe on others too) /usr isn't mounted at bootup, so systemd fails miserably.

Should I open a new bug for this or tell someone specific?

[Comment 145 Davide Pesavento (RETIRED) 2011-03-26 14:47:56 UTC]

(In reply to comment #144)
> I don't know where to state this, so tell me if I'm wrong.
> 
> Currently systemd links against libdbus, which is installed in /usr/lib. On my
> system (and maybe on others too) /usr isn't mounted at bootup, so systemd fails
> miserably.
> 
> Should I open a new bug for this or tell someone specific?

http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

[Comment 146 Benedikt Reinartz 2011-03-26 15:10:55 UTC]

Just read that, sorry for the noise. So, back to openrc :)

[Comment 147 Gustavo Sverzut Barbieri 2011-03-26 16:53:55 UTC]

(In reply to comment #146)
> Just read that, sorry for the noise. So, back to openrc :)

If you really read that, you should understand it is not systemd that is broken, your system is.

And indeed this is acknowledged by Gentoo developers, see my bug report: http://bugs.gentoo.org/show_bug.cgi?id=338082   sys-apps/kbd is one example, but surely you may hit more of them once in a while, particularly if you're using async/parallel boots.

[Comment 148 Benedikt Reinartz 2011-03-27 13:18:23 UTC]

IMHO that's a different case. /bin/systemd links against libdbus which is installed in /usr/lib by default on gentoo, so here separate /usr is not supported at all. It works if I copy /usr/lib/libdbus to /lib, so my system is not that broken :)

[Comment 149 Gustavo Sverzut Barbieri 2011-03-27 16:08:58 UTC]

You could change libdbus to be compiled statically, that wouldn't solve the problem.

The best thing you can do is create an initramfs that properly handles this issue mounting not just / but also /usr on top of it before calling switch/pivot-root.

[Comment 150 David J Cozatt 2011-04-09 13:16:48 UTC]

Just reading the thread and adding a comment or two. I may try systemd on a system come Monday (next day off)

source http://wireless.kernel.org/en/users/Documentation/wpa_supplicant

"Enabling control interface and nl80211 driver
New wpa_supplicant (as of commit cd27df100b from git) command line options 

-o<driver> and -O<ctrl>can now be used to override the parameters received in add interface command from dbus or global ctrl_interface. This can be used to enable a control interface when using NetworkManager or Connman or change the wpa_supplicant driver used. 

The wpa_supplicant control interface is used by wpa_cli and wpa_gui to control wpa_supplicant. GUI applications use the DBUS service file to run wpa_supplicant with specific parameters. You can edit this file to take advantage of these new changes. 

The wpa_supplicant service file is typically available on systems in the following location: 

/usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.serviceThis service file typically looks like this: 

[D-BUS Service]
Name=fi.epitest.hostap.WPASupplicant
Exec=/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log
User=rootChange it as follows to enable usage of wpa_cli or wpa_gui and also to use nl80211 when available: 

[D-BUS Service]
Name=fi.epitest.hostap.WPASupplicant
Exec=/sbin/wpa_supplicant -u -onl80211 -O/var/run/wpa_supplicant
User=root

If you are compiling the supplicant you will want CONFIG_CTRL_IFACE_DBUS=y to enable -u, CONFIG_DRIVER_NL80211=y for -onl80211 and CONFIG_CTRL_IFACE=y for the control interface. To enable usage of wpa_cli you will also want CONFIG_READLINE=y. Also enable CONFIG_DEBUG_FILE=y for the debug file"

May want to update your fi.epitest.hostap.WPASupplicant and try -Dnl80211
I am using an updated file and -Dnl80211 on p54pci and will be trying it with ath9k_ht tonight 

If systemd install goes well for me I'll likely move to that on 2 boxes soon

At present I use iw, crda, wireles-regdb and wpa_supplicant with openrc and baselayout-2 w/ ~amd64 on one box and x86-stable-32bit on a laptop (system V and baselayout-1.. well stable except running git wireless-kernel ;-))

Don't really follow why on comment #133 but perhaps will when I get time to read the wiki.

[Comment 151 Michał Górny 2011-04-09 20:50:06 UTC]

Is it ok to start supplying systemd service files with packages already? Can I assume that /$(get_libdir)/systemd/system/ would be the correct location for those?

[Comment 152 Marc-Antoine Perennou 2011-04-13 17:17:00 UTC]

I had a "bug" with systemd that I solved a few day ago.
My system took more than 3 minutes to boot, because of my lvm swap .device timeouting when activating swap.
I wrote a little lvm service which solved this issue (tested also with various system parts on lvm, like /home ...)
I edited the wiki with this new one which seems a lot better and simpler than the previous one (no-sysv version).
It would be great to have it either shipped with the lvm2 package or in the systemd-units package

[Comment 153 Marc-Antoine Perennou 2011-04-13 17:22:03 UTC]

Nevermind me, it was good only for those activating volumes in an initramfs before... Sorry about that

[Comment 154 Canek Peláez Valdés 2011-04-16 13:06:38 UTC]

Created attachment 270185 [details]
GNOME 3/systemd accountsservice ebuild

Ebuild for accountsservice, based on the one from the GNOME 3 overlay, with systemd support.

[Comment 155 Canek Peláez Valdés 2011-04-16 13:08:10 UTC]

Created attachment 270187 [details]
GNOME 3/systemd NetworkManager ebuild

Ebuild for NetworkManager, based on the one from the GNOME 3 overlay, with systemd support.

[Comment 156 Canek Peláez Valdés 2011-04-16 13:09:14 UTC]

Created attachment 270189 [details]
GNOME 3/sytemd avahi ebuild

Ebuild for avahi, based on the one from the GNOME 3 overlay, with systemd support.

[Comment 157 Canek Peláez Valdés 2011-04-16 13:10:15 UTC]

Created attachment 270191 [details]
GNOME 3/systemd wpa_supplicant ebuild

Ebuild for wpa_supplicant, based on the one from the GNOME 3 overlay, with systemd support.

[Comment 158 Canek Peláez Valdés 2011-04-16 13:12:14 UTC]

With the ebuilds from above, I'm able to use GNOME 3 with systemd in Gentoo. Don't forget to enable accounts-daemon.service, otherwise GDM, NetworkManager, and several other things stop working correctly.

[Comment 159 Michał Górny 2011-04-17 18:30:52 UTC]

Having no reply, I started some work on bringing systemd to gx86 in my dev overlay [1]. I hope this won't end up as a duplicate effort.

[1] http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git

[Comment 160 Christoph Brill (egore) (RESIGNED) 2011-04-21 09:30:10 UTC]

(In reply to comment #159)
> Having no reply, I started some work on bringing systemd to gx86 in my dev
> overlay [1]. I hope this won't end up as a duplicate effort.
> 
> [1] http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git

Are you reusing the ebuild available in http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git ?

[Comment 161 Michał Górny 2011-04-21 12:47:37 UTC]

(In reply to comment #160)
> (In reply to comment #159)
> > Having no reply, I started some work on bringing systemd to gx86 in my dev
> > overlay [1]. I hope this won't end up as a duplicate effort.
> > 
> > [1] http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git
> 
> Are you reusing the ebuild available in
> http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git ?

Assuming that's the 'systemd' overlay from layman, yes, I'm reusing that work. Though my concept is not exactly the same.

[Comment 162 Christoph Brill (egore) (RESIGNED) 2011-04-21 21:14:16 UTC]

(In reply to comment #161)
> (In reply to comment #160)
> > (In reply to comment #159)
> > > Having no reply, I started some work on bringing systemd to gx86 in my dev
> > > overlay [1]. I hope this won't end up as a duplicate effort.
> > > 
> > > [1] http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git
> > 
> > Are you reusing the ebuild available in
> > http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git ?
> 
> Assuming that's the 'systemd' overlay from layman, yes, I'm reusing that work.
> Though my concept is not exactly the same.

Good to know. I was comparing the ebuilds for systemd and there were some major differences (e.g. different EAPI, etc.) so I was wondering if you were starting from scratch.

[Comment 163 Michał Górny 2011-04-22 18:10:46 UTC]

Due to lack of reply from current asignee, I'm taking the bug over and starting to work more extensively on the topic.

[Comment 164 Gustavo Sverzut Barbieri 2011-04-22 18:17:28 UTC]

What's your work plan?

IMO (as mentioned in few comments above), we should have an official systemd use flag in portage and instructions on how to use it.

While some packages would need some effort, many would not! Things like DBus, Udev, Bluez, ConnMan, Avahi are all shipping with systemd services. It's just a matter of installing it and not /etc/init.d  This way our systemd-units package would be a quick temporary testbed, instead of a painful lagging-behind repository.

Later I believe that it would be good to make openrc and systemd collide and maybe make an alternative baselayout using standard systemd configuration files http://0pointer.de/blog/projects/the-new-configuration-files.html

[Comment 165 Carter Young 2011-04-22 19:39:21 UTC]

(In reply to comment #164)
> What's your work plan?
> 
> Later I believe that it would be good to make openrc and systemd collide and
> maybe make an alternative baselayout using standard systemd configuration files
> http://0pointer.de/blog/projects/the-new-configuration-files.html

While that sounds great, just remember openrc is going stable around the 2nd week in May

[Comment 166 Peter Stuge 2011-04-22 20:08:03 UTC]

(In reply to comment #164)
> IMO (as mentioned in few comments above), we should have an official systemd
> use flag in portage and instructions on how to use it.

Why is the USE flag needed? Why not just install both init.d and units, and let user choose what to use for init. Maybe with eselect?


> Later I believe that it would be good to make openrc and systemd collide

Why? Are there any conflicting files? I am strongly opposed to creating an artificial conflict in a Gentoo package. Seems quite un-Gentooish.

[Comment 167 Gustavo Sverzut Barbieri 2011-04-22 23:38:20 UTC]

Because there is no usage for both openrc and systemd in the same system, other than confusion.

So far systemd is the underdog and we try to cope with existing setups, but eventually we will drop all the compatibility from systemd and just native configuration files will be supported. That itself is one reason to justify.

Also, installing /etc/init.d scripts is bad. Because one user may think it's like in fedora that these will "do the right thing" and call systemctl, but it won't and thus may double-start daemons, particularly bad-written daemons that rely on archaic locking mechanisms.

Last but not least, installing both often leads to runtime detection of one of them, and it is bad. (Yes, it's bad practice, but we're encouraging it in one way or another). Take, for instance, udev scripts that call net.$DEV based on being in openrc or systemd. These could be avoided and not installed at all if just systemd use flag is enabled.

I don't think now it's a good moment to make them conflict, but later when things are more tested it may be a good way to migrate systems to systemd.

[Comment 168 Gustavo Sverzut Barbieri 2011-04-22 23:49:06 UTC]

(In reply to comment #165)
> While that sounds great, just remember openrc is going stable around the 2nd
> week in May

Okay, but "so what?" Yes, openrc took ages to be considered stable, although I used it for years, but it should be replaced with systemd as it's a way better approach.

So far systemd fully replaces openrc. The only missing bit is network, that is not up to it (init system). Most desktops would use NetworkManager or ConnMan, but for servers it may be worth to investigate alternatives. Proper alternatives, those that allow dynamic cards and thus configurations (dependencies such as firewall included).

I'm still unsure the best way to proceed here (network). Servers are either so simple that people could write udev rules themselves, or so complex that the openrc syntax gets in the way. I'm far from complex server setups since ages, so I don't have the knowledge to discuss this. One option is to split networking out of openrc and make it a standalone that is used together with systemd.

[Comment 169 Michał Górny 2011-04-23 07:46:09 UTC]

(In reply to comment #164)
> What's your work plan?

First, make it working without breaking gx86 too much. Second, test it. Third, move it nicely. In the meantime, get some of devs approval.

> IMO (as mentioned in few comments above), we should have an official systemd
> use flag in portage and instructions on how to use it.

Introducing another USEflag sounds like a bad idea, considering that systemd units are a clean no-op for non-systemd users. I am in favour of installing them all the time. INSTALL_MASK could be used to get rid of them completely.

> While some packages would need some effort, many would not! Things like DBus,
> Udev, Bluez, ConnMan, Avahi are all shipping with systemd services. It's just a
> matter of installing it and not /etc/init.d  This way our systemd-units package
> would be a quick temporary testbed, instead of a painful lagging-behind
> repository.

Do you really think packages would update their systemd services that often?

> Later I believe that it would be good to make openrc and systemd collide and
> maybe make an alternative baselayout using standard systemd configuration files
> http://0pointer.de/blog/projects/the-new-configuration-files.html

Bad idea. My concept is to install systemd with sysv compat disabled, thus it doesn't interfere with OpenRC scripts in any way. If systemd gets broken for some reason, user can boot back into OpenRC rather than running a rescue shell.

[Comment 170 Gustavo Sverzut Barbieri 2011-04-23 13:28:46 UTC]

While systemd units are no-op for openrc, if you keep openrc /etc/init.d you have the risk that you'll mess your system with 2 instances of the same system as openrc would fail to know some dependency is up and would try to start it as again.

> Do you really think packages would update their systemd services that often?

It's not the case. The case is that we keep a copy and it lags behind when main package is updated. I can't even remember when my system failed to boot because udev/dbus was updated in the main system and not in our copy. Similar (but less dangerous) happened when other stuff updated, like bluez.


> Bad idea. My concept is to install systemd with sysv compat disabled, thus it
> doesn't interfere with OpenRC scripts in any way. If systemd gets broken for
> some reason, user can boot back into OpenRC rather than running a rescue shell.

Hey, systemd got past that point for a while now. You don't need openrc to resuce it, don't have openrc in your system if you plan to be a systemd maintainer (well, it would be good to have at least 2 machines, to exercise both cases).

Putting this in a more technical way: the only thing that could break your boot is boot-time packages that do not cooperate: kernel, udev, dbus. Actually I believe to have a resuce shell, just udev needs to be correct so it will mount your hard discs.

[Comment 171 Michał Górny 2011-04-23 16:59:02 UTC]

(In reply to comment #170)
> While systemd units are no-op for openrc, if you keep openrc /etc/init.d you
> have the risk that you'll mess your system with 2 instances of the same system
> as openrc would fail to know some dependency is up and would try to start it as
> again.

This is the first problem we're trying to handle, and it's a problem with OpenRC and not systemd.

> It's not the case. The case is that we keep a copy and it lags behind when main
> package is updated. I can't even remember when my system failed to boot because
> udev/dbus was updated in the main system and not in our copy. Similar (but less
> dangerous) happened when other stuff updated, like bluez.

Good point. I'm already keeping udev & dbus units separate, I will add versioned udev/dbus dep too to avoid such a failure. I hope to get over with this when other devs are convinced to install systemd files in their packages.

> Hey, systemd got past that point for a while now. You don't need openrc to
> resuce it, don't have openrc in your system if you plan to be a systemd
> maintainer (well, it would be good to have at least 2 machines, to exercise
> both cases).

As a maintainer, I can break it myself too. And then it's a lot faster to fix the issue from a complete running system.

[Comment 172 Pavel Procopiuc 2011-04-29 20:32:55 UTC]

Created attachment 271583 [details, diff]
0001-Fix-bus_manager_handler.txt for systemd-25

Without this patch systemd freezes as soon as I try to run systemadm:

<26>systemd[1]: Assertion 'm' failed at src/dbus-manager.c:323, function bus_manager_append_n_jobs(). Aborting.
<27>systemd[1]: Caught <ABRT>, dumped core as pid 2379.
<30>systemd[1]: Freezing execution.

Patch taken from here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624094

[Comment 173 Christoph Brill (egore) (RESIGNED) 2011-05-06 18:23:47 UTC]

I'm really wondering why http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=summary and http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git are working on the same thing in completely different directions and therefore completely redundant :-/

[Comment 174 Henry Gebhardt 2011-05-07 13:06:26 UTC]

(In reply to comment #173)
> working on the same
> thing in completely different directions and therefore completely
> redundant :-/

Yes, there is some redundancy, but they are a little different, and
therefore *not* completely redundant (and there is a lot of copying
going on). I am continuing the user/systemd overlay for the following
reasons:

  - The mgorny overlay doesn't remove udev rules that call into
    /etc/init.d scripts. Bug #364159 needs to be resolved in order not
    to start them in that case.

  - The mgorny overlay doesn't append the dbus service file for, say
    wpa_supplicant (although I am not completely happy with how it is
    done now in the user/systemd overlay).

  - The mgorny overlay removes the systemd.pc file, so service files
    from e.g. libcanberra don't get installed automagically.

  - I would like to experiment (and invite others to do the same) with
    sys-apps/baselayout-systemd.

Since Michal committed his systemd eclass (thanks Michal!), keeping the
distance small between the two approaches is easier. Hopefully there
will be fewer and fewer packages in these overlays as more packages make
use of the eclass (btw, Michal, you no longer need the systemd-dbus
package, nor need you include consolekit in systemd-units).

[Comment 175 Michał Górny 2011-05-08 22:05:36 UTC]

(In reply to comment #174)
> (btw, Michal, you no longer need the systemd-dbus
> package, nor need you include consolekit in systemd-units).

I'm waiting for udev to be updated as well.

[Comment 176 Peter Stuge 2011-05-08 23:27:02 UTC]

(In reply to comment #167)
> there is no usage for both openrc and systemd in the same system, other
> than confusion.

You haven't done much migration eh? :) Seriously, the point is that there is no technical reason for the two init systems to block each other, and it is very un-Gentoo-like to introduce an artifical restriction in such circumstances.


> So far systemd is the underdog and we try to cope with existing setups, but
> eventually we will drop all the compatibility from systemd and just native
> configuration files will be supported. That itself is one reason to justify.

I think dropping compat from systemd is fine, that should just make it even easier for systemd to co-exist with openrc.


> Also, installing /etc/init.d scripts is bad. Because one user may think it's
> like in fedora that these will "do the right thing" and call systemctl, but it
> won't and thus may double-start daemons, particularly bad-written daemons that
> rely on archaic locking mechanisms.

I think all /etc/init.d scripts have something in common on Gentoo; the runscript interpreter. It should be trivial to allow users to choose init system using eselect, and have runscript yell at the user if they try to use init.d scripts when systemd is activated. If I'm overlooking some technical reason why this can not work then please remind me.


> Last but not least, installing both often leads to runtime detection of one of
> them, and it is bad. (Yes, it's bad practice, but we're encouraging it in one
> way or another). Take, for instance, udev scripts that call net.$DEV based on
> being in openrc or systemd. These could be avoided and not installed at all if
> just systemd use flag is enabled.

Runtime detection would use said eselect setting.


> I don't think now it's a good moment to make them conflict, but later when
> things are more tested it may be a good way to migrate systems to systemd.

That's a daring statement. I'm not even sure that every Gentoo user should actually be forced to use systemd in the future. Default sure, but who knows what options will be popular..

I say let's enable the two overlapping systems to co-exist now, in a way that is easy enough for everyone to deal with (emerge systemd without blocks, eselect to switch painlessly back and forth. reboot after switching would IMO be acceptable but of course excellent if we can avoid that) and deal with migration or changing the distribution default when time comes for that.

Thanks for reading!

[Comment 177 Carter Young 2011-05-09 01:00:41 UTC]

(In reply to comment #176)
> (In reply to comment #167)
> > there is no usage for both openrc and systemd in the same system, other
> > than confusion.
> 
> You haven't done much migration eh? :) Seriously, the point is that there is no
> technical reason for the two init systems to block each other, and it is very
> un-Gentoo-like to introduce an artifical restriction in such circumstances.
> 
> 
I added myself to this bug for many reasons.  

1. I run exherbo in a Virtualbox.  The default recommended there is systemd.
2. I wanted to watch the progress of an ebuild from birth to acceptance.

I just wanted to comment on what I posted above.  If your comment were true about being un-gentoo like regarding restrictions lets confuse a massive userbase, as an example, by allowing baselayout-1 and baselayout-2 to exist together.  The fact that baselayout-2/openrc blocks baselayout-1 guarantees that a user will not foobar his system.  You are correct in stating that there is no technical reason, but IT SHOULD BE COMMON SENSE that two init systems cannot exist in tandem as both systems are trying to control the critical boot process.

In line with Common Sense, I hope that this bug stays open as long as bug #295613 for QA reasons, so that arguments like this do not make it into the tree(nearly a year and a half) as the requester understood the importance of nudging users down an upgrade path properly.

[Comment 178 Peter Stuge 2011-05-09 01:12:49 UTC]

(In reply to comment #177)
> > > there is no usage for both openrc and systemd in the same system, other
> > > than confusion.
> > 
> > the point is that there is no technical reason for the two init systems to
> > block each other, and it is very un-Gentoo-like to introduce an artifical
> > restriction in such circumstances.
> 
> I just wanted to comment on what I posted above.  If your comment were true
> about being un-gentoo like regarding restrictions lets confuse a massive
> userbase

I think Gentoo is about choice; unless there's a technical problem Gentoo wants to continue to do clever things that allow users to make choices easily.


> You are correct in stating that there is no technical reason, but IT SHOULD
> BE COMMON SENSE that two init systems cannot exist in tandem as both systems
> are trying to control the critical boot process.

Maybe I was unclear. Sorry. Only one system can be active. Of course only one system can be active.

But a block was suggested, which would mean that both systems could not even be installed at the same time. To me this is an artifical limitation that doesn't belong in Gentoo.

I am not questioning that only one init system can be active at a time. I'll now for the third time suggest that users indicate their init choice using eselect, which should also make it very easy for relevant parts of the system to know what the user has chosen.

[Comment 179 Alec Meyers 2011-05-09 01:50:12 UTC]

(In reply to comment #177)
> that a user will not foobar his system.  You are correct in stating that there
> is no technical reason, but IT SHOULD BE COMMON SENSE that two init systems
> cannot exist in tandem as both systems are trying to control the critical boot
> process.

I'd just like to remind you that we actually *did* have alternative boot systems, and they never blocked each other.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/initng/?hideattic=0
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/einit/?hideattic=0

I'd also like to remind you that baselayout-1 and openrc shared a lot file locations, which would have resulted in file collisions - a legitimate reason for packages to block each other.

[Comment 180 Carter Young 2011-05-09 02:10:12 UTC]

(In reply to comment #178)

> I am not questioning that only one init system can be active at a time. I'll
> now for the third time suggest that users indicate their init choice using
> eselect, which should also make it very easy for relevant parts of the system
> to know what the user has chosen.

Your eselect "fix" in order to allow Gentoo to do "clever things" adds code
bloat to both init systems in the form of an if.  If init=openrc shutout
systemd etc and vice versa.  In your scenario there is no reliable way to test
init.  Example:

1. eselect init set openrc
2. emerge openrc
3. configure openrc
4. reboot
5. eselect init set systemd
6. emerge systemd
7. configure systemd
8. reboot

now both sets of inits are configured properly (steps 3 and 7).  There is no
reliable way to have either init test for the other, unless you store both sets
of configs in a common place, but I can still clobber the config files by
runing 1 and 5 because etc-update will not be run unless the inits are
re-emerged each time...  This creates the need 4 a block.

[Comment 181 Peter Stuge 2011-05-09 02:28:16 UTC]

(In reply to comment #180)
> Your eselect "fix" in order to allow Gentoo to do "clever things" adds code
> bloat to both init systems in the form of an if.  If init=openrc shutout
> systemd etc and vice versa.

You are seriously worried about the extra cmp and jnz instructions, and the cache miss? I think we can afford it.


> In your scenario there is no reliable way to test init.  Example:
> 
> 1. eselect init set openrc
> 2. emerge openrc
> 3. configure openrc
> 4. reboot
> 5. eselect init set systemd
> 6. emerge systemd
> 7. configure systemd
> 8. reboot
> 
> now both sets of inits are configured properly (steps 3 and 7).  There is no
> reliable way to have either init test for the other, unless you store both sets
> of configs in a common place, but I can still clobber the config files by
> runing 1 and 5 because etc-update will not be run unless the inits are
> re-emerged each time...  This creates the need 4 a block.

Ah, but I was thinking more like this:

1. emerge openrc
2. configure openrc
3. eselect init set openrc
4. (maybe) reboot
5. emerge systemd
6. configure systemd
7. eselect init set systemd
8. (maybe) reboot

I'm afraid I don't understand completely what you mean by configs in a common place. As for configuration (my steps 2 and 6) I would probably expect all openrc configuration to be separate and isolated from systemd configuration, simply because the two init systems work differently. So users wanting to switch would indeed have to adapt their previous configuration. Possibly it can be avoided to some degree, maybe even completely, but in principle I'm not sure I really can expect Gentoo to do very much there.

You mention needing etc-update to "activate" openrc or systemd respectively, which suggests that both systems have config files with the same name in the same place. If this is a hard requirement then it is a technical reason for a block. But in that case I think it would be real nice to work away from that, so that the two *can* co-exist. But noone else has pointed out that there are any file conflicts, so I'm not sure it's accurate? What files exist in both ebuilds?

[Comment 182 Carter Young 2011-05-09 02:57:56 UTC]

(In reply to comment #181)
> (In reply to comment #180)

> You are seriously worried about the extra cmp and jnz instructions, and the
> cache miss? I think we can afford it.

> > now both sets of inits are configured properly (steps 3 and 7).  There is no
> > reliable way to have either init test for the other, unless you store both sets
> > of configs in a common place, but I can still clobber the config files by
> > runing 1 and 5 because etc-update will not be run unless the inits are
> > re-emerged each time...  This creates the need 4 a block.
> 
> Ah, but I was thinking more like this:
> 
> 1. emerge openrc
> 2. configure openrc
> 3. eselect init set openrc
> 4. (maybe) reboot
> 5. emerge systemd
> 6. configure systemd
> 7. eselect init set systemd
> 8. (maybe) reboot
> 
> I'm afraid I don't understand completely what you mean by configs in a common
> place. As for configuration (my steps 2 and 6) I would probably expect all
> openrc configuration to be separate and isolated from systemd configuration,
> simply because the two init systems work differently. So users wanting to
> switch would indeed have to adapt their previous configuration. Possibly it can
> be avoided to some degree, maybe even completely, but in principle I'm not sure
> I really can expect Gentoo to do very much there.
> 
> You mention needing etc-update to "activate" openrc or systemd respectively,
> which suggests that both systems have config files with the same name in the
> same place. If this is a hard requirement then it is a technical reason for a
> block. But in that case I think it would be real nice to work away from that,
> so that the two *can* co-exist. But noone else has pointed out that there are
> any file conflicts, so I'm not sure it's accurate? What files exist in both
> ebuilds?

The purpose of an init system is to boot in a reasonable amount of time, so yes I am worried about the extra instructions.  System requirements are not what Gentoo is about. Running on a low end system will be different etc.

If you allow both inits to be installed at once you allow for a user with root privileges to start with one init, boot, and then intelligently stop services using the other init system, as eselect does not enforce permission.  Example:

eselect package_manager set paludis
cave resolve -x <package atom>

Just because I prefer paludis doesn't stop me from using emerge even though eselect is properly set. Responsible use of a package does not mean that all users will use it responsibly, which presents a security risk.  Having the configuration files in 2 separate directories allows for interchangeable use, as both are properly configured.  Having them in the same place ensures security, but decreases interchangeability.

[Comment 183 Michał Górny 2011-05-09 06:31:23 UTC]

(In reply to comment #182)
> The purpose of an init system is to boot in a reasonable amount of time, so yes
> I am worried about the extra instructions.  System requirements are not what
> Gentoo is about. Running on a low end system will be different etc.

And you are worried about these few instructions, say, checking for a single file existence (like I suggested for openrc) where there's already a lot of time wasted on running shell code?

[Comment 184 William Hubbs 2011-05-10 14:42:19 UTC]

The way I see this From the perspective of working with openrc, is that there are a couple of things that need to be done:

The first is that openrc should print a warning if you try to run an init.d script if openrc was  not used to boot the system. bug 364159 is addressing this. There are two patches on that bug that seem to do the same thing, so I need to decide which one to take.

The second issue is that some of our packages automatically call scripts in /etc/init.d. So far I have found that this list would include sys-fs/udev, net-wireless/wpa_supplicant and net-wireless/bluez. Are there more?

These will have to be looked at on a case-by-case basis and we will need to figure out how to make these packages not call scripts in /etc/init.d unless openrc was used to boot the system.

[Comment 185 Canek Peláez Valdés 2011-05-20 19:11:20 UTC]

(Using the overlay from: git://git.overlays.gentoo.org/user/systemd.git)

The new systemd ebuild (version 27) depends on stable audit with the audit USE flag, but systemd 27 doesn't compile with audit 1.7.4. With audit 2.0.5, systemd compiles again.

[Comment 186 Michał Górny 2011-06-06 08:37:41 UTC]

(In reply to comment #185)
> The new systemd ebuild (version 27) depends on stable audit with the audit USE
> flag, but systemd 27 doesn't compile with audit 1.7.4. With audit 2.0.5,
> systemd compiles again.

Fixed.

systemd-28 now in tree, hard-masked. Feel free to test it but denote that:
1) it blocks the current releases of OpenRC (<0.8.3 which is not yet released) due to services started by udev rules,
2) it requires >=udev-171 which still blocks many packages,
3) USE=audit requires masked audit-2,
4) many packages still lack systemd units.

Anyway, feel free to test.

1) for simple bugs - report here,
2) for more complex bugs - open a separate bug and block this one with it,
3) for ebuilds not installing systemd units which upstream supplies - open a separate bug, block bug #365937,
4) for other systemd unit requests - open a separate bug, CC me.

[Comment 187 Maciej Piechotka 2011-06-10 08:40:45 UTC]

On paludis I get error on pretend:


systemd-9999> LOG FILE "/var/log/sandbox/sandbox-32236.log"
systemd-9999> 
systemd-9999> VERSION 1.0
systemd-9999> FORMAT: F - Function called
systemd-9999> FORMAT: S - Access Status
systemd-9999> FORMAT: P - Path as passed to function
systemd-9999> FORMAT: A - Absolute Path (not canonical)
systemd-9999> FORMAT: R - Canonical Path
systemd-9999> FORMAT: C - Command Line
systemd-9999> 
systemd-9999> F: open_wr
systemd-9999> S: deny
systemd-9999> P: .32381.tmp
systemd-9999> A: /usr/src/linux-2.6.38-zen20110510/.32381.tmp
systemd-9999> R: /usr/src/linux-2.6.38-zen20110510/.32381.tmp
systemd-9999> C: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/as --64 -o .32381.tmp /tmp/cccb5f3N.s 
systemd-9999> 
(...)

Everything is ok when I comment out the pretend part from ebuild

[Comment 188 Aleksandar Petrinic 2011-06-10 09:41:37 UTC]

I'm on paludis too.
Here, everything works correctly.

What is your paludis version and what command did you use ?

[Comment 189 Maciej Piechotka 2011-06-10 10:03:12 UTC]

(In reply to comment #188)
> I'm on paludis too.
> Here, everything works correctly.
> 
> What is your paludis version and what command did you use ?

# cave --version
paludis 0.60.4

[Comment 190 microcai 2011-06-10 11:27:11 UTC]

gcc-config need /etc/init.d/functions.sh which is provided by openrc.
So, block openrc will disable gcc-config , of-course.

/etc/init.d/functions.sh is needed by many scripts, better to fix these scripts or make systemd provide it too?

[Comment 191 Michał Górny 2011-06-10 12:35:21 UTC]

(In reply to comment #187)
> On paludis I get error on pretend:

Please open a separate bug, state your 'emerge --info' and kernel info there.

(In reply to comment #190)
> gcc-config need /etc/init.d/functions.sh which is provided by openrc.
> So, block openrc will disable gcc-config , of-course.
> 
> /etc/init.d/functions.sh is needed by many scripts, better to fix these scripts
> or make systemd provide it too?

Noone is going to block openrc. I think, though, that these packages should RDEPEND on it then.

[Comment 192 Christoph Brill (egore) (RESIGNED) 2011-06-15 12:10:37 UTC]

Created attachment 277115 [details, diff]
systemd-28.patch

This patch for the ebuild adds support for plymouth

[Comment 193 Christoph Brill (egore) (RESIGNED) 2011-06-15 12:11:53 UTC]

Created attachment 277117 [details, diff]
systemd-28-enable-plymouth.patch

Patch to systemd itself to enable plymouth for gentoo.

[Comment 194 Christoph Brill (egore) (RESIGNED) 2011-06-15 12:23:01 UTC]

(In reply to comment #186)
> Anyway, feel free to test.

I did so (on a production machine). In most cases systemd is working fine already. I had some trouble getting mysqld to run (was missing the tmpfile entry to create /var/run/mysqld) and I manually removed the blocker to openrc (I didn't like the idea to switch back to baselayout1 (as suggested in the wiki) and don't think any of my udev rules will cause openrc to be started).

Next to that my system is really stable and working as expected. Good job. I've not tested the systemd overlay as it wasn't necessary for my tests.

But: We definitely need some documentation on how to properly put services to the tragets/runlevels. E.g. I'm starting syslog in multi-user.target which is way to late but I haven't figured out which would be better. I think a descriptive mapping table (I don't really like the idea of adding symlinks like sysinit.target, shutdown.target, boot.target, local.target, nonetwork.target, ...) that would explain which systemd target matches best the Gentoo openrc runlevels. Or maybe we could even create a rc-update -> *.target automigration?

[Comment 195 Michał Górny 2011-06-15 13:33:48 UTC]

(In reply to comment #194)
> I did so (on a production machine). In most cases systemd is working fine
> already. I had some trouble getting mysqld to run (was missing the tmpfile
> entry to create /var/run/mysqld) and I manually removed the blocker to openrc
> (I didn't like the idea to switch back to baselayout1 (as suggested in the
> wiki) and don't think any of my udev rules will cause openrc to be started).

The other solution is to update to openrc-9999. It might be a good idea to ping OpenRC herd to make a release soon.

> But: We definitely need some documentation on how to properly put services to
> the tragets/runlevels. E.g. I'm starting syslog in multi-user.target which is
> way to late but I haven't figured out which would be better. I think a
> descriptive mapping table (I don't really like the idea of adding symlinks like
> sysinit.target, shutdown.target, boot.target, local.target, nonetwork.target,
> ...) that would explain which systemd target matches best the Gentoo openrc
> runlevels. Or maybe we could even create a rc-update -> *.target automigration?

Having a doc writer in the team would be awesome indeed :P.

For the plymouth patch, I have taken a simpler route. I'd appreciate if you could test whether it works for you.

[Comment 196 Alec Moskvin 2011-06-15 14:59:13 UTC]

What is the plan in regards to the lack of systemd units?

Should we report bugs to package maintainers with proposed units, or will there be a systemd-units package like in the systemd overlay?

[Comment 197 William Hubbs 2011-06-15 15:06:29 UTC]

(In reply to comment #196)
> What is the plan in regards to the lack of systemd units?
> 
> Should we report bugs to package maintainers with proposed units, or will there
> be a systemd-units package like in the systemd overlay?

I would not recommend a systemd-units package; that will cause collissions as other packages get systemd units of their own.

I would suggest reporting bugs to the package maintainers, or better yet, reporting to the upstream for the packages.

[Comment 198 Michał Górny 2011-06-15 15:32:30 UTC]

(In reply to comment #196)
> What is the plan in regards to the lack of systemd units?
> 
> Should we report bugs to package maintainers with proposed units, or will there
> be a systemd-units package like in the systemd overlay?

Open bugs and CC systemd@g.o. Best if upstream wants to supply the systemd unit file (but please make sure they do it like in `man daemon', i.e. with full --with-systemdsystemunitdir); some devs may also like to supply units with their packages irrespective of upstream.

For systemd-units, things like that are PITA to maintain. There will be probably a package like that left in the overlay but it's not going to hit the tree. If you are in a hurry, I suggest just putting the units in /etc/systemd/system/.

[Comment 199 Christoph Brill (egore) (RESIGNED) 2011-06-16 05:18:05 UTC]

I'd really like to see the remaining open blockers of bug #365937 to be resolved as soon as possible. This way we won't need the systemd overlay anymore. I've opened some bugs for the packages provided by the overlays but I think we need a single bug for every file found in http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=tree;f=sys-apps/systemd-units/files , right?

I also reworked the gentoo wiki not to point to the overlay any more for installing systemd (as comment 198 says: systemd-units is a bad idea).

[Comment 200 Michał Górny 2011-06-16 05:42:15 UTC]

(In reply to comment #199)
> I'd really like to see the remaining open blockers of bug #365937 to be
> resolved as soon as possible. This way we won't need the systemd overlay
> anymore. I've opened some bugs for the packages provided by the overlays but I
> think we need a single bug for every file found in
> http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=tree;f=sys-apps/systemd-units/files
> , right?

Hopefully, some devs will start migrating their packages themselves.

There are also some units in my overlay [mgorny].

And we have a few troublesome packages like wpa_supplicant. The 'common' systemd unit lying on the net is useful only to NetworkManager users. I made a simpler one which is useful to plain wpa_supplicant users. Getting a package to install two different service files is exponentially harder that installing one.

> I also reworked the gentoo wiki not to point to the overlay any more for
> installing systemd (as comment 198 says: systemd-units is a bad idea).

Thanks.

[Comment 201 Christoph Brill (egore) (RESIGNED) 2011-06-16 06:24:45 UTC]

(In reply to comment #195)
> For the plymouth patch, I have taken a simpler route. I'd appreciate if you
> could test whether it works for you.

I wasn't sure whether to patch the configure.ac's default value or pass have_plymouth to configure. Both attempts work the same way for me (rather unstable as I'm not quite sure when to start which plymouth service because the "upstream" service files don't provide an Install-WantedBy).

[Comment 202 Michał Górny 2011-06-20 18:25:45 UTC]

It seems like the last blocker was closed. Are there any reasons not to unmask systemd besides lack of docs?

[Comment 203 Christoph Brill (egore) (RESIGNED) 2011-06-21 10:44:34 UTC]

(In reply to comment #202)
> It seems like the last blocker was closed. Are there any reasons not to unmask
> systemd besides lack of docs?

I think the documentation in the wiki already is quite useable. I could set up my system without to much effort and all mistakes I made are covered by the wiki page. I added a simple section about necessary services (network, dm) so that the user is not left without network and the X server.

http://en.gentoo-wiki.com/wiki/Systemd#Important_services

I'm not sure how to deal with different dm's though. We don't have a proper replacement for /etc/init.d/xdm yet (afaik). Other distros seem to use a simple shell script named "prefdm" that more or less does the same. But that might be target for a different bug.

http://forums.fedoraforum.org/showthread.php?t=51961

Other than that I think we can unmask systemd as it does not break anything (all my system are running systemd already).

[Comment 204 Gerhard Gappmeier 2011-06-21 11:19:30 UTC]

Hi,

I still have a problem with systemd, but I'm not sure if it's an systemd bug or just a configuration error.

My HD in my laltop only has one encrypted LUKS partion and the /boot partition.
I'm using an initramfs to mount the LUKS partition and start LVM2.
All other partitions are logical volumes.
Then I use switch_root to start to real system with systemd.

However, the systemd hangs because mountspoints for /var, /opt, /home, etc. don't get mounted.
Yes, I tried "comment=systemd.mount" and "comment=systemd.automount" in /etc/fstab.
If I mount all partitions in the initramfs using the init shell script,
before starting systemd it works.

Nevertheless I think systemd should be able to detect the LVM partitions and mount them itself.

Another issue is that I need to mount at least / and /usr in the initramfs, because systemd has a dependency to libdbus which is in /usr/lib.
I don't think it's clever te let a system tool like systemd depend on files in /usr.

I hope this issues can be fixed with an updated wiki.

I've one more question: Is it possible or even recomended to use systemd already in initramfs instead of the /init shellscript?

[Comment 205 Michał Górny 2011-06-21 11:36:42 UTC]

(In reply to comment #203)
> I'm not sure how to deal with different dm's though. We don't have a proper
> replacement for /etc/init.d/xdm yet (afaik). Other distros seem to use a simple
> shell script named "prefdm" that more or less does the same. But that might be
> target for a different bug.
> 
> http://forums.fedoraforum.org/showthread.php?t=51961

I personally disagree with the prefdm concept. This is just an unnecessary middleware creating more and more trouble maintaining. I'd prefer that each DM installed a separate service.

(In reply to comment #204)
> Another issue is that I need to mount at least / and /usr in the initramfs,
> because systemd has a dependency to libdbus which is in /usr/lib.
> I don't think it's clever te let a system tool like systemd depend on files in
> /usr.

Upstream doesn't support having separate /usr. We can't do anything about it.

[Comment 206 Maciej Piechotka 2011-06-21 11:48:01 UTC]

> However, the systemd hangs because mountspoints for /var, /opt, /home, etc.
> don't get mounted.
> Yes, I tried "comment=systemd.mount" and "comment=systemd.automount" in
> /etc/fstab.
> If I mount all partitions in the initramfs using the init shell script,
> before starting systemd it works.
> 
> Nevertheless I think systemd should be able to detect the LVM partitions and
> mount them itself.
> 

I use such file:

# cat /lib/systemd/system/lvm.service                       
[Unit]
Description=LVM activation
DefaultDependencies=no
Requires=udev-settle.service
After=udev-settle.service
Before=basic.target shutdown.target
Conflicts=shutdown.target

[Service]
ExecStart=/sbin/vgchange --sysinit --available y
Type=oneshot
TimeoutSec=0
RemainAfterExit=yes

[Install]
WantedBy=basic.target

I haven't been successful with custom initrd+systemd - I use dracut

[Comment 207 Canek Peláez Valdés 2011-06-21 11:59:24 UTC]

(In reply to comment #205)
> I personally disagree with the prefdm concept. This is just an unnecessary
> middleware creating more and more trouble maintaining. I'd prefer that each DM
> installed a separate service.

I agree.

> (In reply to comment #204)
> > Another issue is that I need to mount at least / and /usr in the initramfs,
> > because systemd has a dependency to libdbus which is in /usr/lib.
> > I don't think it's clever te let a system tool like systemd depend on files 
> > in /usr.
> 
> Upstream doesn't support having separate /usr. We can't do anything about it.

It's not systemd: A separate partition for /usr it's actually broken. systemd can work with /usr in a different partition: It only prints a warning that several things would break (unrelated to systemd). See:

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1337

[Comment 208 Christoph Brill (egore) (RESIGNED) 2011-06-22 07:09:51 UTC]

(In reply to comment #205)
> I personally disagree with the prefdm concept. This is just an unnecessary
> middleware creating more and more trouble maintaining. I'd prefer that each DM
> installed a separate service.

I don't really like the idea either. I'm really happy to use

 systemctl enable gdm\@.service

to enable gdm. This is what I want ("enable gdm") and no etc-update/dispatch-conf will suggest me to use xdm again :-)

So do we need updated ebuilds for xdm/gdm/kdm/slim/etc. before unmasking? Or shall we wait until the demand from the users forces us?

[Comment 209 Michał Górny 2011-06-22 07:56:14 UTC]

(In reply to comment #208)
> So do we need updated ebuilds for xdm/gdm/kdm/slim/etc. before unmasking? Or
> shall we wait until the demand from the users forces us?

I don't think it's really necessary. Though we need to develop some docs explaining users the risks and so on.

[Comment 210 Michał Górny 2011-06-22 10:38:58 UTC]

Ok, I have unmasked systemd and created an initial version of the install guide. It will be available on our project page [1] when docs refresh.

[1]:http://www.gentoo.org/proj/en/base/systemd/

[Comment 211 Henry Gebhardt 2011-06-22 15:08:03 UTC]

(In reply to comment #210)
> Ok, I have unmasked systemd and created an initial version of the install
> guide. It will be available on our project page [1] when docs refresh.
> 
> [1]:http://www.gentoo.org/proj/en/base/systemd/

I think code listing 2.4 is not really necessary, you can enable the service with 'systemctl enable xdm@.service'. You need to do it manually only if you don't want to use the default tty7 for it.

Thanks.

[Comment 212 Christoph Brill (egore) (RESIGNED) 2011-06-23 22:41:56 UTC]

Currently systemd installs a completion file into

/etc/bash_completion.d/systemctl-bash-completion.sh

while the file should be placed in

/usr/share/bash-completion/systemctl

so it gets picked up by "eselect bashcomp" and can be enabled/disabled.

[Comment 213 Michał Górny 2011-06-24 07:02:47 UTC]

(In reply to comment #211)
> (In reply to comment #210)
> > Ok, I have unmasked systemd and created an initial version of the install
> > guide. It will be available on our project page [1] when docs refresh.
> > 
> > [1]:http://www.gentoo.org/proj/en/base/systemd/
> 
> I think code listing 2.4 is not really necessary, you can enable the service
> with 'systemctl enable xdm@.service'. You need to do it manually only if you
> don't want to use the default tty7 for it.

Yes, that's true but I really don't want to have 10 more cases for it there. I think it is idiotic that 'systemctl enable [e-mail]' doesn't work. It treats @ magical but only in some cases...

(In reply to comment #212)
> Currently systemd installs a completion file into
> 
> /etc/bash_completion.d/systemctl-bash-completion.sh
> 
> while the file should be placed in
> 
> /usr/share/bash-completion/systemctl
> 
> so it gets picked up by "eselect bashcomp" and can be enabled/disabled.

I'll fix the ebuild. I'd appreciate if you opened a bug upstream.

[Comment 214 Christoph Brill (egore) (RESIGNED) 2011-06-24 20:02:03 UTC]

(In reply to comment #213)
> I'll fix the ebuild. I'd appreciate if you opened a bug upstream.

I'm not sure if /usr/share/bash-completion isn't something Gentoo specific. All ebuilds I found (e.g. udisks) do something like:

rm -f "${ED}"/etc/profile.d/udisks-bash-completion.sh
dobashcompletion tools/udisks-bash-completion.sh ${PN}


Next to that I tried to use my system without sysvinit/openrc. Works like a charm with one downside that there is no "halt" or "reboot" by default (only "systemctl reboot"). It also seems that "systemctl halt" does halt my system but does not turn it off.


I also opened bug #372887 for an implicit openrc dependecy from eix.

[Comment 215 erFelipe 2012-03-22 10:32:21 UTC]

Created attachment 306293 [details]
service file from syslog-ng_3.2.5.tar.bz2

modified with "Alias" literal, following systemd's internal syslog.service file advice.

[Comment 216 erFelipe 2012-03-22 10:33:50 UTC]

Created attachment 306295 [details]
laptop-mode service file

copied from arch's unit file

[Comment 217 erFelipe 2012-03-22 10:35:31 UTC]

Created attachment 306297 [details]
hwclock service file

It works together with hwclock-set.sh script I made.

[Comment 218 erFelipe 2012-03-22 10:37:49 UTC]

Created attachment 306299 [details]
script for hwclock service file

wrote for me, keeping the exact behaviour of gentoo's init.d file... But it needs to be revised.

[Comment 219 erFelipe 2012-03-22 10:46:29 UTC]

Hi, in the forum, people told me to post here my own service files, so here they are:

1. syslog-ng file is copied from tar.bz2 syslog-ng package, but modified with "Alias", following advice in systemd syslog.service file

2. Laptop-mode-tools service file is copied from arch's unit file. No modifications.

3 hwclock file has been written for me, keeping exact behaviour of gentoo's init.d file... but it needs a script... Script is an adaptation from the init.d file.

Later I'll post some more (microcode, cpufrequtils...), but now I have no time to do so :S

I hope my files are useful.



(BTW, sorry for my 'dirty' english :)

[Comment 220 erFelipe 2012-03-22 17:00:19 UTC]

Created attachment 306339 [details]
adapted from gentoo init script

[Comment 221 erFelipe 2012-03-22 17:05:40 UTC]

Created attachment 306341 [details]
lm_sensors service file

[Comment 222 erFelipe 2012-03-22 17:08:52 UTC]

Created attachment 306343 [details]
script used by my cpufrequtils unit file

[Comment 223 erFelipe 2012-03-22 17:09:44 UTC]

Created attachment 306345 [details]
cpufrequtils unit file

[Comment 224 Gustavo Sverzut Barbieri 2012-03-22 17:12:59 UTC]

(In reply to comment #219)
> 3 hwclock file has been written for me, keeping exact behaviour of gentoo's
> init.d file... but it needs a script... Script is an adaptation from the
> init.d file.

Please don't. There was that support and it was agreed to be removed for good.

The recommendation is to have the following kernel options:

   CONFIG_RTC_HCTOSYS=y
   CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

And leave the sync to "ntp", as it will sync every 11 minutes.


> Later I'll post some more (microcode, cpufrequtils...), but now I have no
> time to do so :S

Also talked to systemd/udev maintainers and they also recommend to not use those, reasons:

 - microcode is useless. All the microcode loading now should be done by kernel requests to the firmware loader. microcodectl should die.

 - cpufreq should be left to kernel with ondemand governor. People should avoid cpufreq and governor changes unless they really know what they are doing, in this case they can write the services themselves for their needs.

Feel free to join #systemd at irc.freenode.net to ask.

[Comment 225 Henry Gebhardt 2012-04-27 18:42:18 UTC]

(In reply to comment #215)
> Created attachment 306293 [details]
> service file from syslog-ng_3.2.5.tar.bz2
> 
> modified with "Alias" literal, following systemd's internal syslog.service
> file advice.

Sorry for my late reply.

Do you know what syslog-ng upstream thinks of it? I am not sure if syslog-ng supports socket activation. Could you check that?

Please file a bug report against syslog-ng. A service file should get included there.