Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: - "upstart" and "systemd" are now parallel installable. When you upgrade rawhide you will get both installed. (we'll drop upstart eventually, but during the testing phase i made sure to explicitly install both, so that there is a safe backup init system)

- You can boot into either of them by setting the "init=" kernel cmdline option according to your wishes. If you pass "init=/bin/systemd" you will boot into systemd, if you pass "init=/sbin/upstart" you will boot into upstart (note the /sbin vs. /bin!)

> Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system.

On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: > On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >>> Why is the systemd executable in /bin instead of /sbin? >> Without looking too closely I believe systemd eventually seeks to replace >> things like gnome-session daemon. It has session management in mind as >> well as system. > > Still belongs in /sbin, unless it's meant to actually be executed directly > by end-users. No. If that were the criterion, update-mime-database would belong in /sbin .

On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: > On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >>> Why is the systemd executable in /bin instead of /sbin? >> Without looking too closely I believe systemd eventually seeks to replace >> things like gnome-session daemon. It has session management in mind as >> well as system. > > Still belongs in /sbin, unless it's meant to actually be executed directly > by end-users. No. If that were the criterion, update-mime-database would belong in /sbin .

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNVfQACgkQ6YSQoMYUY95UngCgxoS3//7yzpXZriKSCZMFnun+ 1qoAn107myHo05jderCykLfKsSmqYAmS =iYOx -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2010 09:39 PM, Matt McCutchen wrote: > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >>>> Why is the systemd executable in /bin instead of /sbin? >>> Without looking too closely I believe systemd eventually seeks to replace >>> things like gnome-session daemon. It has session management in mind as >>> well as system. >> >> Still belongs in /sbin, unless it's meant to actually be executed directly >> by end-users. > > No. If that were the criterion, update-mime-database would belong > in /sbin . > The FHS puts it like this: (a) "/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts." (b) "/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin." So if the intent is that systemd will eventually be invoked (indirectly by some script/daemon) by users this seems justified by (a). On the other hand the page has this to say on "init": "The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed: ... init" It's arguable though whether this refers to SysV's init or is intended to be more general. http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES

2010/7/27 Matt McCutchen <matt(a)mattmccutchen.net&gt;: > On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/24/2010 09:39 PM, Matt McCutchen wrote: >> > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >> >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >> >>>> Why is the systemd executable in /bin instead of /sbin? >> >>> Without looking too closely I believe systemd eventually seeks to replace >> >>> things like gnome-session daemon. It has session management in mind as >> >>> well as system. >> >> >> >> Still belongs in /sbin, unless it's meant to actually be executed directly >> >> by end-users. >> > >> > No.  If that were the criterion, update-mime-database would belong >> > in /sbin . >> > >> >> The FHS puts it like this: >> >> (a) "/bin contains commands that may be used by both the system >> administrator and by users, but which are required when no other >> filesystems are mounted (e.g. in single user mode). It may also contain >> commands which are used indirectly by scripts." >> >> (b) "/sbin contains binaries essential for booting, restoring, >> recovering, and/or repairing the system in addition to the binaries in >> /bin." >> >> So if the intent is that systemd will eventually be invoked (indirectly >> by some script/daemon) by users this seems justified by (a). On the >> other hand the page has this to say on "init": >> >> "The following files, or symbolic links to files, must be in /sbin if >> the corresponding subsystem is installed: ... >> init" >> >> It's arguable though whether this refers to SysV's init or is intended >> to be more general. >> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES > > A hard link or symlink at /sbin/init is needed because tools look for it > there.  However, I think the main "systemd" executable belongs in /bin. > I read (b) as a subdivision of the category established by the previous > sentence: "Utilities used for system administration (and other root-only > commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin."  systemd > is not (going to be) root-only, hence it doesn't go in */sbin.  The > right comparison would be to /bin/dbus-daemon. > > -- > Matt i do not understand how a daemon (like e.g. dbus-daemon) qualifies as "/bin : Essential user command binaries (for use by all users)" (taken from fhs 2.3).  one could argue if a daemon qualifies as "command". especially since it seems it has to be run before /usr is mounted it is never getting executed by (all) the users. From a usability point of view it is exactly those kinda commands i do not want in the user path because a user itsself should never have to execute it. to me it sounds more like: /sbin : System binaries. If the system doesent need it why do we start it that early? kind regards, Rudolf Kastl kind regards, Rudolf Kastl > > -- > devel mailing list > devel(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel >

On Tue, 2010-07-27 at 09:49 +0200, Rudolf Kastl wrote: > small addition: > > if you want to move stuff to /bin how about ifconfig and ip. I don't think so.  ifconfig and ip administer the system-wide network interfaces.  All the write operations require root privileges.  The read operations don't, but if they are called by an unprivileged user, it is still for the purpose of system administration and I don't think it's unreasonable to expect the user to go to /sbin .

-- Matt -- devel mailing list devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

On Tue, 2010-07-27 at 09:42 +0200, Rudolf Kastl wrote: > i do not understand how a daemon (like e.g. dbus-daemon) qualifies as > "/bin : Essential user command binaries (for use by all users)" (taken > from fhs 2.3).  one could argue if a daemon qualifies as "command". > especially since it seems it has to be run before /usr is mounted it > is never getting executed by (all) the users. The next sentence says, "/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode)."  systemd qualifies on both counts: it may be used by users, and it is needed before other filesystems are mounted.

> From a usability point of view it is exactly those kinda commands i do > not want in the user path because a user itsself should never have to > execute it. Messing up the distinction between */bin and */sbin in the name of cleaner path completion is not progress.

> to me it sounds more like: /sbin : System binaries. If the system > doesent need it why do we start it that early? The system does need systemd.  Users also need it (that is, once the envisioned user session-management capability is added).

-- Matt -- devel mailing list devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote: > On 7/23/2010 20:26, Lennart Poettering wrote: > > - You can boot into either of them by setting the "init=" kernel cmdline > > option according to your wishes. If you pass "init=/bin/systemd" you > > will boot into systemd, if you pass "init=/sbin/upstart" you will boot > > into upstart (note the /sbin vs. /bin!) > > Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system.

- You can boot into either of them by setting the "init=" kernel cmdline option according to your wishes. If you pass "init=/bin/systemd" you will boot into systemd, if you pass "init=/sbin/upstart" you will boot into upstart (note the /sbin vs. /bin!)

If systemd does not work for you and you need a temporary fix, pass "init=/bin/upstart" on the kernel command line.

Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit I built a local systemd-sysvinit and updated and did some testing. First it seems that my boot would fail. It was unable to find or run a 'default.target' and would hang. Unfortunately it advises you to check the logs, but since syslog isn't up yet and you can't do anything to look at dmesg thats not very helpfull. ;( If there is no /etc/systemd/system/default.target could we fall back to a single user target? Also, in my switchover, I got no getty's setup by default. Happily I was able to figure out how to add them here by looking at the FAQ (once I found it. ;) Does systemd allow you to query for root password before doing single user? With upstart/sysvinit you can do a 'chkconfig --list | grep 3:on' or the like to get a in order list of services. Is there something similar for systemd? I ask because I see people who have problems booting and often can see the last service that did work before the hang, then can look at the order and find out the trouble service. If systemd is just starting them all, is there any way to debug what one didn't finish or was next in the order? The shutdown/reboot commands don't seem to wall by default or output anything. You type them and the machine goes down. Could you at least add a "Shutting down system at 2010-07-25 xx;xx;xx" or something? With sysvinit/upstart the command would return back to a prompt and you could logout or do some few things before the machine was totally down. It's anoying to have to kill your ssh manually instead of being able to logout gracefully. Whats the status on selinux integration? We must get that working before release if it's going to be default... As a side note, "systemd" is an unfortunate name, google wise. It took me a while to find it's home page for the FAQ. ;(

Anyhow, I sure hope we can get all the issues ironed out in time for F14. If not, we can always try again next cycle. I personally really want to make sure things are as stable and working and clear as we can make them before committing to making this default. kevin -- devel mailing list devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit

On 07/25/2010 04:30 AM, Frank Murphy wrote: > On 25/07/10 07:34, Kevin Fenzi wrote: >> Greetings. >> >> first it seems that systemd-sysvinit needs to add a: >> >> Provides: sysvinit-userspace >> >> To avoid the current conflicts/upgrade problems: >> >> ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed >> --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit >> --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit >> Error: systemd-sysvinit conflicts with upstart-sysvinit > > thank Seth? for yum --exclude=systemd\* > > Will systemd be default in F14-Branched, > or be kept with devel? As of yet, that's still undecided.

>> First it seems that my boot would fail. It was unable to find or run a 'default.target' and would hang. Unfortunately it advises you to check the logs, but since syslog isn't up yet and you can't do anything to look at dmesg thats not very helpfull. ;( If there is no /etc/systemd/system/default.target could we fall back to a single user target? Also, in my switchover, I got no getty's setup by default. Happily I was able to figure out how to add them here by looking at the FAQ (once I found it. ;) What symbolic link did you set to get a graphical target?

I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works:

- Since there can only be one implementation providing the /sbin/init file name, I have split off -sysvinit packages from both packages which symlink this to either /bin/systemd (in the systemd-sysvinit pkg) or /sbin/upstart (in the upstart-sysvinit pkg). Something similar is done for /sbin/reboot and the other well-known SysV client utilities. That basically means you can choose which init system to use by default simply by installing either of these two packages. By default systemd-sysvinit will now be installed. As mentioned the "upstart" and "systemd" packages do not conflict -- but "upstart-sysvinit" and "systemd-sysvinit" do. The former two packages include all the actual code, and the latter then install them under the well-known names via symlinks.

It also doesn't seem that systemd is yet kicking in as the default for the live builds. Even though the installed systemd-units package is systemd-units-4-3.fc14.x86_64 , indicating a version new enough to be intended to be the default was available, systemd-units is the *only* systemd package installed, and upstart-sysvinit-0.6.5-7.fc14 is installed, so it seems upstart still gets to be the default. Not sure if that's another packaging issue, or just that the live spin kickstart file needs to be changed.

Adam Williamson (awilliam(a)redhat.com) said: > %define with_upstart 1%{nil} > ... > if with_upstart > Requires: upstart >= 0.6.0 > %else > Requires: SysVinit >= 2.85-38 > %endif > > seems like something that should be changed. readahead, > system-setup-keyboard and vpnc also have direct dependencies on upstart, > presumably because they (I think incorrectly) include upstart-style > scripts in their main packages rather than separating them into a > -upstart subpackage. It's intentional, as there never really was a plan to support multiple init systems.

Adam Williamson (awilliam(a)redhat.com) said: > > > seems like something that should be changed. readahead, > > > system-setup-keyboard and vpnc also have direct dependencies on upstart, > > > presumably because they (I think incorrectly) include upstart-style > > > scripts in their main packages rather than separating them into a > > > -upstart subpackage. > > > > It's intentional, as there never really was a plan to support multiple > > init systems. > > Which bit? Obviously they're *intentional*, no-one writes a Requires > line into a spec file by accident :). I only mean that, if systemd is > going to be the default init system, then these things should be > changed. The 'not separating the scripts into a separate subpackage' bit.

Adam Williamson (awilliam(a)redhat.com) said: > > The 'not separating the scripts into a separate subpackage' bit. > > Ah. I thought the point of separating them wasn't to allow for multiple > init systems, but because our current guidance was to use sysvinit > scripts by default, not upstart scripts; so with them separated off, you > only get the upstart native script if you manually install it. The referenced packages aren't using upstart jobs as a replacement for traditional SysV service scripts... they're using upstart for things that don't really fit in the service paradigm.