Ubuntu

upstart breaks inittab

Reported by John Nilsson on 2006-10-17
24
Affects Status Importance Assigned to Milestone
daemontools-installer (Debian)
Fix Released
Unknown
daemontools-installer (Ubuntu)
Undecided
Unassigned

Bug Description

In a recent edgy upgrade sysvinit was replaced with upstart. I guess upstart doesn't parse /etc/inittab as this line
SV:123456:respawn:/usr/bin/svscanboot
seems to have no effect.

replacing with a file in /etc/event.d
--- /etc/event.d/svscan ---
start on runlevel-1
start on runlevel-2
start on runlevel-3
start on runlevel-4
start on runlevel-5
start on runlevel-6

stop on shutdown

respawn /usr/bin/svscanboot
--- EOF ---
seems to work though.

We have a limited migration script for /etc/inittab, which can migrate those modifications that we expect people to make.

The problem is that the inittab file format is so free-form that it's not really possible to do anything other than a guided migration -- which violates our update policy.

Michael Shuler (mshul3r) wrote :

Thanks for the event.d example, John. This is an issue on feisty, and you can bet that it will not be fixed up upstream ;)

John, I believe the runlevel-x lines should not include a hyphen:

--- /etc/event.d/svscan ---
start on runlevel 1
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
start on runlevel 6

stop on shutdown

respawn /usr/bin/svscanboot
--- EOF ---

Kind Regards,
Michael

John Nilsson (john-milsson) wrote :

Just upgraded to Feisty Fawn
This seems to work
--- /etc/event.d/svscan ---
# svscan
#
# upstart service for svscan created by me (John)

start on runlevel 1
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
start on runlevel 6

respawn
exec /usr/bin/svscanboot
--- EOF ---

Any chance of getting the event.d file installed by daemontools-installer instead of the init.d entry?

ward (ward-pong) wrote :

<i>Any chance of getting the event.d file installed by daemontools-installer instead of the init.d entry?</i>

That would be great indeed.

John Nilsson (john-milsson) wrote :

Just a heads up. The config file I posted earlier will lead to poroblems with unmounting on shutdown.

The following should be more correct.
--- /etc/event.d/svscan ---
start on runlevel 2
start on runlevel 3

stop on runlevel 0
stop on runlevel 1
stop on runlevel 4
stop on runlevel 5
stop on runlevel 6

respawn
exec /usr/bin/svscanboot
--- EOF ---

Mrts (mrts) wrote :

The Debian/Ubuntu run levels are as follows:

0 System Halt
1 Single user
2 Full multi-user mode (Default)
3-5 Same as 2
6 System Reboot

Thus, a correct /etc/event.d/svscan is as follows:
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5

stop on runlevel 0
stop on runlevel 1
stop on runlevel 6

respawn
exec /usr/bin/svscanboot

Download full text (16.8 KiB)

This bug is still an issue...tested in latest Hardy. The problem is that daemontools-installer first encounters problems with /etc/inittab...

<snip>
root@khermans-laptop:~# build-daemontools

This script unpacks the daemontools source into a directory, and
compiles it to produce a binary daemontools*.deb file.

The directory where this is done will end up containing the source
and package files for the daemontools binary package, along with a
directory containing the unpacked source.

Enter a directory where you would like to do this [/tmp/daemontools]

Please select package format
 The "djb" format is the way that daemontools would be installed if you
 downloaded the source yourself and compiled it. This will create several
 new top-level directories such as /package and /command. It will also
 use /service as the service directory.
 .
 The "fhs" format is an FHS-compatible format which installes all binaries
 in /usr/bin, and uses /var/lib/svscan as the service directory. This format
 is NOT recommended as it will most likely not be supported by DJB or any
 of his mailing lists.
 .
 *IMPORTANT* if you choose the DJB version, a new directory called /service
 will be created. If you are upgrading from an old release, you may or may
 not have a symlink pointing from /service to /var/lib/svscan. Either way,
 before upgrading I suggest you remove this symlink and then copy the existing
 data from /var/lib/svscan to /service after the upgrade.

Which format would you like to use? [fD]

Binary package daemontools will be compiled now
This can take long time, depending on your machine

If you want me to apply any patches, please make sure that
they are located in /usr/src/daemontools-installer/patches/.

Press ENTER to continue...
Attempting to apply patches located in /usr/src/daemontools-installer/patches...
/usr/src/daemontools-installer/patches/errno.patch
patching file src/error.h
/usr/src/daemontools-installer/patches/fileutils.patch
patching file src/rts.tests
dh_testdir
package/compile
Linking ./src/* into ./compile...
Compiling everything in ./compile...
make[1]: Entering directory `/tmp/daemontools/admin/daemontools-0.76/compile'
sh find-systype.sh > systype
rm -f compile
sh print-cc.sh > compile
chmod 555 compile
./compile byte_chr.c
./compile byte_copy.c
./compile byte_cr.c
./compile byte_diff.c
./compile byte_rchr.c
./compile fmt_uint.c
./compile fmt_uint0.c
./compile fmt_ulong.c
rm -f makelib
sh print-ar.sh > makelib
chmod 555 makelib
./compile scan_ulong.c
./compile str_chr.c
./compile str_diff.c
./compile str_len.c
./compile str_start.c
./makelib byte.a byte_chr.o byte_copy.o byte_cr.o byte_diff.o \
        byte_rchr.o fmt_uint.o fmt_uint0.o fmt_ulong.o scan_ulong.o str_chr.o \
        str_diff.o str_len.o str_start.o
rm -f choose
cat warn-auto.sh choose.sh \
        | sed s}HOME}"`head -1 home`"}g \
        > choose
chmod 555 choose
./choose c trydrent direntry.h1 direntry.h2 > direntry.h
./compile envdir.c
rm -f load
sh print-ld.sh > load
chmod 555 load
./compile alloc.c
./compile alloc_re.c
./compile buffer.c
./compile buffer_0.c
./compile buffer_1.c
./compile buffer_2.c
./compile buffer_get.c
./compile buffer_put.c
....

Confirming this bug report...

Changed in daemontools-installer:
status: New → Confirmed
Changed in daemontools-installer:
status: Unknown → New
Sandip Bhattacharya (sandipb) wrote :

As a temporary workaround reference for me(when I install this again after a while forgetting eveything that I had to read up to fix the problem) as well as others, here are the steps.

Steps to be taken after the installer fails.

1. sudo touch /etc/inittab
2. sudo dpkg -i /tmp/daemontools/admin/daemontools_xxxx.deb
3. (Add the config mentioned by mrts to /etc/event.d/svscan)
    sudo pico /etc/event.d/svscan
    add this>>
                      start on runlevel 2
                      start on runlevel 3
                      start on runlevel 4
                      start on runlevel 5

                      stop on runlevel 0
                      stop on runlevel 1
                      stop on runlevel 6

                      respawn
                      exec /usr/bin/svscanboot
     <<
4. sudo initctl start svscan

From next boot onwards, you don't need to do (4).

Changed in daemontools-installer:
status: New → Fix Released
Greg A (etulfetulf) wrote :

The package has removed from Ubuntu Hardy and later versions. For this reason I am marking as Invalid.

Changed in daemontools-installer:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.