desktop-packages team mailing list archive

[Thomas M Steenholdt <1532552@xxxxxxxxxxxxxxxxxx>]

I was wrong. It appears as if the XFS filesystem on / is the actual culprit here.
The way XFS works, makes it lose last-second changes such as the new settings file written by transmission-daemon, whet the power is cut after halt. I've added a "sync" to my UPS power-off script and everything appears to be much more stable now.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to transmission in Ubuntu.
https://bugs.launchpad.net/bugs/1532552

Title:
  transmission-daemon settings gone after system halt

Status in transmission package in Ubuntu:
  Invalid

Bug description:
  Ubuntu-15.10, amd64
  systemd-225-1ubuntu9
  transmission-daemon-2.84-1ubuntu1

  I've noticed more than once, that "halt" can cause transmission-daemon
  to loose it's settings. AFAIK, "halt" is not that different from
  "poweroff" or "reboot" in regards to the shutdown sequence, so it is
  probably a problem for those as well.

  What I've noticed is that after my system comes back up after being
  halted, transmission-daemon won't start, citing config issues. Looking
  at /etc/transmission-daemon/settings.json, it's there but it's empty.

  This does not happen every time, but I've seen it on at least 3
  different occasions.

  My guess (and I'm relatively new to systemd) is that while the
  transmission-daemon systemd unit-file wants to start after
  network.target, there is nothing that would prompt a "stop" of the
  service during shutdown. This seems to leave a race where the
  transmission-daemon is killed too close to remounting the / filesystem
  read-only, giving the daemon enough time to truncate it's config, yet
  making it impossible for the daemon to write it's settings, as it
  likes to do on "stop".

  My / filesystem is XFS, but that does not seem to have anything to do
  with this.

  I'm still looking for a way to map out the dependencies of systemd on
  shutdown, but it seems to me that perhaps adding
  Require=network.target to the unit-file might cause the daemon to stop
  early and solve this issue.

  Please let me know if you need anything else

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