Bug #15344
/sbin/start-stop-daemon does nothing but exit 0: prevents rng-tools from starting
100%
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.
Subtasks
Related issues
|
Blocks Tails - |
Resolved | 2017-06-29 |
History
#1 Updated by intrigeri 2018-02-24 12:14:04
- 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 2018-02-24 14:56:54
- 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 2018-02-27 11:59:30
- blocks
Feature #13245: Core work 2018Q1: Foundations Team added
#4 Updated by intrigeri 2018-02-27 12:00:04
- 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 2018-02-27 12:06:09
- 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 commit: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 2018-02-27 12:16:32
- % Done changed from 0 to 10
- Feature Branch set to bugfix/15344-repair-start-stop-daemon
#7 Updated by intrigeri 2018-02-27 13:10:49
- 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 2018-02-27 15:29:35
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 2018-02-28 13:47:27
- Status changed from In Progress to Fix committed
- 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 2018-03-14 11:04:58
- Status changed from Fix committed to Resolved