Вот появилась необходимость написать демона для запуска его на линухе на .net core
По простому консольная аппликуха которая внутри запускает наследника BackgroundWorker и слушает внешние очереди сообщений ну и процессит сообщения.
Т.к. это чудо ранится само по себе на AWS EC2 и никто не хочет туда заходить по RDP что бы остановить аппликуху руками по Ctrl+C то необходимо переписать это что бы апликуха ранилась как daemon и использовала SystemD
Из полезного под .NET Core нашел эту статью .NET Core and SystemD но насколько я понял
1) весь конфиг сервиса переносится из appsettings.<environment>.json в AppName.service который просто plaintext файл и не так удобен для чтения ?
2) не уверен что сигнал от SystemD сможет инициировать cancellationtoken.cancel в BackgroundWorker чтобы сигнализировать о том что нужно все красиво остановить и звершить работу?
Если у кого либо есть опыт с .NET Core + SystemD и реагирование на сигналы о старте /остановке или же кто походил по иным граблям в этом — отпишитесь пожалуйста.
Здравствуйте, Jericho113, Вы писали:
J>Если у кого либо есть опыт с .NET Core + SystemD и реагирование на сигналы о старте /остановке или же кто походил по иным граблям в этом — отпишитесь пожалуйста.
Да вроде никаких тонкостей особых. Пишешь UseSystemD у хоста и все. Можно впараллель написать UseWindowsService, тогда и на винде можно запускать.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: .net Core Linux daemon - опыт написания и грабли ?
НС>Да вроде никаких тонкостей особых. Пишешь UseSystemD у хоста и все. Можно впараллель написать UseWindowsService, тогда и на винде можно запускать.
Спасибо. Про это я понял — статью прочитал.
Т.е Linux пошлет сигнал о завершении и BackgroundService на этот сигнал вызовет CancellationTokenSource.Cancel ?
А по поводу конфигурации — обязательно ее всю запихивать в <AppName>.service текстовый файл или же можно оставить в appsettings.json и только специфичную для SystemD положить в AppName.service ?
Здравствуйте, Jericho113, Вы писали:
J>Т.е Linux пошлет сигнал о завершении и BackgroundService на этот сигнал вызовет CancellationTokenSource.Cancel ?
Да.
J>А по поводу конфигурации — обязательно ее всю запихивать в <AppName>.service текстовый файл или же можно оставить в appsettings.json и только специфичную для SystemD положить в AppName.service ?
Линуксовые только в AppName.service
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Jericho113, Вы писали:
J>>Т.е Linux пошлет сигнал о завершении и BackgroundService на этот сигнал вызовет CancellationTokenSource.Cancel ?
НС>Да.
J>>А по поводу конфигурации — обязательно ее всю запихивать в <AppName>.service текстовый файл или же можно оставить в appsettings.json и только специфичную для SystemD положить в AppName.service ?
НС>Линуксовые только в AppName.service
Честно не очень понимаю зачем переносить конфиги в AppName.service. Все отлично читается из appsettings.json главное правильно прописать WorkingDirectory.
Re: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, varenikAA, Вы писали:
AA>TPL Data Flow есть же — модель — источник — подписчик.
TPL Data Flow смотрел, имхо для меня это немного переусложнено.
AA>BackgroundWorker под Winforms заточен.
Прошу прощения, я дал ссылку на BackgroundService и указал просто некорректное название класса.
Конечно же про отличие BackgroundWorker от BackgroundService я знаю
Просто это первый раз когда я под .NET Core вообще что-либо пишу и это "что-либо" сразу же оказывается Linux сервис с интеграцией с Systemd
NetDigitally yours ....
Re[5]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, Хэлкар, Вы писали:
J>>>А по поводу конфигурации — обязательно ее всю запихивать в <AppName>.service текстовый файл или же можно оставить в appsettings.json и только специфичную для SystemD положить в AppName.service ? НС>>Линуксовые только в AppName.service
Х>Честно не очень понимаю зачем переносить конфиги в AppName.service. Все отлично читается из appsettings.json главное правильно прописать WorkingDirectory.
Я так и сделал — все что нужно Linux для запуска сервиса добавил в Appname.Service а конфигураци самой аппликухи оставил в AppSettings.<environment>.JSON
На самом деле там все немного сложнее — предполагается что этот сервис будет крутиться в докер контейнере и таких контейнеров можно будет запустить еще с десяток.
Просто раньше это была просто консольная аппликуха которая принудительно убивалась когда докер контейнер останавливался.
В виде сервиса, я предполагаю, система его остановит прежде чем остановить контейнер.
NetDigitally yours ....
Re[3]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, Jericho113, Вы писали:
J>Здравствуйте, varenikAA, Вы писали:
AA>>TPL Data Flow есть же — модель — источник — подписчик. J>TPL Data Flow смотрел, имхо для меня это немного переусложнено.
Зря, считается самой простой техникой реализации многопоточной обработки данных.
dlang (send/receive), F# (post/receive — mailbox), C# — TPL data flow. Все это родилось в эрланге.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[4]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, varenikAA, Вы писали:
J>>TPL Data Flow смотрел, имхо для меня это немного переусложнено.
AA>Зря, считается самой простой техникой реализации многопоточной обработки данных. AA>dlang (send/receive), F# (post/receive — mailbox), C# — TPL data flow. Все это родилось в эрланге.
Да, вполне возможно я ошибаюсь и просто не так глубоко копал что бы понять как это работает.
Посмотрю повнимательнее в свободное время т.к. очень часто приходится писать микросервисы с построением обработки данных
вида Producer Consumer и ручным управлением тасками и т.п. так что TPL поможет упростить это.
Спасибо.
NetDigitally yours ....
Re[4]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, varenikAA, Вы писали:
AA>Зря, считается самой простой техникой реализации многопоточной обработки данных.
BackgroundService и многопоточная обработка это не одно и тоже. Более того, скорее всего BackgroundService это однопоточная обработка, потому что ему оркестратор выделяет одно ядро, и смысла в многопоточности никакого. Многопоточность там обеспечивается на уровне оркестратора.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, varenikAA, Вы писали:
AA>>Зря, считается самой простой техникой реализации многопоточной обработки данных.
НС>BackgroundService и многопоточная обработка это не одно и тоже. Более того, скорее всего BackgroundService это однопоточная обработка, потому что ему оркестратор выделяет одно ядро, и смысла в многопоточности никакого. Многопоточность там обеспечивается на уровне оркестратора.
Не совсем понимаю почему вы связываете BackgroundService с потоками??
Это просто точка входа в сервис — ну как наследование от ServiceBase для написания виндовых сервисов в Full .NET
Единственное что требуется мне от BackgroundService это сигнал о завершении работы процесса и он это делает через CancellationToken.
А что будет уже крутиться в ExecuteAsync однопоточный код или пулл кастомных воркеров это проблемы разработчика.
NetDigitally yours ....
Re[6]: .net Core Linux daemon - опыт написания и грабли ?
J>Вот появилась необходимость написать демона для запуска его на линухе на .net core J>По простому консольная аппликуха которая внутри запускает наследника BackgroundWorker и слушает внешние очереди сообщений ну и процессит сообщения.
J>Т.к. это чудо ранится само по себе на AWS EC2 и никто не хочет туда заходить по RDP что бы остановить аппликуху руками по Ctrl+C то необходимо переписать это что бы апликуха ранилась как daemon и использовала SystemD J>Из полезного под .NET Core нашел эту статью .NET Core and SystemD но насколько я понял
J>1) весь конфиг сервиса переносится из appsettings.<environment>.json в AppName.service который просто plaintext файл и не так удобен для чтения ?
Ничего не понятно
/etc/systemd/system/AppName.service — это часть SystemD, он ортогонален asp.net core с фоновыми задачами.
Это файл делает твой консольный бинарник фоновой службой линукс которая может его запускать при старте, и уведомлять при остановке и еще много чего как и в виндос службах
это файл для админов системы. они там настройки могут задавать через переменные окружения директивой Environment
есть еще директива EnvironmentFile — там принято настройки выносить файл и отбирать права у всех не нужных.
J>2) не уверен что сигнал от SystemD сможет инициировать cancellationtoken.cancel в BackgroundWorker чтобы сигнализировать о том что нужно все красиво остановить и звершить работу?
я писал backgroundworker для линукс. все нормально там сигналится. самому на сигналы не надо подписываться — майкрософт сделал все и спрятал красиво в свежих .net core — дизпозе вызывается четко! а в дебри cancellationToken который например в startAsync передается, я дебагером не заглядывал.
J>Если у кого либо есть опыт с .NET Core + SystemD и реагирование на сигналы о старте /остановке или же кто походил по иным граблям в этом — отпишитесь пожалуйста.
Re[2]: .net Core Linux daemon - опыт написания и грабли ?
Здравствуйте, VladCore, Вы писали:
VC>я писал backgroundworker для линукс. все нормально там сигналится. самому на сигналы не надо подписываться — майкрософт сделал все и спрятал красиво в свежих .net core — дизпозе вызывается четко! а в дебри cancellationToken который например в startAsync передается, я дебагером не заглядывал.
Спасибо. Я уже разобрался как оно работает.
В докере деплоил и ранил сервис.
Сервисные настройки из .sevice подгружаются а настройки аппликухи из appsetings.json все работает.