Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Le mardi 24 août 2010 à 16:38 -0400, Bill Nottingham a écrit : Lennart Poettering (mzerq...@0pointer.de) said: PACKAGING - Guidelines for packaging systemd units shall be formalized. As pointed out elsewhere, I'd avoid this for F14. Then we should put don't in the guidelines, instead. We need to set clear expectations for package maintainers as to what they should be doing. (And certainly not switching the state of their packages mid-release.) Anyway, we have branched now, so rawhide is already F15-to-be, and F15 will hopefully include systemd units, so the packaging guidelines for F15 need to be formalized *now* and not at the last minute. Please do not wait for F15 branch point to formalize packaging guidelines for systemd units. Do it now so they can be added and QAed during all the F15 devel cycle (which is already open) or services will need to be patched with band-aid and sticky take at F15 alpha time. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, 2010-08-25 at 09:49 +0200, Kevin Kofler wrote: Matt McCutchen wrote: I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. Don't Do That Then. :-) It's just another reason to stick with systemd. That's no answer. As for any feature, we need a contingency plan in case a problem is discovered that cannot be fixed in time. At least, I believe FESCo accepted the systemd feature with the understanding that it could be rolled back if necessary. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
seth vidal wrote: It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. Same here, I have used interactive boot more than once to fix a non-booting system. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Adam Williamson wrote: for clarity - no, there's nothing magic about five releases ago. Five was a Random Rhetorical Number. :) I don't know the last time we had a major init system change, whenever it was, I wasn't around. You actually guessed the correct number. Upstart was introduced in Fedora 9 (Fedora 8 used the old SysVInit), so exactly the last five releases at Fedora 14's release time, i.e. Fedora 9, 10, 11, 12 and 13, were using it. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Matt McCutchen wrote: I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. Don't Do That Then. :-) It's just another reason to stick with systemd. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Lennart Poettering wrote: You can actually use systemd.confirm_spawn=yes on the kernel cmdline. This should work fine for an interactive boot and things are synchronized via tty ownership. However, I am not sure how useful this all is, given that we starte gdm pretty early (which then owns the console tty and hence makes it impossible to ask any further questions which then timeout) and this options asks a confirmation question for *everything* we start, not just sysv services. That means you get even asked on shutdown, and when we activate bus services. systemd.confirm_spawn=yes is a debugging tool, but I don't think this is useful for a broader audience or ever could be made useful for a broader audience. I don't see these as unsolvable problems: * Starting prefdm or gettys can be delayed when using interactive boot. * It can just stop asking for confirmation after a certain target is reached, e.g. after prefdm or gettys is started. One possible implementation would be to have an EndsInteractiveBoot target property. When that is set to yes, which it would be for prefdm and gettys, systemd should 1. try to execute it as late as possible, i.e. only when there are no other pending changes not depending on that target and 2. stop confirmation prompts after starting that service is confirmed. Another question is whether we need to ask for confirmation for items which don't normally block booting in the first place. If such items hang, they can just be killed by the user. Unless we introduce some kind of interactive UI that somehow doesn't clash with gettys or gdm being active on a tty I don't hink we can ever make interactive boots work again. Wasn't one of the points of KMS to be able to switch a console to text mode at any time? That said, getting dropped back to text mode from my KDE to confirm activating some service probably isn't useful (see also my note above about non-blocking items). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Lennart Poettering wrote: But you enable them to block out change. For example, if somebody refuses to merge a patch that adds a systemd equivalent for an upstart config hook he has, … then a provenpackager should just commit the change. We should trust maintainers in most cases, but if they're refusing to cooperate with distrowide projects, we shouldn't hesitate to overrule and/or circumvent them. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Bill Nottingham wrote: Lennart Poettering (…) said: [snip] We want prefdm to start as early as possible. That is a separate discussion that should be had once we have the basic functionality verified and working, IMO. If we want to reorganize around early login, we should do that as a coordinated effort in F-15, not as an ad-hoc side-effect of the systemd configuration. Well, early login (and parallelization, of which systemd's implementation of early login is just a special case) is a core selling feature of systemd. If we require everything to be serialized, we've lost much of the reason to use systemd in the first place. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On 08/24/2010 05:06 AM, Bill Nottingham wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. -- The services shall function the same. -- The same set of devices and filesystems shall be mounted. -- The same set of devices and filesystems shall be fscked. It should also mount nothing else unless it is absolutely necessary for systemd! Currently systemd mounts all control groups controllers (/cgroup/cpu, /cgroup/cpuset, /cgroup/cpuacct, ...), which breaks libcgroup. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 12:58:26PM +0200, Jan Safranek wrote: It should also mount nothing else unless it is absolutely necessary for systemd! Currently systemd mounts all control groups controllers (/cgroup/cpu, /cgroup/cpuset, /cgroup/cpuacct, ...), which breaks libcgroup. bug number? -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On 08/25/2010 01:59 PM, Matthew Miller wrote: On Wed, Aug 25, 2010 at 12:58:26PM +0200, Jan Safranek wrote: It should also mount nothing else unless it is absolutely necessary for systemd! Currently systemd mounts all control groups controllers (/cgroup/cpu, /cgroup/cpuset, /cgroup/cpuacct, ...), which breaks libcgroup. bug number? https://bugzilla.redhat.com/show_bug.cgi?id=626794 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 02:05:01PM +0200, Jan Safranek wrote: bug number? https://bugzilla.redhat.com/show_bug.cgi?id=626794 thanks. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote: I'm going to be blunt. I DON'T CARE. Yay, thanks that you don't care. You are aware that by putting everything on a single man's shoulders and then telling him you don't care you make him feel really welcome and make him wonder why he even bothers with this shit? Sure, I suppose individual maintainers want to push their code over the wall and then sit in their silo and claim 'that's not my problem' and 'someone else needs to fix that', well, that's their right to be lame. But we, as Fedora, as producers of a product that we ship to our users, don't have that luxury. But you enable them to block out change. For example, if somebody refuses to merge a patch that adds a systemd equivalent for an upstart config hook he has, he can sink the whole systemd in fedora project. I am pretty sure some folks would be really happy to have that power... Hey, lets not get carried away here. It is pretty clear that Bills list of checkpoints for init / boot functionality covered not just systemd, but plymouth, gdm, initscripts, kernel, dracut, and a bunch of other early userspace packages. I'm sure the maintainers of those packages will be willing to help with making the init / boot experience of Fedora 14 great. To my knowledge, this is the first time we've ever looked at codifying what behaviours we expect in this area (why didn't we do this exercise for upstart ?). It is very useful, and if nothing else, this is already a very useful outcome of the systemd adventure. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 3:27 PM, Matthias Clasen mcla...@redhat.com wrote: On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote: I'm going to be blunt. I DON'T CARE. Yay, thanks that you don't care. You are aware that by putting everything on a single man's shoulders and then telling him you don't care you make him feel really welcome and make him wonder why he even bothers with this shit? Sure, I suppose individual maintainers want to push their code over the wall and then sit in their silo and claim 'that's not my problem' and 'someone else needs to fix that', well, that's their right to be lame. But we, as Fedora, as producers of a product that we ship to our users, don't have that luxury. But you enable them to block out change. For example, if somebody refuses to merge a patch that adds a systemd equivalent for an upstart config hook he has, he can sink the whole systemd in fedora project. I am pretty sure some folks would be really happy to have that power... Hey, lets not get carried away here. It is pretty clear that Bills list of checkpoints for init / boot functionality covered not just systemd, but plymouth, gdm, initscripts, kernel, dracut, and a bunch of other early userspace packages. I'm sure the maintainers of those packages will be willing to help with making the init / boot experience of Fedora 14 great. To my knowledge, this is the first time we've ever looked at codifying what behaviours we expect in this area (why didn't we do this exercise for upstart ?). It is very useful, and if nothing else, this is already a very useful outcome of the systemd adventure. Indeed, imo we should add them to the release criteria. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, 25.08.10 03:03, Miloslav Trmač (m...@volny.cz) wrote: If the libraries or binaries used by systemd are replaced during runtime, and it is not re-executed on shutdown, the filesystem will have busy inodes on shutdown. (If you'd like to take the filesystem semantics up with the kernel, feel free to tilt at that windmill.) snip Well, what me still puzzles is this: the reexec is done asynchronously, via signals. Shouldn't this be done synchronously at least to make sure the daemon really is reexec'ed when we try to remount r/o? The traditional solution is to reexec not on shutdown, but immediately after init upgrade (which also frees the inodes early); this can still race with shutdown in theory, but is probably good enough in practice. Well, while reexecing on package upgrades might kinda help fix the issue I think it doesn't really scale, because you'd have to reexec systemd when any of the libs it uses is upgraded, i.e. glibc, audit, selinux, tcpwrap, pam, libcap. So I guess there's isn't really any other option then reexecing init in some way on shutdown. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 04:08:49PM +0200, Lennart Poettering wrote: On Wed, 25.08.10 03:03, Miloslav Trmač (m...@volny.cz) wrote: The traditional solution is to reexec not on shutdown, but immediately after init upgrade (which also frees the inodes early); this can still race with shutdown in theory, but is probably good enough in practice. Well, while reexecing on package upgrades might kinda help fix the issue I think it doesn't really scale, because you'd have to reexec systemd when any of the libs it uses is upgraded, i.e. glibc, audit, selinux, tcpwrap, pam, libcap. glibc %post (and prelink cron scripts) already telinit u when libc/ld.so (resp. any library) changes. So I guess there's isn't really any other option then reexecing init in some way on shutdown. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, 2010-08-25 at 15:35 +0200, drago01 wrote: Indeed, imo we should add them to the release criteria. It's a rather indigestible lump, for the criteria. James and I were thinking about a 'module' system for the release criteria so it can link out to other pages, but I'm wondering when a dilution effect would start kicking in. I'm not sure everything on that list is genuinely something we'd hold up a release for, either. But it's certainly something I want to use for the systemd test day. -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. We need something in here about cgroups. Doing something useful by default with cgroups is one of the big selling points for systemd. We should be clear on what's intented to work now (each user session in a unique cgroup) and insure that that's working, document (loosely) plans for the future, and define how systemd's use of cgroups should interact with other tools (like libcgroup) for this release and for the future. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Chris Adams (cmad...@hiwaay.net) said: This is a very big change. chkconfig has worked for a long, long time. Its elegance and simplicity is one of the nice administrative features of Red Hat based distributes. People like it. Yes, and they should continue to use it -- for sysv scripts. I thought the last big discussion resulted in agreement that chkconfig and service should continue to work for all services. Is that not the case? service can, because it's pretty much a 1:1 mapping. (It's currently fixed in git; it's telling you it's using systemctl while doing the appropriate thing.) chkconfig is different, because it's not a 1:1 mapping, and there are different semantics involved. I'd like to have it working so that the automated uses in scripts/frameworks work (checking whether a service is enabled, for example), with the realization that everything it's used for isn't going to be supported. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Lennart Poettering (mzerq...@0pointer.de) said: Hmm, so this is about files that are deleted but still mapped by init, and which can only be deleted when init stops referencing them, but that is required to remount the fs r/o? Did I get this right? Correct. I am not really convinced that reexecing is the right answer for this problem. But well, since this already works anyway I guess this doesn't really matter too much. It's the only answer I know of which doesn't require kernel changes. PACKAGING - Guidelines for packaging systemd units shall be formalized. As pointed out elsewhere, I'd avoid this for F14. Then we should put don't in the guidelines, instead. We need to set clear expectations for package maintainers as to what they should be doing. (And certainly not switching the state of their packages mid-release.) Well, if we can agree on don't, unless you contacted Lennart or [add list here] and he said it's OK then I am fine with this. That works for me. Well, if we can agree on after all sysv services that include no proper ordering dependency information in the LSB headers, then I'd be fine with this. If sysv services contain LSB headers, we should follow the ordering it encodes, not come with implicit additional rules. SysV services don't have a dependency concept of 'this needs to run after me', AFAIK. So rc.local always implying 'I'm the last thing' isn't something that could be stated correctly in mere LSB deps. OK, so now you've stated 5 times in this mail some equivalent of 'that's not my package, it shouldn't be my problem, I don't want to be responsible for this.' I'm going to be blunt. I DON'T CARE. Yay, thanks that you don't care. You are aware that by putting everything on a single man's shoulders and then telling him you don't care you make him feel really welcome and make him wonder why he even bothers with this shit? I'm not putting it on the shoulders of one man. I'm putting it on the shoulders of *the project*. These are the issues that need to work; these are the bugs that need to be fixed. If the scenarios have problems, we'll assign bugs and go from there. But in *generating* the scenarios that need to work, I'm not concerned with whose plate it falls on - it falls on everyone's. Sure, I suppose individual maintainers want to push their code over the wall and then sit in their silo and claim 'that's not my problem' and 'someone else needs to fix that', well, that's their right to be lame. But we, as Fedora, as producers of a product that we ship to our users, don't have that luxury. But you enable them to block out change. For example, if somebody refuses to merge a patch that adds a systemd equivalent for an upstart config hook he has, he can sink the whole systemd in fedora project. I am pretty sure some folks would be really happy to have that power... That's what provenpackager and FESCo is for. We've forced patches to be merged in the past. (Related to PA, if I remember right.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 03:27:54PM -0400, Bill Nottingham wrote: chkconfig is different, because it's not a 1:1 mapping, and there are different semantics involved. I'd like to have it working so that the automated uses in scripts/frameworks work (checking whether a service is enabled, for example), with the realization that everything it's used for isn't going to be supported. I think that either having chkconfig working fully *or* having an arguably improved systemd replacement¹ is a blocker. The automated uses should work, but also these basic end-user/admin use cases (refinements welcome, btw): - enable a service in its normal targets - disable a service in all targets - enable/disable a service (unit in systemd-speak) in a given target with one easy command - nicely list all units that will be enabled in a given target (recursively, with some thought put into the formatting) - nicely list all targets in which a given unit will be enabled (with the option of only showing targets which are sensible for isolate/switch-to). I don't think this is an onerous requirement, because systemctl already does the first two things, and does the last two are almost there (just with no pretty output). The middle thing, as I understand it, Lennart would rather people do by manually creating and moving symlinks, but I think there's a pretty good case for having a user-interface to do it. (That case being: people used to administer sysvinit runlevels by manipulting symlinks, and it sucked. Then we got chkconfig as standard, and it was much nicer.) And in the or case, there needs to be really good release notes, offering tasty, tasty cake. That is: 1) explaining that the change is necessary because the semantics don't match exactly, 2) giving a concise explanation of why the new semantics are better 3) showing off the command and how to use it 4) showing something cool this give you that chkconfig doesn't offer. 1. as discussed here: http://lists.fedoraproject.org/pipermail/devel/2010-August/141713.html -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 5:56 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-08-25 at 15:35 +0200, drago01 wrote: Indeed, imo we should add them to the release criteria. It's a rather indigestible lump, for the criteria. James and I were thinking about a 'module' system for the release criteria so it can link out to other pages, but I'm wondering when a dilution effect would start kicking in. I'm not sure everything on that list is genuinely something we'd hold up a release for, either. But it's certainly something I want to use for the systemd test day. Well I am not saying go add the whole list ... but at least a subset of it. Having a working initsystem should be release goal imo (where working is more than just it boots). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On 08/23/2010 11:06 PM, Bill Nottingham wrote: (intentionally breaking thread) Toshio Kuratomi (a.bad...@gmail.com) said: Maybe I should start a new thread since this isn't really a bug, but it is a blocker -- we need to get some packaging guidelines out for systemd. I think that the last message on the subject was this one: http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html Could I get a reply as to whether that looks right? - At the moment, /bin/systemctl is in systemd-units. (I think this is a bug. Filed.) - As long as we're still shipping upstart, the sysv scripts would still need included, and would still need to be set up with chkconfig the same way. As noted in the post, I'm not sure if the outlined procedure correctly implements level 1. I believe it does. We should probably also have the scriptlets for implementing level 3 for the things basic to the system that require that. My reading of your mail is different - the case we want to handle is case #2 (installation of something that starts by default - dbus, NM, etc.) As I understand it, they would be the same, with the addition of: %post if [ 0$1 -eq ]; then /bin/systemctl enablefoo.service fi with foo.service having the appropriate [Install] stanza that says where it should start up. As with SysV scripts, we generally do not start services by default, so this is rare. Case #3 that you mentioned is something I don't think we have in Fedora - we never start services on package installation. This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. File /etc/inittab should keep working at the same level it is now. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
2010/8/24 Miroslav Lichvar mlich...@redhat.com: On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. Also, if chkconfig --add called systemctl enable when the sysv script is enabled, most of the current scriptlets probably wouldn't need any changes. The status of systemd and sysv services would be required to stay in sync though. keeping compatibility to chkconfig is in my opinion a key requirement to really find acceptance as a replacement. kind regards, Rudolf Kastl -- Miroslav Lichvar -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: Hey Bill, this is a very good initial list, this should make it very easy for QA to whip up a test plan for systemd. Some comments below. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). RUNTIME TOOLS - telinit [0123456] does the proper thing. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. - 'halt' shuts down, but does not poweroff. -- 'halt' supports -p, to power off. - 'poweroff' shuts down, and powers off. - 'reboot' shuts down and reboots. - 'halt', 'poweroff', 'reboot' all support '-f', to force the action. - 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and the audit layer. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', time. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. - the kbdrequest job currently in systemd will be disabled for final release. - 'ctrl-alt-delete' will reboot the system. Should include chkconfig here, probably ? PREFDM - prefdm starts a configured display manager correctly. - prefdm starts a installed display manager correctly without additional configuration. CONSOLEKIT - ConsoleKit properly logs system start, stop, and restart. - The ConsoleKit shutdown/reboot/halt methods work as expected. SERIAL CONSOLES - Booting with a primary serial console (via console=) automatically sets up a getty on the console, and sets up securetty to allow for root login. - (optional) Booting with secondary serial consoles does the same. NON-SERIAL CONSOLES - By default, 6 gettys will be started in text mode, on tty1-6. 5 gettys will be started in GUI mode, on tty2-6. - getty and X will not be started on the same tty. - (optional) The number of ttys started can be configurable. ERROR HANDLING - SELinux automatic relabelling will still function. - fsck will still function. - Dropping to an emergency shell in the case where either of these fails shall still function. SELINUX - No AVCs from the init system in normal use. - No AVCs when executing any of the cases specified here - systemd shall still function if booted with selinux=0. PACKAGING - Guidelines for packaging systemd units shall be formalized. - The behavior when both systemd units and SysV services are present on the system shall be defined. This includes defined behavior when a service appears to be 'enabled' for SysV links while 'disabled' for systemd (and vice-versa). - The syntax of systemd units shall be frozen for the release (all future releases? Some set number of releases?) Can you clarify this a bit ? I assume what we want is that future systemd releases remain backwards compatible with systemd units of today. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2010 08:45 AM, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: Hey Bill, this is a very good initial list, this should make it very easy for QA to whip up a test plan for systemd. Some comments below. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). RUNTIME TOOLS - telinit [0123456] does the proper thing. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. - 'halt' shuts down, but does not poweroff. -- 'halt' supports -p, to power off. - 'poweroff' shuts down, and powers off. - 'reboot' shuts down and reboots. - 'halt', 'poweroff', 'reboot' all support '-f', to force the action. - 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and the audit layer. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', time. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. - the kbdrequest job currently in systemd will be disabled for final release. - 'ctrl-alt-delete' will reboot the system. Should include chkconfig here, probably ? PREFDM - prefdm starts a configured display manager correctly. - prefdm starts a installed display manager correctly without additional configuration. CONSOLEKIT - ConsoleKit properly logs system start, stop, and restart. - The ConsoleKit shutdown/reboot/halt methods work as expected. SERIAL CONSOLES - Booting with a primary serial console (via console=) automatically sets up a getty on the console, and sets up securetty to allow for root login. - (optional) Booting with secondary serial consoles does the same. NON-SERIAL CONSOLES - By default, 6 gettys will be started in text mode, on tty1-6. 5 gettys will be started in GUI mode, on tty2-6. - getty and X will not be started on the same tty. - (optional) The number of ttys started can be configurable. ERROR HANDLING - SELinux automatic relabelling will still function. - fsck will still function. - Dropping to an emergency shell in the case where either of these fails shall still function. SELINUX - No AVCs from the init system in normal use. - No AVCs when executing any of the cases specified here - systemd shall still function if booted with selinux=0. PACKAGING - Guidelines for packaging systemd units shall be formalized. - The behavior when both systemd units and SysV services are present on the system shall be defined. This includes defined behavior when a service appears to be 'enabled' for SysV links while 'disabled' for systemd (and vice-versa). - The syntax of systemd units shall be frozen for the release (all future releases? Some set number of releases?) Can you clarify this a bit ? I assume what we want is that future systemd releases remain backwards compatible with systemd units of today. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 08:45 -0400, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). Depends on the driver, but yeah. - ajax 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 10:00 -0400, Adam Jackson wrote: On Tue, 2010-08-24 at 08:45 -0400, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. I know it worked in rhel4 and rhel5 - so circa: fedora 3 and fedora 6 at the very least. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:00:55AM -0400, Adam Jackson wrote: I can't remember interactive boot ever working. It does in RHEL 5. It will need to be working for RHEL 7. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:18:27AM +0200, Tomasz Torcz wrote: File /etc/inittab should keep working at the same level it is now. Now it only selects default runlevel. How about: - If /etc/inittab exists and contains an initdefault line, the default target will be set accordingly. - any other non-comment, non-blank lines in /etc/inittab will be logged as warnings. This leaves a migration path (ditch the file completely) while maintaining some backwards compatibility. For a number of releases, the file can continue to exist with a warning in the comments and the release notes, and then eventually it can go away. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's reasonable to ask that making that selection doesn't significantly change what gets started -- *or*, that if it is expected to behave differently, all ways in which it will be different are clearly documented in the release notes. Cases where I think documenting differences is appropriate rather than requiring identical behavior would be: - services which take advantage of fancy new systemd features - services which take advantage of any upstartd features which systemd does not implement in a similar fashion (if such things exist). - services where the end-user has gone out of their way to configure upstart in a fancy non-default way. It'd be *nice* if the last case could automatically work too, but I'm not expecting magic. So instead, we need to be clear. - The basic syntax of systemd commands shall be frozen for future releases. - The syntax of systemd units shall be frozen for future releases. Again, the best we can ask for is backwards compatibility, I think. 'Frozen' is entirely too strong for a 2 month old project. In fact, I think we need some flexibility to change things which turn out to be sub-optimal once they're out in the real world. Freezing these decisions too soon is one of the strong arguments for waiting until F15. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: RUNTIME TOOLS - telinit [0123456] does the proper thing. It currently doesn't, by the way. But there's been upstream fixes which aren't yet in rawhide, so I'll retest when that's available. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. Correct meaning not just the highest-numbered synonymous runlevel, but the one which was selected? From one point of view, it tells you something that is correct now. From a practical point of view, I think what's actually important is: -- if you're in single user mode → it says 'S' -- if you're in non-GUI multiuser → it says '3' -- if you're in X mode→ it says '5' Because that's what people are testing for in scripts. It should also print the correct _previous_ runlevel. I note that the man page for Fedora 13's runlevel command (and RHEL 5's, for that matter) claims that init will set the environment variables RUNLEVEL and PREVLEVEL, but that doesn't seem to actually happen. The systemd man page for runlevel doesn't say that init will set those, but says that if they *are* set, that's where it will get its information. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', time. Including acting like the current shutdown command with times e.g. tomorrow morning. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. Since it already is documented as doing the similar actions, let's remove optionally from this statement. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. Please also include 'restart' and 'reload'. And if 'graceful' for httpd and any other services which support that kind of thing will no longer work, that needs to be documented in big bold letters. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. Likewise, commands like apache's 'apachectl graceful' need to continue working, even if upstart does something special to start those services. (I don't know that they wouldn't; it just should go on the list.) I would like to see tab-completion for systemctl working before the final release. That's a request, though, not a demand. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. - Running 'service foo status will' produce a concise human-understandable output and the apppropriate return code -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 11:15 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24 Aug 2010, Adam Williamson wrote: On Tue, 2010-08-24 at 11:15 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Matthew Miller (mat...@mattdm.org) said: How about: - If /etc/inittab exists and contains an initdefault line, the default target will be set accordingly. - any other non-comment, non-blank lines in /etc/inittab will be logged as warnings. This leaves a migration path (ditch the file completely) while maintaining some backwards compatibility. For a number of releases, the file can continue to exist with a warning in the comments and the release notes, and then eventually it can go away. As stated in the bug, this would lead to a situation where you could have both a initdefault line, and a default.target symlnk, that select different things. How would you arbitrate? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. This looks great, and I'd definitely like to use it as the basis for the systemd test day. Once comments and so on are in, could you post a 'version 2.0'? 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
seth vidal (skvi...@fedoraproject.org) said: You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. The keyboard shortcut has not worked reliably in quite a while (and is already removed in F-14 - the command line option is there.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On 08/24/2010 04:18 AM, Tomasz Torcz wrote: On Tue, Aug 24, 2010 at 03:33:59AM -0400, Jeff Garzik wrote: BOOTUP - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. File /etc/inittab should keep working at the same level it is now. Now it only selects default runlevel. Correct. Hence at the same level it is now, meaning same level of functionality. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 15:23 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 10:11:58AM -0700, Adam Williamson wrote: If we're still including upstart as a fallback option, I think it's The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. Making a big change like that _after_ beta seems like an invitation to trouble, but I'll give the benefit of the doubt to you as the QA guy. So in that case, the requirement could simply be that at the time of the beta, they do basically the same things, or in cases where they do different things, it is 1) intentional *and* 2) documented. It's not really a big change, it's a couple of lines in a couple of spec files, and it's fairly easy to test (do live/image composes still pull systemd? does an upgrade from f13 replace upstart with systemd? okay, then we're good). It has nothing like the wide scope of the actual *code* change involved here, which we will have been testing all along. -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, 23.08.10 23:06, Bill Nottingham (nott...@redhat.com) wrote: (intentionally breaking thread) Toshio Kuratomi (a.bad...@gmail.com) said: Maybe I should start a new thread since this isn't really a bug, but it is a blocker -- we need to get some packaging guidelines out for systemd. I think that the last message on the subject was this one: http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html Could I get a reply as to whether that looks right? - At the moment, /bin/systemctl is in systemd-units. (I think this is a bug. Filed.) No, this is actually intended that way: systemd-units contains everything necessary by packages that want to ship systemd unit files: the dirs to place them in, some of the deps and the tool to enable/disable them. Everything for actually booting systemd otoh is in the systemd package. This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. While I think this is a good idea I am concernced a bit that this makes me responsible for stuff I am not willing to take responsibility of. i.e. if something from this list is broken, but it isn't systemd's fault then this should not be a reason to drop systemd from F14. Also, some of this I am not really able or willing to test (iscsi...), so I don't want to be responsible to fix this. I think the list is generally good, but the process for handling it should be that bugs are filed about items from the list which don't work correctly and be marked as blockers. But if they are subsequently reassigned to other packages, then this should not reflect back to systemd. Some comments on the individual items. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Except maybe the first three items this is completely independent of systemd. I am not willing to take responsibility for bugs that are in Plymouth, in X, or in the kernel. - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. This is bad. While we support this just fine I think it is a really bad idea to reexec init at shutdown. What's the point of this, can you elaborate on this? This smells to me as a workaround for brokeness in older init systems, and I don't see a reason why reexecing itself would be necessary for systemd. Also, let's not forget that this requirement didn't exist for Upstart. Upstart always has been and still is unable to reexec itself. PREFDM - prefdm starts a configured display manager correctly. - prefdm starts a installed display manager correctly without additional configuration. Hmpf, especially the second item is notthing systemd has an influence on. CONSOLEKIT - ConsoleKit properly logs system start, stop, and restart. - The ConsoleKit shutdown/reboot/halt methods work as expected. Well, I think we had som probs with PK here, but I don't want to be responsible for fixing PK either. SERIAL CONSOLES - Booting with a primary serial console (via console=) automatically sets up a getty on the console, and sets up securetty to allow for root login. I cannot say I am particularly happy with how securetty has been handled so far: entries are only added, not removed from securetty, and the root directory must be writable. I'd see this fixed differently, i.e. in pam_securetty so that it verifies the kernel console= switch internally. - (optional) Booting with secondary serial consoles does the same. Hmm, could you elaborate on this? We have discussed this a couple of times upstream, and came to the conclusion that the only safe thing to do is to run a getty only on the main kernel console, i.e. where input is accepted from. PACKAGING - Guidelines for packaging systemd units shall be formalized. As pointed out elsewhere, I'd avoid this for F14. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. Hmpff. I don't think this is a good idea. chkconfig should manage SysV scripts, and systemctl enable should manage systemd units. But interpolating this would create the impression the semantics were identical, although they really aren't. What would make sense to add to chkconfig is something that checks whether a systemd unit is installed and then prints Hey, you have a systemd unit
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 09:44, Daniel J Walsh (dwa...@redhat.com) wrote: I would add security things. Starting a service sends audit messages from the proper loginuid. I am sure Steve Grub has lots of concerns here also. This is not fair! Upstart never did this. We do this now in systemd, as the first init system on Linux at all. Acknowledge this as a new feature. Don't make this a release requirement. Restarting or starting a service ends up transitioning to the proper domain (Might be an SELinux domain.) directories, sock_files created by systemd end up with the proper context and confined domains see the remote socket as the proper label not, init_t. For example if I setup mysql to be autostarted by systemd then when apache connects to the /var/run/mysql/socket it sees this socket labeled mysqld_var_run_t and the remote end as mysqld_t. With the latest patches we merged this should in theory all be fixed, right? Or is there anything still left to do in this area? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 14:28 -0400, Bill Nottingham wrote: seth vidal (skvi...@fedoraproject.org) said: You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. The keyboard shortcut has not worked reliably in quite a while (and is already removed in F-14 - the command line option is there.) Works in rhel5. I'll test it in rhel6 in just a sec. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 13:28, Bill Nottingham (nott...@redhat.com) wrote: Matthias Clasen (mcla...@redhat.com) said: BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Yes. Do we consider interactive boot essential (I think not) ? This seems rather complicated, given the parallel nature of how systemd starts things. You can actually use systemd.confirm_spawn=yes on the kernel cmdline. This should work fine for an interactive boot and things are synchronized via tty ownership. However, I am not sure how useful this all is, given that we starte gdm pretty early (which then owns the console tty and hence makes it impossible to ask any further questions which then timeout) and this options asks a confirmation question for *everything* we start, not just sysv services. That means you get even asked on shutdown, and when we activate bus services. systemd.confirm_spawn=yes is a debugging tool, but I don't think this is useful for a broader audience or ever could be made useful for a broader audience. Unless we introduce some kind of interactive UI that somehow doesn't clash with gettys or gdm being active on a tty I don't hink we can ever make interactive boots work again. Yes. The idea is that if someone writes a systemd unit file today, they're not going to need to change its syntax, or where they put it, or how they enable it in future releases, unless they're changing it to use *new* features of systemd. My plan is to stay compatible with the file format used in the final F-14 for subequent releases. While we might rename an option or make an option redundant we will continue to read the old configuration then and do the right thing. I meant 'as booting in upstart on the same release'. It's still an option in the F-14 branched tree. -- The services shall function the same. This is again not really much of a systemd requirement. It's a place where systemd can cause regressions due to the change in how services are started. See the current (now fixed?) NetworkManager problems. Grmbl, let's also note one thing: if LSB headers of init scripts are incorrect of arbitrary packages I don't want to be held responsible for that either. The LSB data must be more correct than it used to be. But that's not a bug in systemd... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Matthew Miller (mat...@mattdm.org) said: The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. Making a big change like that _after_ beta seems like an invitation to trouble, but I'll give the benefit of the doubt to you as the QA guy. So in that case, the requirement could simply be that at the time of the beta, they do basically the same things, or in cases where they do different things, it is 1) intentional *and* 2) documented. My concern is with maintaining two init systems for the life of the release. We have two potential situations: - We decide to punt systemd by default to F-15. In this case, maintaining systemd in F-14 actively hurts your ability to fix it - you're punting it to F-15 so you can do more active development and testing of it there. So, you'll have code in F-14 which either a) needs constantly updated to match the testing codebase in F-15, possibly spreading to other packages that interact with systemd, or b) is constantly out of date and effectively unsupported/stillborn. So, in this case, I strongly suggest only going with upstart in F-14, and systemd in F-15. (Perhaps set up something on repos.fp.o for those that would want to test on F-14.) - We decide to have systemd by default in F-14. This case is a little different. However, if we're planning on dropping upstart in F-15, does it help us to have it in F-14 to be maintained for the life of the release, knowing that we're not planning on updating it, ehancing it, or including it in a later release? It also causes problems for documentation, in that all your documentation will have to have 'if upstart do foo, if systemd do bar', etc. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 15:46 -0400, seth vidal wrote: On Tue, 2010-08-24 at 14:28 -0400, Bill Nottingham wrote: seth vidal (skvi...@fedoraproject.org) said: You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. The keyboard shortcut has not worked reliably in quite a while (and is already removed in F-14 - the command line option is there.) Works in rhel5. I'll test it in rhel6 in just a sec. Doesn't work in rhel6 :( sad panda -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
seth vidal (skvi...@fedoraproject.org) said: I'll test it in rhel6 in just a sec. Doesn't work in rhel6 :( If you hold down the key long enough at the right time, it sort of works. That's not really how we want to have it going forward, for obvious reasons. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 09:33:50PM +0200, Lennart Poettering wrote: What would make sense to add to chkconfig is something that checks whether a systemd unit is installed and then prints Hey, you have a systemd unit installed, chkconfig won't do what you think it will do for this unit or so. This is a very big change. chkconfig has worked for a long, long time. Its elegance and simplicity is one of the nice administrative features of Red Hat based distributes. People like it. If you take it away and print a message about how the user is doing it wrong, this will create negative energy. I think I gave the example of nslookup vs. host and dig -- that created a huge amount of grumbling among sysadmins, and _the new thing was clearly better_. It may be that the change is worth it. But then, you have to do three things: 1) sell the advantages of the new thing really hard. There MUST be cake. 2) DO NOT discount the pain of changing. Cuddle people; be on their side. If you overlook the importance of this, you're shooting systemd in the foot and it's going to have to limp up the hill. Even if chkconfig is just one silly command that doesn't matter very much. Really! It is the case. I'm starting to feel a bit like Cassandra here. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 12:14, Mike McGrath (mmcgr...@redhat.com) wrote: On Tue, 24 Aug 2010, Adam Williamson wrote: On Tue, 2010-08-24 at 11:15 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? No. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 11:47, Matthew Miller (mat...@mattdm.org) wrote: From a practical point of view, I think what's actually important is: -- if you're in single user mode → it says 'S' It actually returns 1 in this case. -- if you're in non-GUI multiuser → it says '3' -- if you're in X mode→ it says '5' Because that's what people are testing for in scripts. It should also print the correct _previous_ runlevel. I note that the man page for Fedora 13's runlevel command (and RHEL 5's, for that matter) claims that init will set the environment variables RUNLEVEL and PREVLEVEL, but that doesn't seem to actually happen. The systemd man page for runlevel doesn't say that init will set those, but says that if they *are* set, that's where it will get its information. Yepp, that's for compatibility with Upstart. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. Since it already is documented as doing the similar actions, let's remove optionally from this statement. Well, Upstart doesn't support reexec. We support it just fine, but if we wouldn't this should not count as regression. I would like to see tab-completion for systemctl working before the final release. That's a request, though, not a demand. Happy to take patches! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 15:55, Matthew Miller (mat...@mattdm.org) wrote: On Tue, Aug 24, 2010 at 09:33:50PM +0200, Lennart Poettering wrote: What would make sense to add to chkconfig is something that checks whether a systemd unit is installed and then prints Hey, you have a systemd unit installed, chkconfig won't do what you think it will do for this unit or so. This is a very big change. chkconfig has worked for a long, long time. Its elegance and simplicity is one of the nice administrative features of Red Hat based distributes. People like it. Yes, and they should continue to use it -- for sysv scripts. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 01:20:21PM -0400, Bill Nottingham wrote: As stated in the bug, this would lead to a situation where you could have both a initdefault line, and a default.target symlnk, that select different things. How would you arbitrate? Well, also as stated in the bug :), always follow the /etc/inittab first. If if it makes sense, perhaps systemd should change the default.target to match. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 16:14, Matthew Miller (mat...@mattdm.org) wrote: On Tue, Aug 24, 2010 at 01:20:21PM -0400, Bill Nottingham wrote: As stated in the bug, this would lead to a situation where you could have both a initdefault line, and a default.target symlnk, that select different things. How would you arbitrate? Well, also as stated in the bug :), always follow the /etc/inittab first. If if it makes sense, perhaps systemd should change the default.target to match. Maybe we should check AUTOEXEC.BAT first, too? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: On Tue, 24.08.10 15:55, Matthew Miller (mat...@mattdm.org) wrote: This is a very big change. chkconfig has worked for a long, long time. Its elegance and simplicity is one of the nice administrative features of Red Hat based distributes. People like it. Yes, and they should continue to use it -- for sysv scripts. I thought the last big discussion resulted in agreement that chkconfig and service should continue to work for all services. Is that not the case? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 14:15, Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 24.08.10 16:14, Matthew Miller (mat...@mattdm.org) wrote: On Tue, Aug 24, 2010 at 01:20:21PM -0400, Bill Nottingham wrote: As stated in the bug, this would lead to a situation where you could have both a initdefault line, and a default.target symlnk, that select different things. How would you arbitrate? Well, also as stated in the bug :), always follow the /etc/inittab first. If if it makes sense, perhaps systemd should change the default.target to match. Maybe we should check AUTOEXEC.BAT first, too? Lennart this is neither helpful or 'excellent'. Please tone it down or take a break from posting for a bit. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:15:43PM +0200, Lennart Poettering wrote: Well, also as stated in the bug :), always follow the /etc/inittab first. If if it makes sense, perhaps systemd should change the default.target to match. Maybe we should check AUTOEXEC.BAT first, too? Cute. The answer is: if AUTOEXEC.BAT had been historically checked as part of our boot process, then yes, by all means. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 15:16 -0500, Chris Adams wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: On Tue, 24.08.10 15:55, Matthew Miller (mat...@mattdm.org) wrote: This is a very big change. chkconfig has worked for a long, long time. Its elegance and simplicity is one of the nice administrative features of Red Hat based distributes. People like it. Yes, and they should continue to use it -- for sysv scripts. I thought the last big discussion resulted in agreement that chkconfig and service should continue to work for all services. Is that not the case? It should be. Yea it's wonderful that Open Source lets stuff get re-invented, but RHL, Fedora, RHEL, etc. has been synonymous with chkconfig for about a billion years now and you can't just throw that away without bothering a few people. You can throw it away, but you shouldn't do that in F-14, even if it means compatibility code, like the kind Microsoft probably hated writing as they killed off AUTOEXEC.BAT :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 10:23 -0700, Adam Williamson wrote: On Tue, 2010-08-24 at 12:14 -0500, Mike McGrath wrote: The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? Hmm, I'd say 'not really, no' (unless we decide to fall back to upstart) I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:29 PM, Matt McCutchen m...@mattmccutchen.net wrote: On Tue, 2010-08-24 at 10:23 -0700, Adam Williamson wrote: On Tue, 2010-08-24 at 12:14 -0500, Mike McGrath wrote: The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? Hmm, I'd say 'not really, no' (unless we decide to fall back to upstart) I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. Well that wouldn't be a systemd issue but a flaw in our feature process. We have Feature foo with rollback plan to go back to bar. We decide to revert foo due to bug X, Y and Z and we and up with foo after beta ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Lennart Poettering (mzerq...@0pointer.de) said: - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. This is bad. While we support this just fine I think it is a really bad idea to reexec init at shutdown. What's the point of this, can you elaborate on this? This smells to me as a workaround for brokeness in older init systems, and I don't see a reason why reexecing itself would be necessary for systemd. If the libraries or binaries used by systemd are replaced during runtime, and it is not re-executed on shutdown, the filesystem will have busy inodes on shutdown. (If you'd like to take the filesystem semantics up with the kernel, feel free to tilt at that windmill.) Also, let's not forget that this requirement didn't exist for Upstart. Upstart always has been and still is unable to reexec itself. upstart doens't support re-execution while maintaining internal state. It *does* support minimal re-execution for this usage. - (optional) Booting with secondary serial consoles does the same. Hmm, could you elaborate on this? We have discussed this a couple of times upstream, and came to the conclusion that the only safe thing to do is to run a getty only on the main kernel console, i.e. where input is accepted from. That's why it's optional... given that we don't do this now, it can be dropped. (You'd be amazed at the number of bug reports we've gotten from people who *think* we do this now, and are confused when it doesn't happen.) PACKAGING - Guidelines for packaging systemd units shall be formalized. As pointed out elsewhere, I'd avoid this for F14. Then we should put don't in the guidelines, instead. We need to set clear expectations for package maintainers as to what they should be doing. (And certainly not switching the state of their packages mid-release.) SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. Hmpff. I don't think this is a good idea. chkconfig should manage SysV scripts, and systemctl enable should manage systemd units. But interpolating this would create the impression the semantics were identical, although they really aren't. What would make sense to add to chkconfig is something that checks whether a systemd unit is installed and then prints Hey, you have a systemd unit installed, chkconfig won't do what you think it will do for this unit or so. This isn't good enough, IMO. chkconfig is a utility used by admins, scripts, and packages in an automated fashion. Breaking their scripts is something that should not be taken lightly. Making every script or utility that an admin has have to have code for checking with chkconfig, and checking with systemd, all in the same release, is pretty rude. ORDERING - rc.local will run as the final service on bootup. - gettys will not start until after rc.local. - prefdm will start coincident to gettys (earlier?) Well, first of all, the first two items here obviously contradict. But putting that aside: I don't think speaking of ordering here these days really makes sense. Neither was it traditionally run as last thing of bootup (i.e. it was only synchronized against sysv scripts, not against upstart, inittab, dbus, cron, inetd services) Correct, it was synchronized against SysV scripts. And, IMO, it should stay that way. Principle of least surprise. If you want that reworded as 'the final SysV service', that's not an issue. really. But I am not even too convinced about the prefdm/getty ordering, as this creates an unnecessary synchronization point for everybody, even though rc.local is empty (which it probably is for 99.9% of all people). So, if the admin happens to add something to rc.local that needs synchronization, instead of it working as it has been, he has to rejigger the unit configuration? Ick. We want prefdm to start as early as possible. That is a separate discussion that should be had once we have the basic functionality verified and working, IMO. If we want to reorganize around early login, we should do that as a coordinated effort in F-15, not as an ad-hoc side-effect of the systemd configuration. -- iSCSI / -- LDAP user information -- IPA/AD user information -- NIS user information Can't test any of this really. Wouldn't even know how to test this. I also don't want to be responsible for the fact taht nss-ldap is borked. OK, so now you've stated 5 times in this mail some equivalent of 'that's not my package, it shouldn't be my problem, I don't want to be responsible for this.' I'm going to be blunt. I DON'T CARE. It's about the integration into the system. Playing a blame game doesn't help... if the system doesn't work, we can't ship that way. If there are enough blockers in other packages that prevent a systemd system from functioning to these sorts of
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:05:57PM +0200, Lennart Poettering wrote: From a practical point of view, I think what's actually important is: -- if you're in single user mode → it says 'S' It actually returns 1 in this case. What do you mean by actually? If you try it, you will see that both Fedora 13 and RHEL 5 return 'S'. I would like to see tab-completion for systemctl working before the final release. That's a request, though, not a demand. Happy to take patches! I can work on this. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 22:32 +0200, drago01 wrote: [...] In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. Well that wouldn't be a systemd issue but a flaw in our feature process. We have Feature foo with rollback plan to go back to bar. We decide to revert foo due to bug X, Y and Z and we and up with foo after beta ... It is a potential problem with all features, but more so for replacing the init system because the stakes are higher and the amount of testing required is greater. The contingency plans on most of the feature pages seem to state only what the rolled-back configuration is, not how it will be tested. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 09:33:50PM +0200, Lennart Poettering wrote: This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. While I think this is a good idea I am concernced a bit that this makes me responsible for stuff I am not willing to take responsibility of. i.e. if something from this list is broken, but it isn't systemd's fault then this should not be a reason to drop systemd from F14. Also, some of this I am not really able or willing to test (iscsi...), so I don't want to be responsible to fix this. This isn't personal. It's a list of requirements that indicate where we need to be in order to ship systemd as the default in Fedora 14. It doesn't matter whose fault it is -- if it doesn't work, we can't ship it broken. If it's possible to fix some now-exposed underlying issue by backing out of systemd, and release engineering / FESCO deterimines that that's the best fix, it doesn't mean systemd is a failure. It means that Fedora wasn't ready for it yet. Obviously if the item in question fails both with systemd and upstart, it's a different sort of blocker. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/24/10 1:46 PM, Matt McCutchen wrote: On Tue, 2010-08-24 at 22:32 +0200, drago01 wrote: [...] In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. Well that wouldn't be a systemd issue but a flaw in our feature process. We have Feature foo with rollback plan to go back to bar. We decide to revert foo due to bug X, Y and Z and we and up with foo after beta ... It is a potential problem with all features, but more so for replacing the init system because the stakes are higher and the amount of testing required is greater. The contingency plans on most of the feature pages seem to state only what the rolled-back configuration is, not how it will be tested. Sounds like good feedback for the feature wrangler and for FESCo as far as what they might require in contingency plan sections. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx0NaQACgkQ4v2HLvE71NU4hwCeLgkcqmTO1WOwPz35eLe+2tH2 WcEAoMQ4UoZw/rUAJERvuXCiko57vUzZ =V2ZI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 16:38, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. This is bad. While we support this just fine I think it is a really bad idea to reexec init at shutdown. What's the point of this, can you elaborate on this? This smells to me as a workaround for brokeness in older init systems, and I don't see a reason why reexecing itself would be necessary for systemd. If the libraries or binaries used by systemd are replaced during runtime, and it is not re-executed on shutdown, the filesystem will have busy inodes on shutdown. (If you'd like to take the filesystem semantics up with the kernel, feel free to tilt at that windmill.) Hmm, so this is about files that are deleted but still mapped by init, and which can only be deleted when init stops referencing them, but that is required to remount the fs r/o? Did I get this right? I am not really convinced that reexecing is the right answer for this problem. But well, since this already works anyway I guess this doesn't really matter too much. That's why it's optional... given that we don't do this now, it can be dropped. (You'd be amazed at the number of bug reports we've gotten from people who *think* we do this now, and are confused when it doesn't happen.) I think we'd be ill advised to support this ever. We should take input only from whatever /dev/console refers to (and input on /dev/console only comes from the main console). Everything else I think is dangerous. PACKAGING - Guidelines for packaging systemd units shall be formalized. As pointed out elsewhere, I'd avoid this for F14. Then we should put don't in the guidelines, instead. We need to set clear expectations for package maintainers as to what they should be doing. (And certainly not switching the state of their packages mid-release.) Well, if we can agree on don't, unless you contacted Lennart or [add list here] and he said it's OK then I am fine with this. ORDERING - rc.local will run as the final service on bootup. - gettys will not start until after rc.local. - prefdm will start coincident to gettys (earlier?) Well, first of all, the first two items here obviously contradict. But putting that aside: I don't think speaking of ordering here these days really makes sense. Neither was it traditionally run as last thing of bootup (i.e. it was only synchronized against sysv scripts, not against upstart, inittab, dbus, cron, inetd services) Correct, it was synchronized against SysV scripts. And, IMO, it should stay that way. Principle of least surprise. If you want that reworded as 'the final SysV service', that's not an issue. Well, if we can agree on after all sysv services that include no proper ordering dependency information in the LSB headers, then I'd be fine with this. If sysv services contain LSB headers, we should follow the ordering it encodes, not come with implicit additional rules. OK, so now you've stated 5 times in this mail some equivalent of 'that's not my package, it shouldn't be my problem, I don't want to be responsible for this.' I'm going to be blunt. I DON'T CARE. Yay, thanks that you don't care. You are aware that by putting everything on a single man's shoulders and then telling him you don't care you make him feel really welcome and make him wonder why he even bothers with this shit? Sure, I suppose individual maintainers want to push their code over the wall and then sit in their silo and claim 'that's not my problem' and 'someone else needs to fix that', well, that's their right to be lame. But we, as Fedora, as producers of a product that we ship to our users, don't have that luxury. But you enable them to block out change. For example, if somebody refuses to merge a patch that adds a systemd equivalent for an upstart config hook he has, he can sink the whole systemd in fedora project. I am pretty sure some folks would be really happy to have that power... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 16:54, Matthew Miller (mat...@mattdm.org) wrote: While I think this is a good idea I am concernced a bit that this makes me responsible for stuff I am not willing to take responsibility of. i.e. if something from this list is broken, but it isn't systemd's fault then this should not be a reason to drop systemd from F14. Also, some of this I am not really able or willing to test (iscsi...), so I don't want to be responsible to fix this. This isn't personal. It's a list of requirements that indicate where we need to be in order to ship systemd as the default in Fedora 14. It doesn't matter whose fault it is -- if it doesn't work, we can't ship it broken. Great, I geuss I'll become an X hacker then. Apparently if KMS is borked it's now my duty to fix it. Yay! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 11:32:32PM +0200, Lennart Poettering wrote: This isn't personal. It's a list of requirements that indicate where we need to be in order to ship systemd as the default in Fedora 14. It doesn't matter whose fault it is -- if it doesn't work, we can't ship it broken. Great, I geuss I'll become an X hacker then. Apparently if KMS is borked it's now my duty to fix it. Yay! I just said it wasn't. But let me also repeat my the next paragraph, which you left out: Obviously if the item in question fails both with systemd and upstart, it's a different sort of blocker. -- Matthew Miller mat...@mattdm.org 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24.08.10 20:14, Matt McCutchen (m...@mattmccutchen.net) wrote: On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote: On Tue, 24.08.10 16:38, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. This is bad. While we support this just fine I think it is a really bad idea to reexec init at shutdown. What's the point of this, can you elaborate on this? This smells to me as a workaround for brokeness in older init systems, and I don't see a reason why reexecing itself would be necessary for systemd. If the libraries or binaries used by systemd are replaced during runtime, and it is not re-executed on shutdown, the filesystem will have busy inodes on shutdown. (If you'd like to take the filesystem semantics up with the kernel, feel free to tilt at that windmill.) Hmm, so this is about files that are deleted but still mapped by init, and which can only be deleted when init stops referencing them, but that is required to remount the fs r/o? Did I get this right? Yes, that's right. I am not really convinced that reexecing is the right answer for this problem. But well, since this already works anyway I guess this doesn't really matter too much. Indeed, it's a hack, but there's no better option in sight, so I don't see the point in complaining. Well, what me still puzzles is this: the reexec is done asynchronously, via signals. Shouldn't this be done synchronously at least to make sure the daemon really is reexec'ed when we try to remount r/o? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Lennart Poettering píše v St 25. 08. 2010 v 02:52 +0200: On Tue, 24.08.10 20:14, Matt McCutchen (m...@mattmccutchen.net) wrote: On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote: On Tue, 24.08.10 16:38, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. This is bad. While we support this just fine I think it is a really bad idea to reexec init at shutdown. What's the point of this, can you elaborate on this? This smells to me as a workaround for brokeness in older init systems, and I don't see a reason why reexecing itself would be necessary for systemd. If the libraries or binaries used by systemd are replaced during runtime, and it is not re-executed on shutdown, the filesystem will have busy inodes on shutdown. (If you'd like to take the filesystem semantics up with the kernel, feel free to tilt at that windmill.) snip Well, what me still puzzles is this: the reexec is done asynchronously, via signals. Shouldn't this be done synchronously at least to make sure the daemon really is reexec'ed when we try to remount r/o? The traditional solution is to reexec not on shutdown, but immediately after init upgrade (which also frees the inodes early); this can still race with shutdown in theory, but is probably good enough in practice. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2010 03:39 PM, Lennart Poettering wrote: On Tue, 24.08.10 09:44, Daniel J Walsh (dwa...@redhat.com) wrote: I would add security things. Starting a service sends audit messages from the proper loginuid. I am sure Steve Grub has lots of concerns here also. This is not fair! Upstart never did this. We do this now in systemd, as the first init system on Linux at all. I agree, but no apps (very few) ever changed to upstart activation. I would not put this as a stop ship but I think it should be tested. Acknowledge this as a new feature. Don't make this a release requirement. Restarting or starting a service ends up transitioning to the proper domain (Might be an SELinux domain.) directories, sock_files created by systemd end up with the proper context and confined domains see the remote socket as the proper label not, init_t. For example if I setup mysql to be autostarted by systemd then when apache connects to the /var/run/mysql/socket it sees this socket labeled mysqld_var_run_t and the remote end as mysqld_t. With the latest patches we merged this should in theory all be fixed, right? Or is there anything still left to do in this area? Lennart Yes I am just suggesting that both should be tested. As far as I am concerned they should work now. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkx0gPMACgkQrlYvE4MpobOzQgCg34tuQ9YTlfbZwOJRz05EZyfA 4qkAnRUkQHkcsuGYkWXihToMzIlOWhQJ =Ks1i -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 16:29 -0400, Matt McCutchen wrote: On Tue, 2010-08-24 at 10:23 -0700, Adam Williamson wrote: On Tue, 2010-08-24 at 12:14 -0500, Mike McGrath wrote: The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? Hmm, I'd say 'not really, no' (unless we decide to fall back to upstart) I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. well, feel free. It's still installable. It's unchanged from the last five releases, though, and we didn't have any particular problems with the init system in any of those, so I'm not waking up at nights worrying about it breaking. -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 21:44 -0700, Adam Williamson wrote: I think that's precisely the concern. In the event that F14 goes back to upstart, the final release will use a configuration that may not have received much testing. If we want to claim that it's safe to switch back to upstart after beta, we need to be testing that configuration now, along with the systemd configuration. well, feel free. It's still installable. It's unchanged from the last five releases, though, and we didn't have any particular problems with the init system in any of those, so I'm not waking up at nights worrying about it breaking. for clarity - no, there's nothing magic about five releases ago. Five was a Random Rhetorical Number. :) I don't know the last time we had a major init system change, whenever it was, I wasn't around. -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. Thanks Bill. This looks very helpful. I'll look it over tomorrow. -- Matthew Miller mat...@mattdm.org 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
