Project

General

Profile

Bug #15344

/sbin/start-stop-daemon does nothing but exit 0: prevents rng-tools from starting

Added by segfault almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
02/22/2018
Due date:
% Done:

100%

Feature Branch:
bugfix/15344-repair-start-stop-daemon
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

The fake start-stop-daemon is created by live-build, and should be replaced with the original at the end of the build process. But because of 60ef4e4d9d650de166689cdf914afb9a19734a28, the start-stop-daemon.orig gets deleted before it can be restored by live-build.


Related issues

Blocks Tails - Feature #13245: Core work 2018Q1: Foundations Team Resolved 06/29/2017

Associated revisions

Revision 78cd37c6 (diff)
Added by intrigeri almost 2 years ago

Repair rng-tools (regression introduced in Tails 3.0~rc2): let live-build restore the real start-stop-daemon program (refs: #15344)

Revision 65ccc661
Added by bertagaz almost 2 years ago

Merge remote-tracking branch 'origin/bugfix/15344-repair-start-stop-daemon' into devel

Fix-committed: #15344

History

#1 Updated by intrigeri almost 2 years ago

  • Assignee set to segfault
  • QA Check set to Info Needed

The fake start-stop-daemon is created by live-build, and should be replaced with the original at the end of the build process. But because of 60ef4e4d9d650de166689cdf914afb9a19734a28, the start-stop-daemon.orig gets deleted before it can be restored by live-build.

In order to prioritize/dispatch this task I'd like to better understand the practical impact of this bug. It's only a problem for services that have a SysV initscript and no systemd unit, right? Do you have examples of real-world problems this causes?

#2 Updated by segfault almost 2 years ago

  • Assignee deleted (segfault)
  • QA Check deleted (Info Needed)

intrigeri wrote:

The fake start-stop-daemon is created by live-build, and should be replaced with the original at the end of the build process. But because of 60ef4e4d9d650de166689cdf914afb9a19734a28, the start-stop-daemon.orig gets deleted before it can be restored by live-build.

In order to prioritize/dispatch this task I'd like to better understand the practical impact of this bug. It's only a problem for services that have a SysV initscript and no systemd unit, right? Do you have examples of real-world problems this causes?

It's also a problem for systemd units that are generated from SysVinit scripts. Those can be found in /run/systemd/generator.late. In Tails 3.5, this directory contains rng-tools.service and speech-dispatcher.service. So those services are not actually executed, even though systemd thinks they are.

#3 Updated by intrigeri almost 2 years ago

#4 Updated by intrigeri almost 2 years ago

  • Assignee set to intrigeri
  • Target version set to Tails_3.6

Assignee deleted (segfault)
QA Check deleted (Info Needed)

In general, when providing the requested info, please reassign to the person who requested the info: otherwise you implicitly rely on the fact that person reads all Redmine changes.

It's also a problem for systemd units that are generated from SysVinit scripts. Those can be found in /run/systemd/generator.late. In Tails 3.5, this is directory contains rng-tools.service and speech-dispatcher.service. So those services are not actually executed, even though systemd thinks they are.

Good catch! I wasn't sure we were still shipping any such initscripts. I'm actually glad there are only 2 such initscripts… even though if we had more of those, we would probably have noticed this bug much earlier.

#5 Updated by intrigeri almost 2 years ago

  • Subject changed from /sbin/start-stop-daemon does nothing but exit 0 to /sbin/start-stop-daemon does nothing but exit 0: prevents rng-tools from starting
  • Status changed from Confirmed to In Progress

segfault wrote:

It's also a problem for systemd units that are generated from SysVinit scripts. Those can be found in /run/systemd/generator.late. In Tails 3.5, this directory contains rng-tools.service and speech-dispatcher.service. So those services are not actually executed, even though systemd thinks they are.

I confirm that this will probably prevent rng-tools.service from starting (regression introduced by 60ef4e4d9d650de166689cdf914afb9a19734a28 in Tails 3.0~rc2, affecting Tails up to 3.5 inclusive).

Regarding speech-dispatcher.service we don't care as it's disabled in /etc/default/speech-dispatcher anyway.

#6 Updated by intrigeri almost 2 years ago

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/15344-repair-start-stop-daemon

#7 Updated by intrigeri almost 2 years ago

  • Assignee changed from intrigeri to bertagaz
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

On an ISO built from the topic branch, in a VM with a RNG device:

* rng-tools.service
   Loaded: loaded (/etc/init.d/rng-tools; generated)
   Active: active (running) since Tue 2018-02-27 13:07:27 UTC; 1min 8s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 4 (limit: 4701)
   CGroup: /system.slice/rng-tools.service
           `-1144 /usr/sbin/rngd -r /dev/hwrng

Feb 27 13:07:26 amnesia systemd[1]: Starting rng-tools.service...
Feb 27 13:07:26 amnesia rng-tools[1132]: Starting Hardware RNG entropy gatherer daemon: rngd.
Feb 27 13:07:26 amnesia rngd[1144]: rngd 2-unofficial-mt.14 starting up...
Feb 27 13:07:26 amnesia rngd[1144]: entropy feed to the kernel ready
Feb 27 13:07:27 amnesia systemd[1]: Started rng-tools.service.

… and /sbin/start-stop-daemon is an ELF executable, not a shell script anymore. I didn't run the test suite yet so I suggest you do a code review to save some time but wait for the test results on Jenkins to ensure this does not break anything.

#8 Updated by intrigeri almost 2 years ago

Test suite results (non-fragile) on my local Jenkins:

15:11:32 Failing Scenarios:
15:11:32 cucumber features/time_syncing.feature:37 # Scenario: Boot with a hardware clock set way in the past and make sure that Tails sets the clock to the source date
15:11:32 cucumber features/additional_software_packages.feature:8 # Scenario: Additional software packages are installed even without network

… but these scenarios always fail for me here so it's not the fault of my branch.

#9 Updated by bertagaz almost 2 years ago

  • Status changed from In Progress to 11
  • Assignee deleted (bertagaz)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Builds fine, and it passes automated test suite in Jenkins or locally fine (except unrelated failures). So it's merged for 3.6. Good catch segfault!

#10 Updated by bertagaz almost 2 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF