.net Core Linux daemon - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 31.03.20 09:41
Оценка:
День добрый всем,

Вот появилась необходимость написать демона для запуска его на линухе на .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 и реагирование на сигналы о старте /остановке или же кто походил по иным граблям в этом — отпишитесь пожалуйста.

Заранее благодарен
NetDigitally yours ....
.netcore systemd
Re: .net Core Linux daemon - опыт написания и грабли ?
От: Ночной Смотрящий Россия  
Дата: 31.03.20 10:00
Оценка: 4 (1)
Здравствуйте, Jericho113, Вы писали:

J>Если у кого либо есть опыт с .NET Core + SystemD и реагирование на сигналы о старте /остановке или же кто походил по иным граблям в этом — отпишитесь пожалуйста.


Да вроде никаких тонкостей особых. Пишешь UseSystemD у хоста и все. Можно впараллель написать UseWindowsService, тогда и на винде можно запускать.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: .net Core Linux daemon - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 31.03.20 10:06
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Да вроде никаких тонкостей особых. Пишешь UseSystemD у хоста и все. Можно впараллель написать UseWindowsService, тогда и на винде можно запускать.


Спасибо. Про это я понял — статью прочитал.
Т.е Linux пошлет сигнал о завершении и BackgroundService на этот сигнал вызовет CancellationTokenSource.Cancel ?
А по поводу конфигурации — обязательно ее всю запихивать в <AppName>.service текстовый файл или же можно оставить в appsettings.json и только специфичную для SystemD положить в AppName.service ?
NetDigitally yours ....
.net core systemd
Re[3]: .net Core Linux daemon - опыт написания и грабли ?
От: Ночной Смотрящий Россия  
Дата: 31.03.20 10:10
Оценка: 78 (3)
Здравствуйте, 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 - опыт написания и грабли ?
От: Хэлкар  
Дата: 01.04.20 04:11
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, 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  
Дата: 01.04.20 06:52
Оценка:
Здравствуйте, Jericho113, Вы писали:

J>День добрый всем,

BackgroundWorker и слушает внешние очереди сообщений ну и процессит сообщения.

TPL Data Flow есть же — модель — источник — подписчик.
BackgroundWorker под Winforms заточен.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: .net Core Linux daemon - опыт написания и грабли ?
От: Ночной Смотрящий Россия  
Дата: 01.04.20 09:49
Оценка: +1
Здравствуйте, varenikAA, Вы писали:

AA>TPL Data Flow есть же — модель — источник — подписчик.

AA>BackgroundWorker под Winforms заточен.

Ты по ссылке то сходи. Там BackgroundService и он никакого отношения к винформсам не имеет.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: .net Core Linux daemon - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 01.04.20 10:07
Оценка:
Здравствуйте, 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 - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 01.04.20 10:22
Оценка:
Здравствуйте, Хэлкар, Вы писали:

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 - опыт написания и грабли ?
От: varenikAA  
Дата: 01.04.20 10:31
Оценка:
Здравствуйте, 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 - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 01.04.20 10:47
Оценка:
Здравствуйте, 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 - опыт написания и грабли ?
От: Ночной Смотрящий Россия  
Дата: 01.04.20 11:46
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>Зря, считается самой простой техникой реализации многопоточной обработки данных.


BackgroundService и многопоточная обработка это не одно и тоже. Более того, скорее всего BackgroundService это однопоточная обработка, потому что ему оркестратор выделяет одно ядро, и смысла в многопоточности никакого. Многопоточность там обеспечивается на уровне оркестратора.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: .net Core Linux daemon - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 01.04.20 12:01
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, varenikAA, Вы писали:


AA>>Зря, считается самой простой техникой реализации многопоточной обработки данных.


НС>BackgroundService и многопоточная обработка это не одно и тоже. Более того, скорее всего BackgroundService это однопоточная обработка, потому что ему оркестратор выделяет одно ядро, и смысла в многопоточности никакого. Многопоточность там обеспечивается на уровне оркестратора.


Не совсем понимаю почему вы связываете BackgroundService с потоками??
Это просто точка входа в сервис — ну как наследование от ServiceBase для написания виндовых сервисов в Full .NET
Единственное что требуется мне от BackgroundService это сигнал о завершении работы процесса и он это делает через CancellationToken.
А что будет уже крутиться в ExecuteAsync однопоточный код или пулл кастомных воркеров это проблемы разработчика.
NetDigitally yours ....
Re[6]: .net Core Linux daemon - опыт написания и грабли ?
От: Ночной Смотрящий Россия  
Дата: 01.04.20 12:40
Оценка:
Здравствуйте, Jericho113, Вы писали:

J>Не совсем понимаю почему вы связываете BackgroundService с потоками??


Это не я связываю.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: .net Core Linux daemon - опыт написания и грабли ?
От: VladCore  
Дата: 04.04.20 09:11
Оценка: 4 (1)
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 - опыт написания и грабли ?
От: Jericho113 Украина  
Дата: 05.04.20 14:29
Оценка:
Здравствуйте, VladCore, Вы писали:

VC>я писал backgroundworker для линукс. все нормально там сигналится. самому на сигналы не надо подписываться — майкрософт сделал все и спрятал красиво в свежих .net core — дизпозе вызывается четко! а в дебри cancellationToken который например в startAsync передается, я дебагером не заглядывал.


Спасибо. Я уже разобрался как оно работает.
В докере деплоил и ранил сервис.
Сервисные настройки из .sevice подгружаются а настройки аппликухи из appsetings.json все работает.
NetDigitally yours ....
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.