Feature #5750

Supervise critical services

Added by Tails 2013-07-18 07:45:44 . Updated 2015-11-10 02:43:58 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.0
Start date:
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:
269

Description

If any of the core services (e.g. Tor) crashes, a clueless user will have to reboot after realising that "Internet won’t come back". That can be quite frustrating.

Supervising these services would be nice.

Given we’ll move to an init system (Feature #5821) that knows how to baby-sit services once Tails is based on Jessie, we can use it and find / adapt / write systemd unit files for the services we want to supervise.

Most of the work should be done in Debian and upstream first.

Subtasks

Related issues

Related to Tails - Bug #10528: Restore AppArmor confinement of Tor on Jessie Resolved 2015-11-10
Blocked by Tails - Feature #5821: Switch to systemd as pid 1 Resolved 2014-05-09 2015-06-01

History

#1 Updated by intrigeri 2013-07-19 07:01:55

  • Type of work changed from Wait to Code

#2 Updated by BitingBird 2014-06-09 11:04:21

  • Subject changed from supervise critical services to Supervise critical services
  • Starter set to No

#3 Updated by intrigeri 2015-03-02 18:56:41

  • Description updated

#4 Updated by intrigeri 2015-03-10 00:36:08

  • Description updated

#5 Updated by intrigeri 2015-03-10 01:52:26

  • Description updated
  • Type of work changed from Code to Debian

Here are the daemons we currently run from SysV initscripts in Tails/Jessie:

  • Tor: we should test the unit file from upstream Git in Tails; for it to load the AppArmor profile, we need either one of:
    • renaming the system_tor profile to usr.sbin.tor: should work, highly Tails-specific but so trivial that it’s no big deal — and we can get rid of this hack in Tails/Stretch
    • wrapping the tor daemon’s startup with aa-exec
    • a more recent systemd than Jessie’s one, hopefully from jessie-backports, compiled with AppArmor support (which is the case since 218-4 in Debian experimental)
    • rebuilding Jessie’s systemd with AppArmor support (I’ve been using that for months)
  • ekeyd, spice-vdagent, ttdnsd: not exactly critical?

#6 Updated by intrigeri 2015-05-28 15:21:33

  • Assignee set to intrigeri
  • Target version set to Tails_2.0

#7 Updated by intrigeri 2015-05-28 15:21:49

  • blocks #8668 added

#8 Updated by intrigeri 2015-08-09 09:32:04

  • Type of work changed from Debian to Code

#9 Updated by intrigeri 2015-08-26 05:58:36

  • Deliverable for set to 269

#10 Updated by intrigeri 2015-11-09 08:33:26

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

> * Tor: we should test the unit file from upstream Git in Tails;

feature/jessie now installs Tor 0.2.7.x packages that have the systemd unit file, but I think this is still true:

> for it to load the AppArmor profile, we need either one of: […]

#11 Updated by intrigeri 2015-11-10 02:43:58

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 100

On current feature/jessie, Tor is managed by tor@default.service, which restarts the daemon if it dies (tested with kill -9; this brings a regression in a different area, that is tracked separately as Bug #10528).

I think that supervising tor was the last blocker, since:

  • on Jessie, most other services we run are managed by systemd already;
  • the remaining services started with sysvinit (systemctl | grep LSB) are not critical;

=> I’m calling this done.

#12 Updated by intrigeri 2015-11-10 02:45:21

  • related to Bug #10528: Restore AppArmor confinement of Tor on Jessie added