Bug 158613

Not my problem: Do NEVER start daemons during hardware initialization.
All stuff in /etc/init.d/boot.*. has to run only once at startup and
maybe if someone does a cold boot into single user mode.  Last case
is done by /etc/init.d/rc.

I'm not willingly to run all boot scripts after a warm single user
mode (warm == init 1). This would e.g. run fsck on rw mounted file
systems and unmounting all file systems is not an option.

Well the udev daemon _is_ the hardware initialization, so "NEVER" will not really work :) Next udev will skip "boot.udev stop".

Does not help, because /etc/init.d/single has to have terminate
or kill all processes.  After `init 1' the single user mode will
not have any process beside init its self.  And this is essential
for a single user mode.

So, what to do then?

Will: 
  # Default-Start:     B 2 3 5
instead of:
  # Default-Start:     B
do the trick?

Two solutions possible: first a script in all runlevels to check if
a udev is active and if not start it again ... or a two lines in
/etc/init.d/rc in the test case of a cold boot into single user
mode.  This would be the else tree for warm change into single user
mode with one line

       /etc/init.d/boot.d/S*boot.udev start

or something similar. Would be a change of aaa_base, there add
Rudi to CC.

Hmmm  ... the default start works only if you check in your boot
script if udev is already done.

Just noted that cold boot into single user mode and following
init 3/5 does not work for all cases.

-------------------------------------------------------------------
Thu Mar 16 18:50:27 CET 2006 - werner@suse.de

- Make cold boot into single user work even for `s'
- Restart udev after warm reached single user mode (bug #158613)

-------------------------------------------------------------------

Afaik there are some other daemons started in boot.d e.g. subdomein (AppArmor), which seems not to be started in ordinary runlevels.

*** Bug 157246 has been marked as a duplicate of this bug. ***

As I already stated: daemons should not be started
during boot time. This is for HW initialization only.

Afters system initialization is finished the runlevels
with their daemons and other services are started.

Please move boot.apparmor to apparmor and change the Default-Start to `2 3 5'
... beside the auditd service script should use also Default-Start `2 3 5'
because we've also a runlevel 2 not only 3 and 5.

Jesse can you look at this issue as steve is out? If we move to a standard runlevel managed startup can we ensure that apparmor starts early enough to confine the early services that we do now? From looking at /etc/rc.d/boot.d its looks like now we start before:

S07boot.clock
S07boot.klog
S07boot.loadmodules
S07boot.scpm
S07boot.udev_retry
S07boot.videobios
S08boot.crypto
S09boot.preload
S09boot.swap

Moving to a runlevel based startup would make us unable to confine these later services - from our current profile set I would guess this impacts klogd (which we ship a profile for).

I'd rather we split things back out like we used to and have the boot.apparmor init script load the module and security policy and have a secondary init script that starts up the event daemon if necessary.

Also just to clarify as this bug is a little confusing - an apparmor change won't effect udev startup. Do we need two separate bugs here? one for udev and one against apparmor for violating the property that boot services are all hardware related?

udev and apparmor are independant here. They just had the same problem, namely staring daemons in boot.d. The udev part is fixed.
Yes would have been better to have two bug reports, but it's the same problem.

Ok. So what remains is the changes to apparmor. Jesse what do you think about this? Can we change and test this week? 

And please do not forget to set Default-Start to `2 3 5' for
/etc/init.d/apparmor _and_ /etc/init.d/auditd

I don't think that there is the bandwidth here to correct and test this fix before  the GM candidate without stopping other critical work. What is the impact for not correcting this for 10.1? If the udev issue is fixed what is the impact of not moving to a standard service for apparmor?

The problem is that you may lose apparmor protection when switching to runlevel 1 and back (e.g. for maintenance). And maybe you don't even notice it. So this is kind of securiry problem. But IMHO it is not critical.

Changes have been made for beta9 to split out part of this service to its own init script (starting the aa-eventd daemon).

This process should remain as a boot script and will only load policy (there is no userspace daemon running after this script is completed).

This allows the policy to load as early as possible in the boot process (apparmor policy being allowed to load early means we can confine programs that start in the boot process)