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.
sonarr v4 just pushed to master today introducing .net 6.x native builds effectively eliminating the reliance on mono. https://www.reddit.com/r/sonarr/comments/18u2xfl/sonarr_v4/ This upgrade should be handled cautiously and not rushed however should improve the behaviour of a mono process going zombie mode. the behaviour of radarr that's been using .net native binary builds doesn't exhibit the "malfunctions" sonarr v3 and old radarr that did rely on mono. @Chris Andrews can we possibly try to add stable tagged ebuilds for sonarr and radarr then only stabilize Radarr.master releases? My radarr database was "broken" by ingesting every pre-release radarr development version and the activity history in my radarr database fails to load due to an sql syntax error introduced by a buggy pre-release development build. This can be avoided by stabilizing upstream branch ebuilds. I always ensured this was a top priority in my overlay I maintained so I wouldn't be the recipient of you broke my database "hate mail" :) I should be more active helping maintain this as I used to in my overlay however I'm not certain what I can do. the sonarr ebuild requires a rewrite to use the dotnet format radarr relies on to use sonarr v4 and that major version bump should stabilize the last sonarr v3 version to permit upgrade migration testing.
(In reply to Michael Crawford (ali3nx) from comment #8) > sonarr v4 just pushed to master today introducing .net 6.x native builds > effectively eliminating the reliance on mono. > > https://www.reddit.com/r/sonarr/comments/18u2xfl/sonarr_v4/ > > This upgrade should be handled cautiously and not rushed however should > improve the behaviour of a mono process going zombie mode. the behaviour of > radarr that's been using .net native binary builds doesn't exhibit the > "malfunctions" sonarr v3 and old radarr that did rely on mono. > > @Chris Andrews can we possibly try to add stable tagged ebuilds for sonarr > and radarr then only stabilize Radarr.master releases? > > My radarr database was "broken" by ingesting every pre-release radarr > development version and the activity history in my radarr database fails to > load due to an sql syntax error introduced by a buggy pre-release > development build. > > This can be avoided by stabilizing upstream branch ebuilds. I always ensured > this was a top priority in my overlay I maintained so I wouldn't be the > recipient of you broke my database "hate mail" :) > > I should be more active helping maintain this as I used to in my overlay > however I'm not certain what I can do. > > the sonarr ebuild requires a rewrite to use the dotnet format radarr relies > on to use sonarr v4 and that major version bump should stabilize the last > sonarr v3 version to permit upgrade migration testing. Only the activity history in my radarr log post v5 upgrade displays this sql query error when I refresh the activity history and otherwise every radarr feature functions correctly. radarr-v5-prerelease v4 sqlite database upgrade Dec 30 00:35:11 fenrir Radarr[4381]: SQLite error (1): no such column: Movies.SortTitle in "SELECT "History".*, "Movies".*, "QualityProfiles".* FROM "History" JOIN "Movies" ON ("History"."MovieId" = "Movies"."Id") JOIN "QualityProfiles" ON ("Movies"."QualityProf Dec 30 00:35:11 fenrir Radarr[4381]: [Error] RadarrErrorPipeline: [GET /api/v3/history] Dec 30 00:35:11 fenrir Radarr[4381]: [v5.2.4.8328] code = Error (1), message = System.Data.SQLite.SQLiteException (0x800007BF): SQL logic error Dec 30 00:35:11 fenrir Radarr[4381]: no such column: Movies.SortTitle Dec 30 00:35:11 fenrir Radarr[4381]: at System.Data.SQLite.SQLite3.Prepare(SQLiteConnection cnn, String strSql, SQLiteStatement previous, UInt32 timeoutMS, String& strRemain) Dec 30 00:35:11 fenrir Radarr[4381]: at System.Data.SQLite.SQLiteCommand.BuildNextCommand() Dec 30 00:35:11 fenrir Radarr[4381]: at System.Data.SQLite.SQLiteDataReader.NextResult() Dec 30 00:35:11 fenrir Radarr[4381]: at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) Dec 30 00:35:11 fenrir Radarr[4381]: at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) Dec 30 00:35:11 fenrir Radarr[4381]: at Dapper.SqlMapper.ExecuteReaderWithFlagsFallback(IDbCommand cmd, Boolean wasClosed, CommandBehavior behavior) in /_/Dapper/SqlMapper.cs:line 1142 Dec 30 00:35:11 fenrir Radarr[4381]: at Dapper.SqlMapper.MultiMapImpl[TFirst,TSecond,TThird,TFourth,TFifth,TSixth,TSeventh,TReturn](IDbConnection cnn, CommandDefinition command, Delegate map, String splitOn, DbDataReader reader, Identity identity, Boolean finalize)+MoveNext() in /_/Dapper/SqlMapper.cs:line 1537 Dec 30 00:35:11 fenrir Radarr[4381]: at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) Dec 30 00:35:11 fenrir Radarr[4381]: at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) Dec 30 00:35:11 fenrir Radarr[4381]: at Dapper.SqlMapper.MultiMap[TFirst,TSecond,TThird,TFourth,TFifth,TSixth,TSeventh,TReturn](IDbConnection cnn, String sql, Delegate map, Object param, IDbTransaction transaction, Boolean buffered, String splitOn, Nullable`1 commandTimeout, Nullable`1 commandType) in /_/Dapper/SqlMapper.cs:line 1518 Dec 30 00:35:11 fenrir Radarr[4381]: at NzbDrone.Core.Datastore.SqlMapperExtensions.Query[TFirst,TSecond,TThird,TReturn](IDatabase db, String sql, Func`4 map, Object param, IDbTransaction transaction, Boolean buffered, String splitOn, Nullable`1 commandTimeout, Nullable`1 commandType) in ./Radarr.Core/Datastore/Extensions/SqlMapperExtensions.cs:line 82 Dec 30 00:35:11 fenrir Radarr[4381]: at NzbDrone.Core.Datastore.SqlMapperExtensions.QueryJoined[T,T2,T3](IDatabase db, SqlBuilder builder, Func`4 mapper) in ./Radarr.Core/Datastore/Extensions/SqlMapperExtensions.cs:line 164 Dec 30 00:35:11 fenrir Radarr[4381]: at NzbDrone.Core.Datastore.BasicRepository`1.GetPagedRecords(SqlBuilder builder, PagingSpec`1 pagingSpec, Func`2 queryFunc) in ./Radarr.Core/Datastore/BasicRepository.cs:line 434 Dec 30 00:35:11 fenrir Radarr[4381]: at NzbDrone.Core.History.HistoryRepository.GetPaged(PagingSpec`1 pagingSpec, Int32[] languages, Int32[] qualities) in ./Radarr.Core/History/HistoryRepository.cs:line 100 Dec 30 00:35:11 fenrir Radarr[4381]: at NzbDrone.Core.History.HistoryService.Paged(PagingSpec`1 pagingSpec, Int32[] languages, Int32[] qualities) in ./Radarr.Core/History/HistoryService.cs:line 54 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Api.V3.History.HistoryController.<>c__DisplayClass7_0.<GetHistory>b__2(PagingSpec`1 h) in ./Radarr.Api.V3/History/HistoryController.cs:line 85 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Extensions.RequestExtensions.ApplyToPage[TResource,TModel](PagingSpec`1 pagingSpec, Func`2 function, Converter`2 mapper) in ./Radarr.Http/Extensions/RequestExtensions.cs:line 56 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Api.V3.History.HistoryController.GetHistory(PagingRequestResource paging, Boolean includeMovie, Nullable`1 eventType, String downloadId, Int32[] movieIds, Int32[] languages, Int32[] quality) in ./Radarr.Api.V3/History/HistoryController.cs:line 85 Dec 30 00:35:11 fenrir Radarr[4381]: at lambda_method489(Closure , Object , Object[] ) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync() Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync() Dec 30 00:35:11 fenrir Radarr[4381]: --- End of stack trace from previous location --- Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() Dec 30 00:35:11 fenrir Radarr[4381]: --- End of stack trace from previous location --- Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger) Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Middleware.BufferingMiddleware.InvokeAsync(HttpContext context) in ./Radarr.Http/Middleware/BufferingMiddleware.cs:line 28 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Middleware.IfModifiedMiddleware.InvokeAsync(HttpContext context) in ./Radarr.Http/Middleware/IfModifiedMiddleware.cs:line 41 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Middleware.CacheHeaderMiddleware.InvokeAsync(HttpContext context) in ./Radarr.Http/Middleware/CacheHeaderMiddleware.cs:line 33 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Middleware.StartingUpMiddleware.InvokeAsync(HttpContext context) in ./Radarr.Http/Middleware/StartingUpMiddleware.cs:line 38 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Middleware.UrlBaseMiddleware.InvokeAsync(HttpContext context) in ./Radarr.Http/Middleware/UrlBaseMiddleware.cs:line 27 Dec 30 00:35:11 fenrir Radarr[4381]: at Radarr.Http.Middleware.VersionMiddleware.InvokeAsync(HttpContext context) in ./Radarr.Http/Middleware/VersionMiddleware.cs:line 29 Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.InvokeCore(HttpContext context) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) Dec 30 00:35:11 fenrir Radarr[4381]: at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task) Dec 30 00:35:11 fenrir Radarr[4381]: SQL: Dec 30 00:35:11 fenrir Radarr[4381]: ==== Begin Query Trace ==== Dec 30 00:35:11 fenrir Radarr[4381]: QUERY TEXT: Dec 30 00:35:11 fenrir Radarr[4381]: SELECT "History".*, "Movies".*, "QualityProfiles".* Dec 30 00:35:11 fenrir Radarr[4381]: FROM "History" Dec 30 00:35:11 fenrir Radarr[4381]: JOIN "Movies" ON ("History"."MovieId" = "Movies"."Id") Dec 30 00:35:11 fenrir Radarr[4381]: JOIN "QualityProfiles" ON ("Movies"."QualityProfileId" = "QualityProfiles"."Id") Dec 30 00:35:11 fenrir Radarr[4381]: Dec 30 00:35:11 fenrir Radarr[4381]: LEFT JOIN "MovieMetadata" ON ("Movies"."MovieMetadataId" = "MovieMetadata"."Id") Dec 30 00:35:11 fenrir Radarr[4381]: ORDER BY "Movies"."SortTitle" DESC LIMIT 20 OFFSET 0 Dec 30 00:35:11 fenrir Radarr[4381]: PARAMETERS: Dec 30 00:35:11 fenrir Radarr[4381]: ==== End Query Trace ====
I have zfs sanoid dataset snapshots of older radarr database directory contents I've not tested from march 2023 and newer. I had more but zfs send replicated the entire dataset to a different new dataset then tested some zfs rollbacks and none of the rollbacks i've yet tested did not result in an cosmetic sql query error Do you recall when radarr v5 first released? I could test one of them more easily with a date reference to ascertain if one of the 74 was a pre v5 database version.
> can we possibly try to add stable tagged ebuilds for sonarr and radarr then only stabilize Radarr.master releases? There's a process for using stable keywords: https://devmanual.gentoo.org/keywording/index.html Therefore, I can't just set KEYWORD="amd64" for some versions and KEYWORD="~amd64" for others - a version has to be in the tree for a while, then stabilization requested. So far, I've been removing old versions as new ones are added, I could leave the old ones there so they are available as candidates for stabilization. > My radarr database was "broken" by ingesting every pre-release radarr development version and the activity history in my radarr database fails to load due to an sql syntax error introduced by a buggy pre-release development build. Have you reported the issue upstream? If so, can you please link to it? If not, can you please do so and link to it? Gentoo packages software, tests it, and can triage issues, but ultimately, bugs in the software need to be reported and handled upstream for them to be fixed. > I should be more active helping maintain this as I used to in my overlay however I'm not certain what I can do. Some ideas are to submit bugs here and submit pull requests to https://github.com/gentoo/gentoo/ We can work together to make this packaging the best it can be and address issues quickly for all users. > the sonarr ebuild requires a rewrite to use the dotnet format radarr relies on to use sonarr v4 and that major version bump should stabilize the last sonarr v3 version to permit upgrade migration testing. I updated the ebuild and tested it on my system successfully. Since the upgrade is now in which fixes the problem this issue reports, let's close this issue. Please open new issues for other problems and let's keep working on improvements. Thank you!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36b42f7660c7db7b443c26780d5b8433269d7901 commit 36b42f7660c7db7b443c26780d5b8433269d7901 Author: Craig Andrews <candrews@gentoo.org> AuthorDate: 2024-01-02 16:43:37 +0000 Commit: Craig Andrews <candrews@gentoo.org> CommitDate: 2024-01-02 16:44:56 +0000 www-apps/sonarr: add 4.0.0.748 Closes: https://bugs.gentoo.org/903978 Signed-off-by: Craig Andrews <candrews@gentoo.org> www-apps/sonarr/Manifest | 3 ++ www-apps/sonarr/sonarr-4.0.0.748.ebuild | 64 +++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+)
