-----BEGIN PGP SIGNED MESSAGE-----
On 08/24/2010 08:45 AM, Matthias Clasen wrote:
On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote:
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.
> - System boots successfully to GUI, when configured.
> - System boots successfully to text mode, when configured.
> - System properly handles being passed [1-5], 'single', '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 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
> RUNTIME TOOLS
> - telinit  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,
> the audit layer.
> - 'shutdown' shall support the following arguments in a compatible manner:
> 'r', 'h', 'H', 'P', 'c', 'k',
> - 'telinit' does not error when passed '[Qq]' (to reload its
> 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 starts a configured display manager correctly.
> - prefdm starts a installed display manager correctly without additional
> - 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
> - (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.
> - 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.
> - 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'
> 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
> SERVICE HANDLING
> - Running 'chkconfig <foo> <(null)|on|off>' on a service managed
> will return the correct code/perform an appropriate action.
> - Running 'service <foo> <start|stop|...>' on a service managed
> will perform the appropriate action (via systemctl), and return
> similar errors.
> - Running '/etc/init.d/<foo> <start|stop|...>' will not break the
> 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 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
> -- The services shall function the same.
This is again not really much of a systemd requirement. At most, we
should probably test that socket activation does not affect the
functionality of services (ie that socket activation works as promised).
Of course, this is only an issue if we actually have any
socket-activated services in F14.
> -- The same set of devices and filesystems shall be mounted.
> -- The same set of devices and filesystems shall be fscked.
'Same', compared to what ? I think this needs to be expanded to specify
under what conditions filesystems were mounted/fscked in F13.
> - rc.local will run as the final service on bootup.
> - gettys will not start until after rc.local.
These two seem contradictory, at first sight...
> - prefdm will start coincident to gettys (earlier?)
> ADMIN INTERFACE
> - The files and paths used by systemd shall be frozen for future releases.
> - 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.
> ASSORTED RANDOM CONFIGURATIONS
> - The system shall properly function with:
> -- encrypted /
> -- encrypted non-/
> -- nfs /
> -- iSCSI /
> -- LDAP user information
> -- IPA/AD user information
> -- NIS user information
> -- ext* filesystems
> -- btrfs filesystems
> -- xfs filesystems
> ANY REMAINING UPSTART JOBS
> - All packaged upstart jobs are modified to have some SysV or systemd-native
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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----