After starting and stopping the openrc service a process remains (mono /opt/sonarr/Sonarr.exe) and the service is still reachable through a browser. The expected behaviour is that the service is shut down. I noticed that the shell script (/opt/sonarr/Sonarr) does stop, but the called Sonarr.exe instance does not stop. The SIGTERM doesn't reach the spawned process?
I offer that this uncommon consequential symptom can happen with sonarr in general and also can occur with systemd however it should be uncommon. The reliance on mono by sonarr occasionally produces some runtime quirks such as the reported symptom. If I ever encounter this I'll attempt to kill the mono process id and restart sonarr. If you've had to attempt that repeatedly and the same behaviour symptom reoccurs I might question of there are contributing gentoo system config reasons why that has reoccurred. There are many potential varying factors of gentoo system builds that may contribute to general system reliability concerns. If your running a full unstable gentoo system build configured with ACCEPT_KEYWORDS=~arch" general system stability concerns can be far more common including unresponsive system processes.
@lg188 can you provide the logfile result of emerge --info >emerge-info.log
Created attachment 860883 [details] emerge --info output
Thanks for submitting that information. without the capability to review that It wouldn't have been possible to determine your system configuration is essentially a science experiment build in some significant ways that could potentially be corrected. As I suspected you have a full unstable system build configuration. More of a gentoo system build overall can just be less reliable as a result. configuring ACCEPT_KEYWORDS="~amd64" will provide assurances that some application instability are more likely to be consequentially suspected root causes for system application instability. It also appears you have fish shell set as the root environment user shell and that's not recommended at all. SHELL="/bin/fish" fish when used for root user shell environments breaks gentoo's reliance on bash scripted /etc/env.d environment configurations that set the PATH and other important environment configurations. I spotted something potentially unusual in emerge --info that may potentially be related to a root cause of system instability. I_KNOW_WHAT_I_AM_DOING="1" If i recall correctly this config variable is only used to allow force downgrading glibc versions that would imply a risk of breaking a gentoo install. There's a few major key root causes provided by your system build that likely could cause system instability. Science experiment builds will do that. the newest mono version and what produced it will more commonly provide the results you've reported. If you reverted to full stable with mixed testing packages by only using unstable packages selectively with package.accept.keywords I'm confident the symptoms you reported would not occur. I cannot reproduce the behaviour on my stable gentoo server that uses some mixed testing masked packages. Can you also provide your make.conf config file?
Their system config looks fine other than the I_KNOW variable. Using ~arch is fine and not something we should be harshly recommending against. Please don't do that.
also not sure what the mono comment is about, there's only one in tree anyway and it's stable..?
I can confirm this issue on openrc. This could happen due to mono. It may be forking or something like that and therefore wrong pid got recorded, thus it attempts to stop the wrong process. On the other hand, they allegedly plan dropping mono and starting using dotnet at or after version 4. This should unify sonarr with other *arr packages. Others [*arr packages] do in fact stop upon request. Although sometimes crash in the process, but that might be another issue. I glanced through their sources and it appears they may somehow expose the real pid: https://github.com/Sonarr/Sonarr/blob/87021fff434b52455442327b164a40d332755435/src/NzbDrone.Common/EnvironmentInfo/AppFolderFactory.cs#L212-L218. I suspect this may be used in the meanwhile as a temporary solution, but I doubt it being a "grave" issue needing a fix ASAP.
