Sonarr version (exact version): 2.0.0.5344
Mono version (if Sonarr is not running on Windows):6.12.0.90
OS: Debian Buster
Debug logs:
Description of issue:
After doing as described here (https://sonarr.tv/#downloads-v3-linux-debian), sonarr starts up as a fresh newly installed instance.
None of the config is migrated.
Is this as intended ?
What should i do to migrate from 2 --> 3, preserving the config ?
If you set the same user in the v3 install and the config was in it’s default location it should. At this point you can grab a backup (or the nzbdrone.db from v2) and restore it in the UI.
I did set the exact same user/group in the V3 setup process…fresh install as result.
The thing is running in an LXC on proxmox, so i just did a restore from snapshot when I saw that things weren’t right.
Tried a 2nd time, same result.
I’m back onto 2.x for the moment.
So we’re running as user mediaservice :
$ sudo cat /etc/systemd/system/sonarr.service
[Unit]
Description=Sonarr Daemon
After=network.target
[Service]
User=mediaservice
Group=mediaservices
SyslogIdentifier=sonarr
Type=simple
ExecStart=/usr/bin/mono --debug /opt/NzbDrone/NzbDrone.exe -nobrowser
TimeoutStopSec=20
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
and the config is in that user’s home :
ls -l /home/mediaservice/.config/NzbDrone/
total 7014
drwxr-xr-x 5 mediaservice mediaservices 5 Oct 23 12:49 Backups
-rw-r--r-- 1 mediaservice mediaservices 419 Oct 23 12:26 config.xml
drwxr-xr-x 2 mediaservice mediaservices 8 Oct 22 01:12 logs
-rw-r--r-- 1 mediaservice mediaservices 1720320 Oct 23 15:33 logs.db
-rw-r--r-- 1 mediaservice mediaservices 32768 Oct 23 21:45 logs.db-shm
-rw-r--r-- 1 mediaservice mediaservices 26499872 Oct 23 21:45 logs.db-wal
drwxr-xr-x 78 mediaservice mediaservices 78 Oct 19 18:54 MediaCover
-rw-r--r-- 1 mediaservice mediaservices 11767808 Oct 23 21:52 nzbdrone.db
-rw-r--r-- 1 mediaservice mediaservices 32768 Oct 23 21:55 nzbdrone.db-shm
-rw-r--r-- 1 mediaservice mediaservices 111272 Oct 23 21:55 nzbdrone.db-wal
-rw-r--r-- 1 mediaservice mediaservices 3 Oct 23 12:26 nzbdrone.pid
drwxr-xr-x 2 mediaservice mediaservices 3 Mar 26 2020 UpdateLogs
What am I missing ?
@Taloth might have an idea as he worked on that aspect, I’m not sure why, but backup/restore is the surefire way.
Really depends on how nzbdrone was installed. The v3 script makes an attempt to deal with v2 installs but note that v2 had no systemd unit. So it checks ps aux to see if nzbdrone is running, whether it’s running via systemd and as which user. It then attempts to stop nzbdrone and copy over the config.
if v2 wasn’t running, then it wouldn’t be able to do any of that.
LXC could also be a factor here, preventing the v3 install script from seeing the running systemd unit.
unprivileged LXC,
V2 had been installed using apt from repo (deb http://apt.sonarr.tv/ master main),
the systemd service file contents was included in OP,
$ ps aux | grep -i nzbdro
mediase+ 120 0.0 12.3 1836500 387284 ? Ssl Oct23 43:41 /usr/bin/mono --debug /opt/NzbDrone/NzbDrone.exe -nobrowser
could the length of username play a role here?
The user/grp is actually mediaservice/mediaservices , ps shows mediase+ as user ?
The source has
psNzbDrone=`ps ax -o'user,pid,ppid,unit,args' | grep mono.*NzbDrone\\\\.exe || true`
truncating the user to 7chars with + appended.
This might return the full user name :
ps ax -o'user:20,pid,ppid,unit,args'
That’s just because the name is long.
Run ps ax -o'user,pid,ppid,unit,args' | grep mono.*NzbDrone\\\\.exe || true (you may need to use \\ rather than \\\\, I copied this from the install script)
our replies crossed eachother…
So the preinstall script goes searching for a non-existing user home dir if len username > 8
interesting… thank you for investigating it.
would installing V3 anyway, and importing a backup result in the same as doing apt install sonarr ?
Yes, importing the backup is the same.
The /etc/systemd/system/sonarr.service is tricky anyway. I don’t we properly delete that unit.
We disable the exising systemd unit, but afaik it still interferes with the package provided unit file because the name is the same. (when I originally wrote the script I assumed ppl would likely have something like nzbdrone.service)
I don’t think i’ve updated preinst/postinst to deal with that.
Looks like you do properly handle it, given this & following lines :
if [ "$psNzbDroneUnit" = "sonarr.service" ]; then
# Conflicts with our new sonarr.service so we have to remove it
echo "NzbDrone systemd startup detected at $psNzbDroneUnit, stopping and removing..."
deb-systemd-invoke stop $psNzbDroneUnit >/dev/null
Anyway, i’ll try backup, followed by apt purge, and apt install.
Thx for your time & for the code !!
If you want I can fix the the user:20 and get you a .deb file. No better place to test changes than in production.
And apparently I did fix the sonarr.service edgecase… I admit, it’s been a while.
I’m game for testing…restoring from snapshot is…well… a snap.
This works in terminal:
$ echo `ps ax -o'user:20,pid,ppid,unit,args' | grep mono.*NzbDrone\\\\.exe || true` | tr -s ' ' | cut -d ' ' -f 1
mediaservice
Taken from line #12
I see you made the fix, how can I test it ?
The build agent is down atm and markus just went to sleep. It’ll have to wait 8-10 hours or so.
But once it’s built, I’ll upload the .deb and let you know.
okay, it’ll be smt for tomorrow then.
Try again. I replaced the 3.0.4 package directly (I didn’t want to update to 3.0.5 for just this), so I’m not if the cache has expired already by the time you get it. So I dropped a temporary copy here.
Not knowing if the cache has already expired, I just took the .deb route :
$ sudo dpkg -i sonarr_3.0.4_all.deb
Selecting previously unselected package sonarr.
dpkg: considering removing nzbdrone in favour of sonarr ...
dpkg: yes, will remove nzbdrone in favour of sonarr
(Reading database ... 45145 files and directories currently installed.)
Preparing to unpack sonarr_3.0.4_all.deb ...
NzbDrone systemd startup detected at sonarr.service, stopping and removing...
Unpacking sonarr (3.0.4) ...
dpkg: warning: while removing nzbdrone, directory '/opt' not empty so not removed
Setting up sonarr (3.0.4) ...
Found NzbDrone database in /home/mediaservice/.config/NzbDrone, copying to /var/lib/sonarr.
Removed /etc/systemd/system/multi-user.target.wants/sonarr.service.
Created symlink /etc/systemd/system/multi-user.target.wants/sonarr.service → /lib/systemd/system/sonarr.service.
tom@sonarradarr:~$
The config has migrated. 
Only thing is, the media artwork isn’t present.
Is this expected , or are we still missing smt ?
edit : Browser concole throws 404 not found for the mediacover files.
root@sonarradarr:/home/mediaservice/.config/NzbDrone# du M* -sh
75M MediaCover
so, the files exist.
# tail /var/log/syslog
Oct 25 10:11:25 sonarradarr mono[25058]: [Warn] MediaCoverMapper: File /var/lib/sonarr/MediaCover/77/poster.jpg not found
But sonarr is looking for them in another location.
@Taloth Question : do you feel that this :
root@sonarradarr:/home/mediaservice/.config/NzbDrone# mv MediaCover /var/lib/sonarr/
is the cleanest long-term solution ?
It’s kinda expected, for v3 we simply rely on the next series refresh to repopulate the covers. The log files etc aren’t copied either. It’s essentially a import from backup, and copies only the config.xml and database.
The v2 to v3 migration is best effort anyway. The only reason it’s even there is to properly stop existing v2 installs whenever we can.
Maybe I’ll force a series refresh after install to avoid people panicking. (That said, they should be following a migration guide)
Should I not have moved the MediaCover files?
All seems well now…but I could always restore from snapshot & do the migration again. Leaving Mediacovers alone.