3.0.4 to 3.0.5 (using offical ppa) bug

I upgraded to 3.0.5 last night and freaked when after the upgrade completed, my install was none responsive. It was not responding on the port I assigned it to. Once I figured out it the install reverted back to it’s original port, and I connected to it, all shows were gone.

After some digging, seems when you upgrade using official ppa, the script changes the ExecStart line in /lib/systemd/system/sonarr.service. I don’t have my original anymore (as it’s gone now), but best I can figure is this :

Mine : ExecStart=/usr/bin/mono --debug /usr/lib/sonarr/bin/Sonarr.exe -nobrowser -data=/home/qbt/.config/sonarr

PPA : ExecStart=/usr/bin/mono --debug /usr/lib/sonarr/bin/Sonarr.exe -nobrowser -data=/var/lib/sonarr

Notice the difference in “-data”? This is the root cause. I had an old /var/lib/sonarr that was never used. I keep my data in /home/qbt/.config/sonarr (yeah I’m weird that way). For now, I’ve symlinked /var/lib/sonarr to /home/qbt/.config/sonarr. Restarted the service… all is back on the port I assigned the service to. If the PPA upgrades are actually messing with the ExecStart line, this a fix.

Suggestion: Please don’t mess around with “ExecStart” in PPA upgrades :slight_smile:

Users should NOT edit systemd units. /lib/systemd/system/sonarr.service is owned by the package and should never be modified by the user. (Otherwise it would be in /etc/systemd/…)
There’s override support in systemd (google it). And Sonarr has debconf support for several parameters, including the config folder (as low prio debconf option).

1 Like

Learn something new every day. Thanks!

PS: cmdline is dpkg-reconfigure -plow sonarr in this case.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.