Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, 2010-07-30 at 14:41 -0700, darrell pfeifer wrote: > > > On Fri, Jul 30, 2010 at 14:05, Adam Williamson > wrote: > On Wed, 2010-07-28 at 21:56 -0700, darrell pfeifer wrote: > > > I also had the same problem with one core using 100% CPU, in > my case > > for Xorg. > > > I've filed a bug on this - > https://bugzilla.redhat.com/show_bug.cgi?id=619889. > -- > > > > Speaking of blockers, I don't know if this qualifies, but it pretty > much makes X unusable. > > > https://bugzilla.redhat.com/show_bug.cgi?id=602910 > > > I've also had trouble with the latest X not being usable at all on my > laptop (Just a small start of a gnome window in about 1/6 of the > screen) > > > I haven't filed a bug yet (gun-shy since restoring after a dead X is > really tedious, even with my "working X rpm's" backup. Hardware specific bugs are judgment calls (that's what the 'in most cases' weasel phrase in some of the release criteria means). It depends how many people the issue is likely to effect. We'd need a hardware-specific issue to affect a huge amount of people to consider it an alpha blocker, usually. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 30, 2010 at 14:05, Adam Williamson wrote: > On Wed, 2010-07-28 at 21:56 -0700, darrell pfeifer wrote: > > > I also had the same problem with one core using 100% CPU, in my case > > for Xorg. > > I've filed a bug on this - > https://bugzilla.redhat.com/show_bug.cgi?id=619889. > -- > Speaking of blockers, I don't know if this qualifies, but it pretty much makes X unusable. https://bugzilla.redhat.com/show_bug.cgi?id=602910 I've also had trouble with the latest X not being usable at all on my laptop (Just a small start of a gnome window in about 1/6 of the screen) I haven't filed a bug yet (gun-shy since restoring after a dead X is really tedious, even with my "working X rpm's" backup. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, 2010-07-28 at 21:56 -0700, darrell pfeifer wrote: > I also had the same problem with one core using 100% CPU, in my case > for Xorg. I've filed a bug on this - https://bugzilla.redhat.com/show_bug.cgi?id=619889. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, Jul 28, 2010 at 21:20, wrote: > I found a fix on bugzilla: > rpm -e --nodeps systemd-units > yum install systemd-units > Which created the symlinks and default.service which seemed to be missing, > and allowed the boot to finish, but I may have been to quick to use it. One > CPU core is at maximum and Chrome won't open, so I'm temporarily back to > upstart till I get time to look at it further. > > https://bugzilla.redhat.com/show_bug.cgi?id=618315 > > > Thanks for the info and the bugzilla. Reinstalling systemd-units got me a mostly working system. I also had the same problem with one core using 100% CPU, in my case for Xorg. Added my comments to the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
I found a fix on bugzilla: rpm -e --nodeps systemd-units yum install systemd-units Which created the symlinks and default.service which seemed to be missing, and allowed the boot to finish, but I may have been to quick to use it. One CPU core is at maximum and Chrome won't open, so I'm temporarily back to upstart till I get time to look at it further. https://bugzilla.redhat.com/show_bug.cgi?id=618315 -Original Message- From: darrell pfeifer To: Development discussions related to Fedora Sent: Wed, Jul 28, 2010 6:46 pm Subject: Re: [HEADS-UP] systemd is now the default init system in rawhide On Wed, Jul 28, 2010 at 19:33, wrote: Add init=/sbin/upstart to the end of the kernel line and it will boot up using upstart. Last lines in my boot read failing to load default.service and then failing to start default.service. Check one of the recent previous messages. ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target Will solve that problem and get you a bit further along the way. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, Jul 28, 2010 at 19:33, wrote: > Add init=/sbin/upstart to the end of the kernel line and it will boot up > using upstart. Last lines in my boot read failing to load default.service > and then failing to start default.service. > > Check one of the recent previous messages. ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target Will solve that problem and get you a bit further along the way. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Add init=/sbin/upstart to the end of the kernel line and it will boot up using upstart. Last lines in my boot read failing to load default.service and then failing to start default.service. -Original Message- From: darrell pfeifer To: Development discussions related to Fedora Sent: Wed, Jul 28, 2010 5:59 pm Subject: Re: [HEADS-UP] systemd is now the default init system in rawhide I installed the latest systemd and added the appropriate symbolic link to graphical startup. My system hangs when almost complete at the plymouth throbber. In text mode it gets to the end of starting services and hangs. gdm never starts. In /var/log/messages, these seem to be the suspicious lines Jul 28 14:21:26 darrell init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:26 darrell kernel: init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:35 darrell init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s tart timed out. Jul 28 14:21:35 darrell kernel: init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c. device/start timed out. df shows the volume as /dev/mapper/vg_darrell-lv_root Any suggestions? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
I installed the latest systemd and added the appropriate symbolic link to graphical startup. My system hangs when almost complete at the plymouth throbber. In text mode it gets to the end of starting services and hangs. gdm never starts. In /var/log/messages, these seem to be the suspicious lines Jul 28 14:21:26 darrell init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:26 darrell kernel: init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:35 darrell init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s tart timed out. Jul 28 14:21:35 darrell kernel: init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c. device/start timed out. df shows the volume as /dev/mapper/vg_darrell-lv_root Any suggestions? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, 28 Jul 2010 13:55:23 -0700 darrell pfeifer wrote: > On Sat, Jul 24, 2010 at 23:34, Kevin Fenzi wrote: > > > >> > > > > 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? ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, Jul 24, 2010 at 23:34, Kevin Fenzi wrote: > >> > > 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? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Hi On Wed, Jul 28, 2010 at 6:26 AM, Lennart Poettering wrote: > On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote: > >> >> 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. > > Yes, this is the case. Normal users can and should start it and it might > even be invoked by scripts such as gnomerc or suchlike. On most > distributions (with the exception of Fedora) /sbin/ is not in $PATH and > hence the right place for the systemd binary is /bin/ and nothing else. Could put systemd in /sbin and have a symlink to it called /bin/sessiond That would also allow the daemon to know which "mode" it's running in. Still, probably not worth it. --Ray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote: > > 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. Yes, this is the case. Normal users can and should start it and it might even be invoked by scripts such as gnomerc or suchlike. On most distributions (with the exception of Fedora) /sbin/ is not in $PATH and hence the right place for the systemd binary is /bin/ and nothing else. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 11:34 -0400, Bill Nottingham wrote: > Adam Williamson (awill...@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. Ah, I see, that makes sense then. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, Jul 27, 2010 at 12:55:17AM -0700, Matt McCutchen wrote: > 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. The usefulness in the distinction between /bin and /sbin is largely in "what goes in the path". Generally, daemons don't belong in normal user's paths. > > 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. But that's the point of the distinction. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@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. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 11:11 -0400, Bill Nottingham wrote: > Adam Williamson (awill...@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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@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. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 10:48 -0400, Bill Nottingham wrote:
> Adam Williamson (awill...@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.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@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.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 07/26/2010 10:33 PM, Adam Williamson wrote: > On Mon, 2010-07-26 at 11:32 -0400, Peter Jones wrote: >> 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. > > That doesn't sound right. AIUI, the situation is that systemd will be > default for F-14 unless we find it to be horribly broken, hence it will > become the default in F14-Branched when it branches (unless we've > already decided it's horribly broken by then, which doesn't seem > likely). If you consult http://meetbot.fedoraproject.org/meetbot/fedora-meeting/2010-06-15/fesco.2010-06-15-19.35.log.html , you'll see that what FESCo agreed on was that it was a desirable feature, and that we would revisit the question of being default in F-14 later, when there's more actual data. That being said, I expect it will remain default in the branch for at least some amount of time for the same reason, and because that's the default state if nobody specifically changes it. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Matt McCutchen : > 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. what about your dbus-daemon example? > >> 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. what is progress from your point of view? unfortunately i just see that things break for no particular gain which doesent look like progress either. what exactly is the distinction for then? if we do not care about PATH i will agree with all the statements that have been made before in other threads that */bin and */sbin can be just merged because there is no real benefit anymore in separating them. How else can we fix autocompletion? There are plenty of users using shell and are relying on autocompletion for efficient usage of the terminal. > >> 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). what about dbus-daemon... your example? for systemd: if a user is supposed to execute it (or it is executed as regular user upon login) then i agree completly, no questions asked. in its current state it is not the case though. > > -- > Matt > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Rudolf Kastl : > 2010/7/27 Matt McCutchen : >> 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@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > small addition: if you want to move stuff to /bin how about ifconfig and ip. in this regard our system is really a mess and instead of cleaning it up we worked around by polluting the users PATH and completion with */sbin. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Matt McCutchen : > 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/26 Bryn M. Reeves : > -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 well an init system replacement probably has to do with booting the system hence it makes sense from my pov to move the binary to /sbin. it especially makes sense if one unbreaks the user PATH by removing /sbin from it since there is less irrelevant stuff in the PATH environment then for autocompletion. kind regard, Rudolf Kastl p.s. i am going to open a bug > > Regards, > Bryn. > -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- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Mon, 2010-07-26 at 11:32 -0400, Peter Jones wrote: > 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. That doesn't sound right. AIUI, the situation is that systemd will be default for F-14 unless we find it to be horribly broken, hence it will become the default in F14-Branched when it branches (unless we've already decided it's horribly broken by then, which doesn't seem likely). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Mon, 2010-07-26 at 17:45 -0700, Adam Williamson wrote:
> 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.
Addendum - I just checked spin-kickstarts and AFAICT it doesn't
explicitly specify an init system, I guess it relies on dependencies.
I note that initscripts has an explicit dependency on upstart:
%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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, 2010-07-24 at 03:26 +0200, Lennart Poettering wrote: > 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: Aside from the noted conflict, I see this in the build logs for the 20100726 nightly live (http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100726.15-x86_64.log ): Installing: systemd-units### [ 113/1075]/var/tmp/rpm-tmp.3xbHei: line 11: /bin/ln: No such file or directory ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty1.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty2.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty3.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty4.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty5.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty6.service' ln -s '/lib/systemd/system/prefdm.service' '/etc/systemd/system/graphical.target.wants/prefdm.service' ln -s '/lib/systemd/system/getty.target' '/etc/systemd/system/multi-user.target.wants/getty.target' ln -s '/lib/systemd/system/rc-local.service' '/etc/systemd/system/multi-user.target.wants/rc-local.service' ln -s '/lib/systemd/system/remote-fs.target' '/etc/systemd/system/multi-user.target.wants/remote-fs.target' Looks like it's missing a Requires(post), I guess. 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 Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
-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 Regards, Bryn. -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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Lennart Poettering wrote: > 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. Can't be installed. yum wants to install _both_ *-sysvinit (even on freshly installed machines: F13 --> rawhide), they conflict, and thus systemd isn't updated at all. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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? -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 25/07/10 09:16, Piscium wrote: Please try and trim "replied to post(s)* to relevant parts. > > What about sysd? It would save sysadmins typing 3 characters. > Still doesn't help with Google, which I feel is just maybe it's newness? -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 25 July 2010 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 > > 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. ;( What about sysd? It would save sysadmins typing 3 characters. > > 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tangent! [was Re: [HEADS-UP] systemd is now the default init system in rawhide]
On Sat, Jul 24, 2010 at 01:39:20PM -0700, Matt McCutchen wrote: > > > 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 . It looks like it probably _does_. From the gnome.org docs: Understanding how to refresh the MIME database is important for administrators who wish to add new MIME types to the system, or otherwise modify information about a MIME type. The application update-mime-database is intended for this purpose. But that's a long thread I don't want to sidetrack this with. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 07/24/2010 04: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 . > I suspect the argument is likely the other way round - namely its replacing init - therefore probably belongs in /sbin - no ? Oh - and may also do user session management as an additional feature in addition to being the init daemon ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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 . -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri 23 July 2010 18:26:29 Lennart Poettering wrote: [snip] > - 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!) [snip] > If systemd does not work for you and you need a temporary fix, pass > "init=/bin/upstart" on the kernel command line. Hmmm? :) -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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. --CJD > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 08:04:48PM -0700, darrell pfeifer wrote: > On Fri, Jul 23, 2010 at 18:26, Lennart Poettering wrote: > > > 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) > > > > > > > Just gave it a try with the koji of moments ago. > > ---> Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed > --> Processing Dependency: systemd = 4-3.fc14 for package: > systemd-sysvinit-4-3.fc14.x86_64 > --> Processing Dependency: upstart >= 0.6.5-6.fc14 for package: > systemd-sysvinit-4-3.fc14.x86_64 What?! > ---> Package systemd-units.x86_64 0:4-3.fc14 set to be updated > --> Running transaction check > ---> Package systemd.x86_64 0:4-3.fc14 set to be installed > ---> Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated > --> Processing Dependency: sysvinit-userspace for package: Aand this is the other half of the problem. Change I made before Lennart was around to make a complementary change in the systemd package unfortunately. It shouldn't have caused a big issue except for the really bizzare dependency mentioned above. > upstart-0.6.5-7.fc14.x86_64 > --> Running transaction check > ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed > --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts > upstart-sysvinit > --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts > systemd-sysvinit > --> Finished Dependency Resolution > Error: systemd-sysvinit conflicts with upstart-sysvinit > Error: upstart-sysvinit conflicts with systemd-sysvinit > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > > darrell > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 18:26, Lennart Poettering wrote: > 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) > > > Just gave it a try with the koji of moments ago. ---> Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed --> Processing Dependency: systemd = 4-3.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 --> Processing Dependency: upstart >= 0.6.5-6.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 ---> Package systemd-units.x86_64 0:4-3.fc14 set to be updated --> Running transaction check ---> Package systemd.x86_64 0:4-3.fc14 set to be installed ---> Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated --> Processing Dependency: sysvinit-userspace for package: upstart-0.6.5-7.fc14.x86_64 --> Running transaction check ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit --> Finished Dependency Resolution Error: systemd-sysvinit conflicts with upstart-sysvinit Error: upstart-sysvinit conflicts with systemd-sysvinit You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
