1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <rss version='
2.0' xmlns:lj='http://www.livejournal.org/rss/lj/
1.0/'
>
4 <title>Petter Reinholdtsen - Entries tagged bootsystem
</title>
5 <description>Entries tagged bootsystem
</description>
6 <link>http://people.skolelinux.org/pere/blog/
</link>
10 <title>Debian init.d boot script example for rsyslog
</title>
11 <link>http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
</link>
12 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
</guid>
13 <pubDate>Sat,
2 Nov
2013 22:
40:
00 +
0100</pubDate>
14 <description><p
>If one of the points of switching to a new init system in Debian is
15 <a href=
"http://thomas.goirand.fr/blog/?p=
147">to get rid of huge
16 init.d scripts
</a
>, I doubt we need to switch away from sysvinit and
17 init.d scripts at all. Here is an example init.d script, ie a rewrite
18 of /etc/init.d/rsyslog:
</p
>
21 #!/lib/init/init-d-script
24 # Required-Start: $remote_fs $time
25 # Required-Stop: umountnfs $time
26 # X-Stop-After: sendsigs
27 # Default-Start:
2 3 4 5
29 # Short-Description: enhanced syslogd
30 # Description: Rsyslog is an enhanced multi-threaded syslogd.
31 # It is quite compatible to stock sysklogd and can be
32 # used as a drop-in replacement.
34 DESC=
"enhanced syslogd
"
35 DAEMON=/usr/sbin/rsyslogd
36 </pre
></p
>
38 <p
>Pretty minimalistic to me... For the record, the original sysv-rc
39 script was
137 lines, and the above is just
15 lines, most of the meta
40 info/comments.
</p
>
42 <p
>How to do this, you ask? Well, one create a new script
43 /lib/init/init-d-script looking something like this:
48 # Define LSB log_* functions.
49 # Depend on lsb-base (
>=
3.2-
14) to ensure that this file is present
50 # and status_of_proc is working.
51 . /lib/lsb/init-functions
54 # Function that starts the daemon/service
60 #
0 if daemon has been started
61 #
1 if daemon was already running
62 #
2 if daemon could not be started
63 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test
> /dev/null \
65 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
68 # Add code here, if necessary, that waits for the process to be ready
69 # to handle requests from services started subsequently which depend
70 # on this one. As a last resort, sleep for some time.
74 # Function that stops the daemon/service
79 #
0 if daemon has been stopped
80 #
1 if daemon was already stopped
81 #
2 if daemon could not be stopped
82 # other if a failure occurred
83 start-stop-daemon --stop --quiet --retry=TERM/
30/KILL/
5 --pidfile $PIDFILE --name $NAME
85 [
"$RETVAL
" =
2 ]
&& return
2
86 # Wait for children to finish too if this is a daemon that forks
87 # and if the daemon is only ever run from this initscript.
88 # If the above conditions are not satisfied then add some other code
89 # that waits for the process to drop all resources that could be
90 # needed by services started subsequently. A last resort is to
91 # sleep for some time.
92 start-stop-daemon --stop --quiet --oknodo --retry=
0/
30/KILL/
5 --exec $DAEMON
93 [
"$?
" =
2 ]
&& return
2
94 # Many daemons don
't delete their pidfiles when they exit.
96 return
"$RETVAL
"
100 # Function that sends a SIGHUP to the daemon/service
104 # If the daemon can reload its configuration without
105 # restarting (for example, when it is sent a SIGHUP),
106 # then implement that here.
108 start-stop-daemon --stop --signal
1 --quiet --pidfile $PIDFILE --name $NAME
113 scriptbasename=
"$(basename $
1)
"
114 echo
"SN: $scriptbasename
"
115 if [
"$scriptbasename
" !=
"init-d-library
" ] ; then
116 script=
"$
1"
123 NAME=$(basename $DAEMON)
124 PIDFILE=/var/run/$NAME.pid
126 # Exit if the package is not installed
127 #[ -x
"$DAEMON
" ] || exit
0
129 # Read configuration variable file if it is present
130 [ -r /etc/default/$NAME ]
&& . /etc/default/$NAME
132 # Load the VERBOSE setting and other rcS variables
135 case
"$
1" in
137 [
"$VERBOSE
" != no ]
&& log_daemon_msg
"Starting $DESC
" "$NAME
"
139 case
"$?
" in
140 0|
1) [
"$VERBOSE
" != no ]
&& log_end_msg
0 ;;
141 2) [
"$VERBOSE
" != no ]
&& log_end_msg
1 ;;
145 [
"$VERBOSE
" != no ]
&& log_daemon_msg
"Stopping $DESC
" "$NAME
"
147 case
"$?
" in
148 0|
1) [
"$VERBOSE
" != no ]
&& log_end_msg
0 ;;
149 2) [
"$VERBOSE
" != no ]
&& log_end_msg
1 ;;
153 status_of_proc
"$DAEMON
" "$NAME
" && exit
0 || exit $?
155 #reload|force-reload)
157 # If do_reload() is not implemented then leave this commented out
158 # and leave
'force-reload
' as an alias for
'restart
'.
160 #log_daemon_msg
"Reloading $DESC
" "$NAME
"
164 restart|force-reload)
166 # If the
"reload
" option is implemented then remove the
167 #
'force-reload
' alias
169 log_daemon_msg
"Restarting $DESC
" "$NAME
"
171 case
"$?
" in
174 case
"$?
" in
176 1) log_end_msg
1 ;; # Old process is still running
177 *) log_end_msg
1 ;; # Failed to start
187 echo
"Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}
" >&2
193 </pre
></p
>
195 <p
>It is based on /etc/init.d/skeleton, and could be improved quite a
196 lot. I did not really polish the approach, so it might not always
197 work out of the box, but you get the idea. I did not try very hard to
198 optimize it nor make it more robust either.
</p
>
200 <p
>A better argument for switching init system in Debian than reducing
201 the size of init scripts (which is a good thing to do anyway), is to
202 get boot system that is able to handle the kernel events sensibly and
203 robustly, and do not depend on the boot to run sequentially. The boot
204 and the kernel have not behaved sequentially in year.
</p
>
209 <title>How is booting into runlevel
1 different from single user boots?
</title>
210 <link>http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html
</link>
211 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html
</guid>
212 <pubDate>Thu,
4 Aug
2011 12:
40:
00 +
0200</pubDate>
213 <description><p
>Wouter Verhelst have some
214 <a href=
"http://grep.be/blog/en/retorts/pere_kubuntu_boot
">interesting
215 comments and opinions
</a
> on my blog post on
216 <a href=
"http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html
">the
217 need to clean up /etc/rcS.d/ in Debian
</a
> and my blog post about
218 <a href=
"http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html
">the
219 default KDE desktop in Debian
</a
>. I only have time to address one
220 small piece of his comment now, and though it best to address the
221 misunderstanding he bring forward:
</p
>
223 <p
><blockquote
>
224 Currently, a system admin has four options: [...] boot to a
225 single-user system (by adding
'single
' to the kernel command line;
226 this runs rcS and rc1 scripts)
227 </blockquote
></p
>
229 <p
>This make me believe Wouter believe booting into single user mode
230 and booting into runlevel
1 is the same. I am not surprised he
231 believe this, because it would make sense and is a quite sensible
232 thing to believe. But because the boot in Debian is slightly broken,
233 runlevel
1 do not work properly and it isn
't the same as single user
234 mode. I
'll try to explain what is actually happing, but it is a bit
235 hard to explain.
</p
>
237 <p
>Single user mode is defined like this in /etc/inittab:
238 "<tt
>~~:S:wait:/sbin/sulogin
</tt
>". This means the only thing that is
239 executed in single user mode is sulogin. Single user mode is a boot
240 state
"between
" the runlevels, and when booting into single user mode,
241 only the scripts in /etc/rcS.d/ are executed before the init process
242 enters the single user state. When switching to runlevel
1, the state
243 is in fact not ending in runlevel
1, but it passes through runlevel
1
244 and end up in the single user mode (see /etc/rc1.d/S03single, which
245 runs
"init -t1 S
" to switch to single user mode at the end of runlevel
246 1. It is confusing that the
'S
' (single user) init mode is not the
247 mode enabled by /etc/rcS.d/ (which is more like the initial boot
250 <p
>This summary might make it clearer. When booting for the first
251 time into single user mode, the following commands are executed:
252 "<tt
>/etc/init.d/rc S; /sbin/sulogin
</tt
>". When booting into
253 runlevel
1, the following commands are executed:
"<tt
>/etc/init.d/rc
254 S; /etc/init.d/rc
1; /sbin/sulogin
</tt
>". A problem show up when
255 trying to continue after visiting single user mode. Not all services
256 are started again as they should, causing the machine to end up in an
257 unpredicatble state. This is why Debian admins recommend rebooting
258 after visiting single user mode.
</p
>
260 <p
>A similar problem with runlevel
1 is caused by the amount of
261 scripts executed from /etc/rcS.d/. When switching from say runlevel
2
262 to runlevel
1, the services started from /etc/rcS.d/ are not properly
263 stopped when passing through the scripts in /etc/rc1.d/, and not
264 started again when switching away from runlevel
1 to the runlevels
265 2-
5. I believe the problem is best fixed by moving all the scripts
266 out of /etc/rcS.d/ that are not
<strong
>required
</strong
> to get a
267 functioning single user mode during boot.
</p
>
269 <p
>I have spent several years investigating the Debian boot system,
270 and discovered this problem a few years ago. I suspect it originates
271 from when sysvinit was introduced into Debian, a long time ago.
</p
>
276 <title>What should start from /etc/rcS.d/ in Debian? - almost nothing
</title>
277 <link>http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html
</link>
278 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html
</guid>
279 <pubDate>Sat,
30 Jul
2011 14:
00:
00 +
0200</pubDate>
280 <description><p
>In the Debian boot system, several packages include scripts that
281 are started from /etc/rcS.d/. In fact, there is a bite more of them
282 than make sense, and this causes a few problems. What kind of
283 problems, you might ask. There are at least two problems. The first
284 is that it is not possible to recover a machine after switching to
285 runlevel
1. One need to actually reboot to get the machine back to
286 the expected state. The other is that single user boot will sometimes
287 run into problems because some of the subsystems are activated before
288 the root login is presented, causing problems when trying to recover a
289 machine from a problem in that subsystem. A minor additional point is
290 that moving more scripts out of rcS.d/ and into the other rc#.d/
291 directories will increase the amount of scripts that can run in
292 parallel during boot, and thus decrease the boot time.
</p
>
294 <p
>So, which scripts should start from rcS.d/. In short, only the
295 scripts that _have_ to execute before the root login prompt is
296 presented during a single user boot should go there. Everything else
297 should go into the numeric runlevels. This means things like
298 lm-sensors, fuse and x11-common should not run from rcS.d, but from
299 the numeric runlevels. Today in Debian, there are around
115 init.d
300 scripts that are started from rcS.d/, and most of them should be moved
301 out. Do your package have one of them? Please help us make single
302 user and runlevel
1 better by moving it.
</p
>
304 <p
>Scripts setting up the screen, keyboard, system partitions
305 etc. should still be started from rcS.d/, but there is for example no
306 need to have the network enabled before the single user login prompt
307 is presented.
</p
>
309 <p
>As always, things are not so easy to fix as they sound. To keep
310 Debian systems working while scripts migrate and during upgrades, the
311 scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency
312 order, ie the scripts that nothing in rcS.d/ depend on can be moved,
313 and the next ones can only be moved when their dependencies have been
314 moved first. This migration must be done sequentially while we ensure
315 that the package system upgrade packages in the right order to keep
316 the system state correct. This will require some coordination when it
317 comes to network related packages, but most of the packages with
318 scripts that should migrate do not have anything in rcS.d/ depending
319 on them. Some packages have already been updated, like the sudo
320 package, while others are still left to do. I wish I had time to work
321 on this myself, but real live constrains make it unlikely that I will
322 find time to push this forward.
</p
>
327 <title>Automatic upgrade testing from Lenny to Squeeze
</title>
328 <link>http://people.skolelinux.org/pere/blog/Automatic_upgrade_testing_from_Lenny_to_Squeeze.html
</link>
329 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Automatic_upgrade_testing_from_Lenny_to_Squeeze.html
</guid>
330 <pubDate>Fri,
11 Jun
2010 22:
50:
00 +
0200</pubDate>
331 <description><p
>The last few days I have done some upgrade testing in Debian, to
332 see if the upgrade from Lenny to Squeeze will go smoothly. A few bugs
333 have been discovered and reported in the process
334 (
<a href=
"http://bugs.debian.org/
585410">#
585410</a
> in nagios3-cgi,
335 <a href=
"http://bugs.debian.org/
584879">#
584879</a
> already fixed in
336 enscript and
<a href=
"http://bugs.debian.org/
584861">#
584861</a
> in
337 kdebase-workspace-data), and to get a more regular testing going on, I
338 am working on a script to automate the test.
</p
>
340 <p
>The idea is to create a Lenny chroot and use tasksel to install a
341 Gnome or KDE desktop installation inside the chroot before upgrading
342 it. To ensure no services are started in the chroot, a policy-rc.d
343 script is inserted. To make sure tasksel believe it is to install a
344 desktop on a laptop, the tasksel tests are replaced in the chroot
345 (only acceptable because this is a throw-away chroot).
</p
>
347 <p
>A naive upgrade from Lenny to Squeeze using aptitude dist-upgrade
348 currently always fail because udev refuses to upgrade with the kernel
349 in Lenny, so to avoid that problem the file /etc/udev/kernel-upgrade
350 is created. The bug report
351 <a href=
"http://bugs.debian.org/
566000">#
566000</a
> make me suspect
352 this problem do not trigger in a chroot, but I touch the file anyway
353 to make sure the upgrade go well. Testing on virtual and real
354 hardware have failed me because of udev so far, and creating this file
355 do the trick in such settings anyway. This is a
356 <a href=
"http://www.linuxquestions.org/questions/debian-
26/failed-dist-upgrade-due-to-udev-config_sysfs_deprecated-nonsense-
804130/
">known
357 issue
</a
> and the current udev behaviour is intended by the udev
358 maintainer because he lack the resources to rewrite udev to keep
359 working with old kernels or something like that. I really wish the
360 udev upstream would keep udev backwards compatible, to avoid such
361 upgrade problem, but given that they fail to do so, I guess
362 documenting the way out of this mess is the best option we got for
363 Debian Squeeze.
</p
>
365 <p
>Anyway, back to the task at hand, testing upgrades. This test
366 script, which I call
<tt
>upgrade-test
</tt
> for now, is doing the
369 <blockquote
><pre
>
373 if [
"$
1" ] ; then
382 exec
&lt; /dev/null
384 mirror=http://ftp.skolelinux.org/debian
385 tmpdir=chroot-$from-upgrade-$to-$desktop
387 debootstrap $from $tmpdir $mirror
388 chroot $tmpdir aptitude update
389 cat
> $tmpdir/usr/sbin/policy-rc.d
&lt;
&lt;EOF
393 chmod a+rx $tmpdir/usr/sbin/policy-rc.d
397 mount -t proc proc $tmpdir/proc
398 # Make sure proc is unmounted also on failure
399 trap exit_cleanup EXIT INT
401 chroot $tmpdir aptitude -y install debconf-utils
403 # Make sure tasksel autoselection trigger. It need the test scripts
404 # to return the correct answers.
405 echo tasksel tasksel/desktop multiselect $desktop | \
406 chroot $tmpdir debconf-set-selections
408 # Include the desktop and laptop task
409 for test in desktop laptop ; do
410 echo
> $tmpdir/usr/lib/tasksel/tests/$test
&lt;
&lt;EOF
414 chmod a+rx $tmpdir/usr/lib/tasksel/tests/$test
417 DEBIAN_FRONTEND=noninteractive
418 DEBIAN_PRIORITY=critical
419 export DEBIAN_FRONTEND DEBIAN_PRIORITY
420 chroot $tmpdir tasksel --new-install
422 echo deb $mirror $to main
> $tmpdir/etc/apt/sources.list
423 chroot $tmpdir aptitude update
424 touch $tmpdir/etc/udev/kernel-upgrade
425 chroot $tmpdir aptitude -y dist-upgrade
427 </pre
></blockquote
>
429 <p
>I suspect it would be useful to test upgrades with both apt-get and
430 with aptitude, but I have not had time to look at how they behave
431 differently so far. I hope to get a cron job running to do the test
432 regularly and post the result on the web. The Gnome upgrade currently
433 work, while the KDE upgrade fail because of the bug in
434 kdebase-workspace-data
</p
>
436 <p
>I am not quite sure what kind of extract from the huge upgrade logs
437 (KDE
167 KiB, Gnome
516 KiB) it make sense to include in this blog
438 post, so I will refrain from trying. I can report that for Gnome,
439 aptitude report
760 packages upgraded,
448 newly installed,
129 to
440 remove and
1 not upgraded and
1024MB need to be downloaded while for
441 KDE the same numbers are
702 packages upgraded,
507 newly installed,
442 193 to remove and
0 not upgraded and
1117MB need to be downloaded
</p
>
444 <p
>I am very happy to notice that the Gnome desktop + laptop upgrade
445 is able to migrate to dependency based boot sequencing and parallel
446 booting without a hitch. Was unsure if there were still bugs with
447 packages failing to clean up their obsolete init.d script during
448 upgrades, and no such problem seem to affect the Gnome desktop+laptop
454 <title>Upstart or sysvinit - as init.d scripts see it
</title>
455 <link>http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html
</link>
456 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html
</guid>
457 <pubDate>Sun,
6 Jun
2010 23:
55:
00 +
0200</pubDate>
458 <description><p
>If Debian is to migrate to upstart on Linux, I expect some init.d
459 scripts to migrate (some of) their operations to upstart job while
460 keeping the init.d for hurd and kfreebsd. The packages with such
461 needs will need a way to get their init.d scripts to behave
462 differently when used with sysvinit and with upstart. Because of
463 this, I had a look at the environment variables set when a init.d
464 script is running under upstart, and when it is not.
</p
>
466 <p
>With upstart, I notice these environment variables are set when a
467 script is started from rcS.d/ (ignoring some irrelevant ones like
470 <blockquote
><pre
>
476 UPSTART_EVENTS=startup
478 UPSTART_JOB=rc-sysinit
479 </pre
></blockquote
>
481 <p
>With sysvinit, these environment variables are set for the same
484 <blockquote
><pre
>
485 INIT_VERSION=sysvinit-
2.88
490 </pre
></blockquote
>
492 <p
>The RUNLEVEL and PREVLEVEL environment variables passed on from
493 sysvinit are not set by upstart. Not sure if it is intentional or not
494 to not be compatible with sysvinit in this regard.
</p
>
496 <p
>For scripts needing to behave differently when upstart is used,
497 looking for the UPSTART_JOB environment variable seem to be a good
503 <title>KDM fail at boot with NVidia cards - and no one try to fix it?
</title>
504 <link>http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html
</link>
505 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html
</guid>
506 <pubDate>Tue,
1 Jun
2010 17:
05:
00 +
0200</pubDate>
507 <description><p
>It is strange to watch how a bug in Debian causing KDM to fail to
508 start at boot when an NVidia video card is used is handled. The
509 problem seem to be that the nvidia X.org driver uses a long time to
510 initialize, and this duration is longer than kdm is configured to
513 <p
>I came across two bugs related to this issue,
514 <a href=
"http://bugs.debian.org/
583312">#
583312</a
> initially filed
515 against initscripts and passed on to nvidia-glx when it became obvious
516 that the nvidia drivers were involved, and
517 <a href=
"http://bugs.debian.org/
524751">#
524751</a
> initially filed against
518 kdm and passed on to src:nvidia-graphics-drivers for unknown reasons.
</p
>
520 <p
>To me, it seem that no-one is interested in actually solving the
521 problem nvidia video card owners experience and make sure the Debian
522 distribution work out of the box for these users. The nvidia driver
523 maintainers expect kdm to be set up to wait longer, while kdm expect
524 the nvidia driver maintainers to fix the driver to start faster, and
525 while they wait for each other I guess the users end up switching to a
526 distribution that work for them. I have no idea what the solution is,
527 but I am pretty sure that waiting for each other is not it.
</p
>
529 <p
>I wonder why we end up handling bugs this way.
</p
>
534 <title>Parallellized boot seem to hold up well in Debian/testing
</title>
535 <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html
</link>
536 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html
</guid>
537 <pubDate>Thu,
27 May
2010 23:
55:
00 +
0200</pubDate>
538 <description><p
>A few days ago, parallel booting was enabled in Debian/testing.
539 The feature seem to hold up pretty well, but three fairly serious
540 issues are known and should be solved:
544 <li
>The wicd package seen to
545 <a href=
"http://bugs.debian.org/
508289">break NFS mounting
</a
> and
546 <a href=
"http://bugs.debian.org/
581586">network setup
</a
> when
547 parallel booting is enabled. No idea why, but the wicd maintainer
548 seem to be on the case.
</li
>
550 <li
>The nvidia X driver seem to
551 <a href=
"http://bugs.debian.org/
583312">have a race condition
</a
>
552 triggered more easily when parallel booting is in effect. The
553 maintainer is on the case.
</li
>
555 <li
>The sysv-rc package fail to properly enable dependency based boot
556 sequencing (the shutdown is broken) when old file-rc users
557 <a href=
"http://bugs.debian.org/
575080">try to switch back
</a
> to
558 sysv-rc. One way to solve it would be for file-rc to create
559 /etc/init.d/.legacy-bootordering, and another is to try to make
560 sysv-rc more robust. Will investigate some more and probably upload a
561 workaround in sysv-rc to help those trying to move from file-rc to
562 sysv-rc get a working shutdown.
</li
>
564 </ul
></p
>
566 <p
>All in all not many surprising issues, and all of them seem
567 solvable before Squeeze is released. In addition to these there are
568 some packages with bugs in their dependencies and run level settings,
569 which I expect will be fixed in a reasonable time span.
</p
>
571 <p
>If you report any problems with dependencies in init.d scripts to
572 the BTS, please usertag the report to get it to show up at
573 <a href=
"http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org
">the
574 list of usertagged bugs related to this
</a
>.
</p
>
576 <p
>Update: Correct bug number to file-rc issue.
</p
>
581 <title>Parallellized boot is now the default in Debian/unstable
</title>
582 <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html
</link>
583 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html
</guid>
584 <pubDate>Fri,
14 May
2010 22:
40:
00 +
0200</pubDate>
585 <description><p
>Since this evening, parallel booting is the default in
586 Debian/unstable for machines using dependency based boot sequencing.
587 Apparently the testing of concurrent booting has been wider than
588 expected, if I am to believe the
589 <a href=
"http://lists.debian.org/debian-devel/
2010/
05/msg00122.html
">input
590 on debian-devel@
</a
>, and I concluded a few days ago to move forward
591 with the feature this weekend, to give us some time to detect any
592 remaining problems before Squeeze is frozen. If serious problems are
593 detected, it is simple to change the default back to sequential boot.
594 The upload of the new sysvinit package also activate a new upstream
597 More information about
598 <a href=
"http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
">dependency
599 based boot sequencing
</a
> is available from the Debian wiki. It is
600 currently possible to disable parallel booting when one run into
601 problems caused by it, by adding this line to /etc/default/rcS:
</p
>
603 <blockquote
><pre
>
605 </pre
></blockquote
>
607 <p
>If you report any problems with dependencies in init.d scripts to
608 the BTS, please usertag the report to get it to show up at
609 <a href=
"http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org
">the
610 list of usertagged bugs related to this
</a
>.
</p
>
615 <title>systemd, an interesting alternative to upstart
</title>
616 <link>http://people.skolelinux.org/pere/blog/systemd__an_interesting_alternative_to_upstart.html
</link>
617 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/systemd__an_interesting_alternative_to_upstart.html
</guid>
618 <pubDate>Thu,
13 May
2010 22:
20:
00 +
0200</pubDate>
619 <description><p
>The last few days a new boot system called
620 <a href=
"http://www.freedesktop.org/wiki/Software/systemd
">systemd
</a
>
622 <a href=
"http://
0pointer.de/blog/projects/systemd.html
">introduced
</a
>
624 to the free software world. I have not yet had time to play around
625 with it, but it seem to be a very interesting alternative to
626 <a href=
"http://upstart.ubuntu.com/
">upstart
</a
>, and might prove to be
627 a good alternative for Debian when we are able to switch to an event
628 based boot system. Tollef is
629 <a href=
"http://bugs.debian.org/
580814">in the process
</a
> of getting
630 systemd into Debian, and I look forward to seeing how well it work. I
631 like the fact that systemd handles init.d scripts with dependency
632 information natively, allowing them to run in parallel where upstart
633 at the moment do not.
</p
>
635 <p
>Unfortunately do systemd have the same problem as upstart regarding
636 platform support. It only work on recent Linux kernels, and also need
637 some new kernel features enabled to function properly. This means
638 kFreeBSD and Hurd ports of Debian will need a port or a different boot
639 system. Not sure how that will be handled if systemd proves to be the
640 way forward.
</p
>
642 <p
>In the mean time, based on the
643 <a href=
"http://lists.debian.org/debian-devel/
2010/
05/msg00122.html
">input
644 on debian-devel@
</a
> regarding parallel booting in Debian, I have
645 decided to enable full parallel booting as the default in Debian as
646 soon as possible (probably this weekend or early next week), to see if
647 there are any remaining serious bugs in the init.d dependencies. A
648 new version of the sysvinit package implementing this change is
649 already in experimental. If all go well, Squeeze will be released
650 with parallel booting enabled by default.
</p
>
655 <title>Parallellizing the boot in Debian Squeeze - ready for wider testing
</title>
656 <link>http://people.skolelinux.org/pere/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html
</link>
657 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html
</guid>
658 <pubDate>Thu,
6 May
2010 23:
25:
00 +
0200</pubDate>
659 <description><p
>These days, the init.d script dependencies in Squeeze are quite
660 complete, so complete that it is actually possible to run all the
661 init.d scripts in parallell based on these dependencies. If you want
662 to test your Squeeze system, make sure
663 <a href=
"http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
">dependency
664 based boot sequencing
</a
> is enabled, and add this line to
665 /etc/default/rcS:
</p
>
667 <blockquote
><pre
>
669 </pre
></blockquote
>
671 <p
>That is it. It will cause sysv-rc to use the startpar tool to run
672 scripts in parallel using the dependency information stored in
673 /etc/init.d/.depend.boot, /etc/init.d/.depend.start and
674 /etc/init.d/.depend.stop to order the scripts. Startpar is configured
675 to try to start the kdm and gdm scripts as early as possible, and will
676 start the facilities required by kdm or gdm as early as possible to
677 make this happen.
</p
>
679 <p
>Give it a try, and see if you like the result. If some services
680 fail to start properly, it is most likely because they have incomplete
681 init.d script dependencies in their startup script (or some of their
682 dependent scripts have incomplete dependencies). Report bugs and get
683 the package maintainers to fix it. :)
</p
>
685 <p
>Running scripts in parallel could be the default in Debian when we
686 manage to get the init.d script dependencies complete and correct. I
687 expect we will get there in Squeeze+
1, if we get manage to test and
688 fix the remaining issues.
</p
>
690 <p
>If you report any problems with dependencies in init.d scripts to
691 the BTS, please usertag the report to get it to show up at
692 <a href=
"http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org
">the
693 list of usertagged bugs related to this
</a
>.
</p
>
698 <title>Debian has switched to dependency based boot sequencing
</title>
699 <link>http://people.skolelinux.org/pere/blog/Debian_has_switched_to_dependency_based_boot_sequencing.html
</link>
700 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Debian_has_switched_to_dependency_based_boot_sequencing.html
</guid>
701 <pubDate>Mon,
27 Jul
2009 23:
50:
00 +
0200</pubDate>
702 <description><p
>Since this evening, with the upload of sysvinit version
2.87dsf-
2,
703 and the upload of insserv version
1.12.0-
10 yesterday, Debian unstable
704 have been migrated to using dependency based boot sequencing. This
705 conclude work me and others have been doing for the last three days.
706 It feels great to see this finally part of the default Debian
707 installation. Now we just need to weed out the last few problems that
708 are bound to show up, to get everything ready for Squeeze.
</p
>
710 <p
>The next step is migrating /sbin/init from sysvinit to upstart, and
711 fixing the more fundamental problem of handing the event based
712 non-predictable kernel in the early boot.
</p
>
717 <title>Taking over sysvinit development
</title>
718 <link>http://people.skolelinux.org/pere/blog/Taking_over_sysvinit_development.html
</link>
719 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Taking_over_sysvinit_development.html
</guid>
720 <pubDate>Wed,
22 Jul
2009 23:
00:
00 +
0200</pubDate>
721 <description><p
>After several years of frustration with the lack of activity from
722 the existing sysvinit upstream developer, I decided a few weeks ago to
723 take over the package and become the new upstream. The number of
724 patches to track for the Debian package was becoming a burden, and the
725 lack of synchronization between the distribution made it hard to keep
726 the package up to date.
</p
>
728 <p
>On the new sysvinit team is the SuSe maintainer Dr. Werner Fink,
729 and my Debian co-maintainer Kel Modderman. About
10 days ago, I made
730 a new upstream tarball with version number
2.87dsf (for Debian, SuSe
731 and Fedora), based on the patches currently in use in these
732 distributions. We Debian maintainers plan to move to this tarball as
733 the new upstream as soon as we find time to do the merge. Since the
734 new tarball was created, we agreed with Werner at SuSe to make a new
735 upstream project at
<a href=
"http://savannah.nongnu.org/
">Savannah
</a
>, and continue
736 development there. The project is registered and currently waiting
737 for approval by the Savannah administrators, and as soon as it is
738 approved, we will import the old versions from svn and continue
739 working on the future release.
</p
>
741 <p
>It is a bit ironic that this is done now, when some of the involved
742 distributions are moving to upstart as a syvinit replacement.
</p
>
747 <title>Debian boots quicker and quicker
</title>
748 <link>http://people.skolelinux.org/pere/blog/Debian_boots_quicker_and_quicker.html
</link>
749 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Debian_boots_quicker_and_quicker.html
</guid>
750 <pubDate>Wed,
24 Jun
2009 21:
40:
00 +
0200</pubDate>
751 <description><p
>I spent Monday and tuesday this week in London with a lot of the
752 people involved in the boot system on Debian and Ubuntu, to see if we
753 could find more ways to speed up the boot system. This was an Ubuntu
755 <a href=
"https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint
">developer
756 gathering
</a
>. It was quite productive. We also discussed the future
757 of boot systems, and ways to handle the increasing number of boot
758 issues introduced by the Linux kernel becoming more and more
759 asynchronous and event base. The Ubuntu approach using udev and
760 upstart might be a good way forward. Time will show.
</p
>
762 <p
>Anyway, there are a few ways at the moment to speed up the boot
763 process in Debian. All of these should be applied to get a quick
768 <li
>Use dash as /bin/sh.
</li
>
770 <li
>Disable the init.d/hwclock*.sh scripts and make sure the hardware
771 clock is in UTC.
</li
>
773 <li
>Install and activate the insserv package to enable
774 <a href=
"http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
">dependency
775 based boot sequencing
</a
>, and enable concurrent booting.
</li
>
779 These points are based on the Google summer of code work done by
780 <a href=
"http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/
">Carlos
783 <p
>Support for makefile-style concurrency during boot was uploaded to
784 unstable yesterday. When we tested it, we were able to cut
6 seconds
785 from the boot sequence. It depend on very correct dependency
786 declaration in all init.d scripts, so I expect us to find edge cases
787 where the dependences in some scripts are slightly wrong when we start
788 using this.
</p
>
790 <p
>On our IRC channel for this effort, #pkg-sysvinit, a new idea was
791 introduced by Raphael Geissert today, one that could affect the
792 startup speed as well. Instead of starting some scripts concurrently
793 from rcS.d/ and another set of scripts from rc2.d/, it would be
794 possible to run a of them in the same process. A quick way to test
795 this would be to enable insserv and run
'mv /etc/rc2.d/S* /etc/rcS.d/;
796 insserv
'. Will need to test if that work. :)
</p
>