[Bug 1257036] Re: services started with eatmydata should remove eatmydata by default

[Scott Moser]

In trying to test my fix for this, i went through a few packages before
I found one that was actually broken.  It seems that many packages
(apache2, postgres, anacron) end up cleaning their own environment.

One package that *is* affected is 'backuppc' as demonstrated here:

$ sudo apt-get install --quiet --assume-yes eatmydata
$ sudo eatmydata apt-get install --assume-yes backuppc
$ sudo service backuppc status
 * backuppc is running
$ sudo cat /proc/$pid/environ | tr '\0' '\n' | grep ^LD_PRELOAD
LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so /usr/lib/libeatmydata/libeatmydata.so

After the fix is applied, we see:

$ sudo cat /proc/$pid/environ | tr '\0' '\n' | grep ^LD_PRELOAD
LD_PRELOAD=

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to sysvinit in Ubuntu.
https://bugs.launchpad.net/bugs/1257036

Title:
  services started with eatmydata should remove eatmydata by default

Status in “sysvinit” package in Ubuntu:
  Confirmed

Bug description:
  when services are started from sysvinit (/etc/init.d/$SERVICE start),
  LD_PRELOAD will pass through to the started service.  That is fine,
  and even expected/desired in most cases.

  One explicit case where it is not expected (most of the time) is
  eatmydata is used.

  The use case that I want to "do the right thing" is:
   sudo eatmydata apt-get install mysql

  Here, I want apt-get to run with eatmydata (in order to improve
  performance), but do not want the mysql daemon to start with fsync()
  disabled.

  My solution to this problem is to simply have something clean
  libeatmydata.so from LD_PRELOAD prior to starting services.  I'd
  support an environment variable NEVER_DISABLE_LIBEATMYDATA=1 that
  would enable the user who wanted eatmydata to pass through to the
  service.

  It seems the common place for this to be done would be either:
   a.) /usr/sbin/service (sysvinit-utils)
   b.) invoke-rc.d

  Doing this in invoke-rc.d fixes it for the 'dpkg install' path, and is
  the least invasive path.  (fixing 'service' would not actually fix the
  dpkg install path as invoke-rc.d does not call service).

  so, I'd suggest we fix this in invoke-rc.d.


  Related bugs:
   * bug 1236531: cloud-init support package install with eatmydata

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: sysv-rc 2.88dsf-41ubuntu4
  ProcVersionSignature: Ubuntu 3.12.0-4.12-generic 3.12.1
  Uname: Linux 3.12.0-4-generic x86_64
  ApportVersion: 2.12.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Dec  2 14:26:17 2013
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2011-10-19 (775 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  PackageArchitecture: all
  SourcePackage: sysvinit
  UpgradeStatus: Upgraded to trusty on 2013-05-20 (196 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1257036/+subscriptions