Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, blp, Вы писали:
S>>>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем. blp>>Потому что задача — сделать per-user сервис. S>Это не задача. Это решение. Задача в чём?
Это именно задача, которая стояла перед людьми, ее решающими. Т.е. в документе было написано что-то вроде "Task: refactor XXX services into separate processes instead of system-wide". Вы наверное, хотите спросить зачем это вообще было нужно делать — зачем нужно системным сервисам разносить функциональность по разным процессам для каждого юзера. В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д.
blp>>Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода. S>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен.
Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией)
S>Ну, ок. Допустим, аргумент про изоляцию.
Ну слава богу. А чего только "допустим"?
blp>>а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу. S>Не получается.
Ок, рассказываю: logoff предполагает, что access token юзера, который залогинен, уничтожается. Другими словами, на него никто не должен держать открытый handle. Если у вас есть процесс, который этот токен использует, то вариантов ровно два: завершить процесс принудительно (TerminateProcess,если быть совсем точным, ZwTerminatrProcess, хотя в целя данного разговора непринципиально) или сделать так, чтобы процесс сам завершился (вызвал Exit process), послав ему сигнал и дождавшись пока он корректно деинициализируется и сам завершится. Пока одно из этих двух действий не сделано, завершить logoff нельзя, по определению того, что такое logoff.
С юзерскими приложениями типа ноутпада TerminateProcess еще туда-сюда возможен — юзеру сначала показывается окошко с предложением самому разобраться что надо сделать через GUI, но если он ничего не сделает, а логофф все равно нужно делать, делается TerminateProcess.
В случае с сервисами предполагается, что они написаны так, что могут корректно деинициализироваться за известное время (иногда довольно большое) без участия юзера, TerminateProcess вызывается только тогда, когда это условие нарушается (баг в сервисе); logoff блокируется пока сервис не остановится. Cервисы, очевидно, нельзя просто прибивать.
S>Меньше думайте о людях; больше — о технических подробностях.
Все мы люди, все мы человеки.
S>Либо в Редмонде системный кризис с техдоками, либо эта версия неверна.
Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки?
S>Вот видите, как всё плохо.
Что именно плохо?
>Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить",
Нету такой задачи, потому что нету "сервиса, который мониторит XXX" — у вас изначально была совсем другая формулировка. Сформулируйте что именно вам надо перезапустить и истина откроется вам.
>вызывает какое-то извивание хребтом вместо простого ответа.
Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было.
>Для сравнения: со "старыми" сервисами такой проблемы нет — есть детерминированный способ узнать имя сервиса.
Что в лоб, что по лбу. Старые сервисы — они создаются каждый раз когда юзер залогинится? Нет? Тогда причем они тут?
blp>>Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно. S>А вот мне очень весело. Во-первых, я получаю полезные знания, а во вторых, получаю эстетическое удовольствие, глядя на то, как вы выкручиваетесь из положения, в которое сами себя загнали.
Я вижу исключительно постепенную выдачу детальной технической информации, которая с каждым постом показывает, что собеседники предметом не владеют даже в рамках способности почитать MSDN, но своё мнение у них по любому вопросу есть.
Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.
Здравствуйте, blp, Вы писали:
blp>Это именно задача, которая стояла перед людьми, ее решающими. Т.е. в документе было написано что-то вроде "Task: refactor XXX services into separate processes instead of system-wide".
Откуда вы знаете? Вообще, на таком уровне "задачи" обсуждать неинтересно. Можно точно так же написать "Task: add the userland application" и считать это хорошей идеей.
Под "задачей" лично я понимаю изменение наблюдаемых характеристик, а не внутренних способов реализации. Вот у нас Иван поставил дома прибор, который выделяет 1250 ватт мощности в воздух. Последствия очевидны — в квартире стало теплее. Не стоит сразу бросаться обличать в форуме невежество людей, задающих вопросы: прибор стоил 250000, а для решения задачи обогрева Иван мог выбрать тепловентилятор за 2500.
Правда, вентилятор не умеет майнить биткойны, а Ванин прибор — умеет. Так что критерием для выбора решения было отнюдь не повышение температуры воздуха.
blp>Вы наверное, хотите спросить зачем это вообще было нужно делать — зачем нужно системным сервисам разносить функциональность по разным процессам для каждого юзера.
Именно так, это я и хочу спросить. blp>В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д.
Это правильный подход к реверсингу инженерных решений: смотрим на характеристики решения и пытаемся угадать, какие из них были критериями выбора. Вот только всегда стоит делать следующий шаг: ок, предположим, набор критериев был вот таким. Точно ли выбранное решение является оптимальным с т.з. этих критериев? Или были другие способы получить желаемое?
Если были, то какие преимущества предлагает выбранное решение? Если преимуществ нет — то либо решение было ошибкой, либо критерии идентифицированы неверно.
S>>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен. blp>Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией)
Потому что по вашему же утверждению этих сервисов ранее не существовало. Что именно было отрефакторено?
S>>Ну, ок. Допустим, аргумент про изоляцию. blp>Ну слава богу. А чего только "допустим"?
Вот как раз потому, что теперь надо рассмотреть — а был ли способ обеспечить изоляцию? Ну, вот например — ставим задачу исполнять код сервиса под аккаунтом юзера по соображениям безопасности. Есть ли способы добиться этого в рамках "классической" модели?
Вроде бы ImpersonationTokens были изобретены сто лет назад именно для этого.
Далее — изоляция неприятностей. Тут есть несколько аспектов. Например, почему бы не потратить инвестиции в новую архитектуру в собственно QA? Это уменьшит количество багов, а не последствия каждого из них. Какая может быть причина? Типичные случаи — исполнение пользовательского кода, для которого нет гарантий качества. Тут да — архитектура может помочь сделать так, чтобы скрипты пользователя A не положили работу сервиса для пользователя B. Опять возникает вопрос: а можно ли добится этого другими способами? А исполняют ли все эти сервисы пользовательский код? Есть ли у нас перед глазами примеры других решений такой задачи?
Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему?
blp>Ок, рассказываю: logoff предполагает, что access token юзера, который залогинен, уничтожается. Другими словами, на него никто не должен держать открытый handle. Если у вас есть процесс, который этот токен использует, то вариантов ровно два: завершить процесс принудительно (TerminateProcess,если быть совсем точным, ZwTerminatrProcess, хотя в целя данного разговора непринципиально) или сделать так, чтобы процесс сам завершился (вызвал Exit process), послав ему сигнал и дождавшись пока он корректно деинициализируется и сам завершится. Пока одно из этих двух действий не сделано, завершить logoff нельзя, по определению того, что такое logoff.
Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя? Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента?
blp>Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки?
Как бы взрослые люди знают, что документация — это часть продукта. Нет документации — значит, продукт сырой, недоделанный. Архитектура в смысле дизайн предполагает не только dependency diagram между пакетами, но и всю схему взаимодействия целевой аудитории с предлагаемым решением. Вот мне крайне интересно — какими причинами продиктовано введение per-user services в экосистему винды таким образом, чтобы их разработка была недоступна простым смертным?
blp>Что именно плохо?
Плохо реализованы per-user сервисы. >>Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить", blp>Нету такой задачи, потому что нету "сервиса, который мониторит XXX" — у вас изначально была совсем другая формулировка. Сформулируйте что именно вам надо перезапустить и истина откроется вам.
У меня залипла синхронизация почты. Хочу перезапустить сервис OneSyncSvc, от которого почта зависит. Жду открытия истины — киньте скрипт на повершелле, который это сделает?
blp>Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было.
Вот прямо здесь и вижу.
blp>Что в лоб, что по лбу. Старые сервисы — они создаются каждый раз когда юзер залогинится? Нет? Тогда причем они тут?
При том, что они были нормально продуманы, в отличие от этих новых сервисов. Например, Display name и Service name специально разведены, чтобы можно было иметь локализованные имена, и всё ещё управлять сервисом при помощи одного и того же скрипта. Если бы проектировать их доверили вам, имена сервисов бы запросто получали рандомные значения при каждом запуске, а на вопросы "как узнать имя сервиса" вы бы рассказывали про Рамадан и 2019. Пример про SQL Server вы проигнорировали, а зря. Тоже ведь можно было генерировать имена сервисов при помощи псевдослучайных суффиксов, а на вопросы "как мне стартовать именованный инстанс" отвечать про Рамадан.
blp>Я вижу исключительно постепенную выдачу детальной технической информации, которая с каждым постом показывает, что собеседники предметом не владеют даже в рамках способности почитать MSDN, но своё мнение у них по любому вопросу есть.
Нам всегда интересно послушать мнение людей, полагающих себя более способных к чтению, чем другие. blp>Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.
Ну что вы, в угол вы себя загнали самостоятельно. Стокгольмский синдром и позиция "в редмонде работают божественно одарённые люди; и если они сделали per-user services, то это безусловное благо, и сомневаться в этом грех" — это ваш добровольный выбор. Теперь, даже когда вы видите косяки в реализации, признать их наличие морально тяжело.
Мой выбор — сомневаться во всём. Те же самые люди в том же редмонде разработали Скрепыша; или, из более современного — CardSpace. Как откопали — так и закопали. И ничего, мир не рухнул. Per-user services — это не первый kludge, который я наблюдаю в своей карьере.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, blp, Вы писали:
S>Под "задачей" лично я понимаю изменение наблюдаемых характеристик, а не внутренних способов реализации.
Сложно разговарвать с людьми, у которых свое собственное определение для общеупотребимых терминов. Это как с сектантами, ну или с зеками. Чуть не то слово с их точки зрения употребил (e.g. "сесть" вместо "присесть") — сразу в зубы получил. Я это плохо умею, вы уж извините.
Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать. "Наблюдаемые характеристики" могут в результате и не меняться, если у вас, скажем, доступа к коду нет и вести наблюдения вы не можете. "Рефакторинг" например — тоже задача. Впрочем в обсуждаемом случае наблюдаемыми изменениями является появление новых сервисов, так что под ваше кастомное определение оно тоже попадает.
blp>>В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д. S>Это правильный подход к реверсингу инженерных решений: смотрим на характеристики решения и пытаемся угадать, какие из них были критериями выбора. Вот только всегда стоит делать следующий шаг: ок, предположим, набор критериев был вот таким. Точно ли выбранное решение является оптимальным с т.з. этих критериев? Или были другие способы получить желаемое?
И? Какой именон вывод делаете вы? Я пока никакого анализа от собеседников на форуме не видел, кроме бития себя пяткой в грудь и предложения неработающих решений (разбивающихся о суровую реальность из того же MSDN)
S>>>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен. blp>>Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией) S>Потому что по вашему же утверждению этих сервисов ранее не существовало.
По моему собственному утрвеждению часть сервисов — результат рефакторинга. Читаем мои сообщения внимательно. >Что именно было отрефакторено?
Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы
S>>>Ну, ок. Допустим, аргумент про изоляцию. blp>>Ну слава богу. А чего только "допустим"? S>Вот как раз потому, что теперь надо рассмотреть — а был ли способ обеспечить изоляцию? Ну, вот например — ставим задачу исполнять код сервиса под аккаунтом юзера по соображениям безопасности.
Еще один. Еще можно поставить задачу нарисовать лошадку и нрисовать лошадку. Надо было не "испольнять код серивса под аккантом юзера", а иметь отдельный процесс на каждого юзера. Например, для того, чтобы краш процесса не влиял на всех юзеров сразу. например для того, чтобы в памяти одного процесса не было данных разных юзеров в случае code injection и т д
S>Далее — изоляция неприятностей. Тут есть несколько аспектов. Например, почему бы не потратить инвестиции в новую архитектуру в собственно QA?
Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи?
S>Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему?
Потому что iis никак не привязан к пользовательским логон-сессиям. Это system-wide сервис, запускающий несколько копий w3wp.exe ниак с десктопом не взаимодействующих. Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры.
S>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя?
Как запущен? ну вот реально как? что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное? ShutdownBlockReasonCreate вызывался? Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д.
попробуйте детально почитать MSDN чтобы найти дырки в вашем предложении. Мне это делать за вас уже лень, да и в некоторых местах за это платят неплохие деньги, а я тут чисто зачем-то бесплатно распинаюсь . вот — начните отсюда
Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами.
>Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента?
Опять-таки, читаем MSDN.
blp>>Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки? S>Как бы взрослые люди знают, что документация — это часть продукта. Нет документации — значит, продукт сырой, недоделанный.
А мужики-то не знают! Регулярно шипают недокументированные фичи виндов уже лет 30 как. Сырой продукт, стало быть. Недоделаный!
S>У меня залипла синхронизация почты. Хочу перезапустить сервис OneSyncSvc
Зачем? кто вам сказал, что это вам поможет? Или вы если у вас телевидор не работает, разбираете его и начинаете рандомно перепаивать? >Жду открытия истины — киньте скрипт на повершелле, который это сделает?
Не могу вам его дать Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true.
blp>>Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было. S>Вот прямо здесь и вижу.
У нас с вами какое-то очень разное восприятие. Ну ок, бывает, чо. У вас собственное определение того, что таое "задача", что уж там со всем остальным.
S>При том, что они были нормально продуманы, в отличие от этих новых сервисов. Например, Display name и Service name специально разведены, чтобы можно было иметь локализованные имена, и всё ещё управлять сервисом при помощи одного и того же скрипта.
Оооо. Что ни заявление — то просто огонь. Еще раз: раньше per-user сервисов, создающихся на запуске не было. Ваши красивые рассуждения по имена и прочее — не особо интересны. Ну да, есть у вас такое мнение. Я особо с ним не спорю.
>Если бы проектировать их доверили вам, имена сервисов бы запросто получали рандомные значения при каждом запуске, а на вопросы "как узнать имя сервиса" вы бы рассказывали про Рамадан и 2019.
Непонятно, как вы сделали такой вывод. Я вам многократно задаю вопрос, на который вы пока не ответили — сформулируйте какой именно сервис вы хотите перезапустить. Но вы упорно придумываете какие-то странные вещи. Если формулировать вопрос правильно истина откроется вам (возможно. неприятная, как с логоффами и изоляцией). Старайтесь, у вас получится.
>Пример про SQL Server вы проигнорировали, а зря.
Ничего я не проигнорировал. Я же ответил — это не per-user сервис. Причем он тут?
> Тоже ведь можно было генерировать имена сервисов при помощи псевдослучайных суффиксов, а на вопросы "как мне стартовать именованный инстанс"
Можно было. Но эти сервисы создаются людьми, которые указывают имя инстанса. per-user сервисы созаются и уничтожаются автоматически. Можете еще прикопаться к тому, что PID у процессов каждый раз разный и очень трудно процесс прибить, используя PID. Плохой дизайн, непродуманый!
S>Нам всегда интересно послушать мнение людей, полагающих себя более способных к чтению, чем другие.
Мне MSDN читать не надо — я и так все, на что ссылки давал, знаю. Потому что раньше читал, а потом код писал. И отлаживал.
blp>>Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться. S>Ну что вы, в угол вы себя загнали самостоятельно. Стокгольмский синдром и позиция "в редмонде работают божественно одарённые люди; и если они сделали per-user services, то это безусловное благо, и сомневаться в этом грех" — это ваш добровольный выбор. Теперь, даже когда вы видите косяки в реализации, признать их наличие морально тяжело.
Хоспади, ну вот опять. Какой-то стокгольмский синдром, какие-то одаренные люди из редмонда. Откуда это все лезет у вас?
S>Мой выбор — сомневаться во всём.
Последуйте этому выбору!
Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна
>Те же самые люди в том же редмонде разработали Скрепыша; или, из более современного — CardSpace.
Неа, не те же самые. У них из общих менеджеров — только Надела. Это соврешенно разные орги с разной культурой разработки и разным подходом ко всему.
>Per-user services — это не первый kludge, который я наблюдаю в своей карьере.
Ваше экспертное мнение очень важно, продолжайте вести наблюдения!
Здравствуйте, blp, Вы писали:
blp>Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать.
Простите, но с т.з. архитектуры такое понимание задачи — это уровень джуниор-девелопера. Ему сказали "написать функцию" — он написал функцию. Сказали бы "написать класс" — он бы написал класс.
blp> "Наблюдаемые характеристики" могут в результате и не меняться, если у вас, скажем, доступа к коду нет и вести наблюдения вы не можете. "Рефакторинг" например — тоже задача.
Мы в данном случае обсуждаем не рефакторинг. blp> Впрочем в обсуждаемом случае наблюдаемыми изменениями является появление новых сервисов, так что под ваше кастомное определение оно тоже попадает.
Не "наблюдаемые изменения", а "изменения интересующих параметров". Я вам пример про криптоферму уже приводил — из того, что наблюдаемыми изменениями является повышение температуры в квартире, никак не следует то, что именно оно и было целью.
Вы рассуждаете на каком-то сверхнизком уровне принятия решений — в рамках задачи "написать per-user service" задача "написать per-user service" очевидно является единственным возможным выбором.
Интересует не она, а то, откуда вообще взялась задача "написать per-user service".
blp>И? Какой именон вывод делаете вы? Я пока никакого анализа от собеседников на форуме не видел, кроме бития себя пяткой в грудь и предложения неработающих решений (разбивающихся о суровую реальность из того же MSDN)
Я, с точки зрения своего опыта работы продукт менеджером, делаю вывод о том, что была поставлена какая-то прикладная задача. При обсуждении кто-то предложил прикостылить вот эти вот per-user services.
Судя по всему, единодушной поддержки это решение не получило; его приняли с условием "ок, давайте попробуем; если окажется, что проблем создаётся больше, чем решается — откатим обратно".
Именно поэтому их не стали документировать — чтобы избежать будущих зависимостей. Собственные сервисы можно выпилить с обозримым бюджетом; бегать за неизвестным числом производителей с попытками отозвать API займёт годы.
Потому же не стали допиливать GUI — зачем это делать, если есть риск через полгода убирать всё обратно?
Теперь у нас есть три варианта развития событий:
1. Сервисы признаются приемлемым решением; недоделки доделываются.
2. Сервисы признаются неудачным решением; в очередном релизе они исчезают.
3. Никто ничего не делает, т.к. "работает — не трогай", "покажите мне business justification для предлагаемого вами изменения", "это всё понятно, но на этот релиз у нас другие приоритеты".
Наиболее вероятен третий вариант.
>>Что именно было отрефакторено? blp>Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы
Эмм, вы уверены? CDPSvc никуда не делся. Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, или его код вынесен в сервис из каких-то приложений, которые до этого бегали в пользовательской сессии?
blp>Еще один. Еще можно поставить задачу нарисовать лошадку и нрисовать лошадку. Надо было не "испольнять код серивса под аккантом юзера", а иметь отдельный процесс на каждого юзера. Например, для того, чтобы краш процесса не влиял на всех юзеров сразу. например для того, чтобы в памяти одного процесса не было данных разных юзеров в случае code injection и т д
Ещё раз: давайте всегда будем начинать с того, что вы пишете после "например, для того, чтобы". Потому что задачи типа "иметь отдельный процесс на каждого юзера" — это не задачи, это решения.
По их формулировке невозможно понять уместность решения. Например, я ставлю задачу "иметь отдельный поток под каждую пользовательскую сессию". Задача? Задача. Является ли она уместной в контексте высоконагруженного сервиса?
Как мы знаем — нет. Ну так какой смысл рассуждать в терминах стажёрских задач?
Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться. blp>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи?
Потому что объём ресурсов всегда ограничен. Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза.
S>>Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему? blp>Потому что iis никак не привязан к пользовательским логон-сессиям. Это system-wide сервис, запускающий несколько копий w3wp.exe ниак с десктопом не взаимодействующих.
Взаимодействие с десктопом тут дело десятое. Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике.
S>>Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры.
Нет там никаких костылей в ядре. Или вы костылями называете http.sys?
S>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя? blp>Как запущен? ну вот реально как?
Запущен через CreateProcessWithToken, например. blp>что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное?
Оконное приложение, которое не создаёт никаких окон.
blp>ShutdownBlockReasonCreate вызывался?
Нет, мы говорим не о шатдауне, а о logoff.
blp>Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д.
О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл.
blp>попробуйте детально почитать MSDN чтобы найти дырки в вашем предложении. Мне это делать за вас уже лень, да и в некоторых местах за это платят неплохие деньги, а я тут чисто зачем-то бесплатно распинаюсь . blp>вот — начните отсюда
Это я читал. Ничего интересного в рамках нашей дискуссии там нет. Напомню, что мы обсуждаем именно logoff — задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис. blp>Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами.
Ну, это же вы рассказываете мне, что именно сервис имеет возможность задерживать логофф, в отличие от приложения. Вот и расскажите, как именно.
"Запустить" — а в чём, собственно, проблема? CreateThread() и поехали.
>>Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента? blp>Опять-таки, читаем MSDN.
Ну, вы же уже прочитали, и уверены в том, что хорошо во всём разобрались. Если нет — так и напишите, будем вместе читать. А критика чужой квалификации без демонстрации своей — неубедительна, увы. blp>А мужики-то не знают! Регулярно шипают недокументированные фичи виндов уже лет 30 как. Сырой продукт, стало быть. Недоделаный!
Почему не знают? Конечно знают. Вы попробуйте на конференции подойти к любому сотруднику MS (кроме, естественно, маркетологов) и спросить, идеален ли их продукт. Вам каждый скажет, что у них есть бэклог толщиной в хобот мамонта на следующие релизы. И конечно все знают, что разные фичи шипятся в разных степенях готовности и проработанности.
>>Жду открытия истины — киньте скрипт на повершелле, который это сделает? blp>Не могу вам его дать
Ну, спасибо что признались. blp>Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true.
Ну как же так? Ладно, давайте остановим сервис CDPUserSvc, т.к. я не подключаю устройства, для которых он нужен. Только, пожалуйста, тот, который в моей сессии — не хочу случайно стопнуть чужой сервис.
Вы же говорите, что существующие тулзы прекрасно работают с этими новыми сервисами, так? Ну ладно, фиг с ним с настройками сервиса (которые выдают invalid parameter — см. заглавное сообщение). Но уж старт-стоп то мы должны получить на халяву, нет? Иначе не очень понятно, какие такие преимущества даёт нам запиливание этой функциональности в виде сервиса, а не обычного процесса.
blp>У нас с вами какое-то очень разное восприятие. Ну ок, бывает, чо. У вас собственное определение того, что таое "задача", что уж там со всем остальным.
Не, это как раз у вас очень собственное определение "задача". В стиле "подмети плац ломом". А что, тоже задача, не хуже других. Архитекторы системы формулируют задачи в стиле "обеспечить чистоту плаца при таких-то ограничениях". И там уже или метлой, или ломом, или спецтехникой.
blp>Оооо. Что ни заявление — то просто огонь. Еще раз: раньше per-user сервисов, создающихся на запуске не было. Ваши красивые рассуждения по имена и прочее — не особо интересны. Ну да, есть у вас такое мнение. Я особо с ним не спорю.
Во-первых, не при запуске, а при логоне. Во-вторых, понятно, что не было — непонятно, для чего они нужны. И непонятно, почему они так криво сделаны.
blp>Непонятно, как вы сделали такой вывод. Я вам многократно задаю вопрос, на который вы пока не ответили — сформулируйте какой именно сервис вы хотите перезапустить. Я же вам написал — тот экземпляр сервиса, который запущен в моей сессии. Вы продолжаете выкручиваться. blp>Ничего я не проигнорировал. Я же ответил — это не per-user сервис. Причем он тут?
При том, что он спроектирован нормально, с учётом сценариев пользователя.
blp>Можно было. Но эти сервисы создаются людьми, которые указывают имя инстанса. per-user сервисы созаются и уничтожаются автоматически. Можете еще прикопаться к тому, что PID у процессов каждый раз разный и очень трудно процесс прибить, используя PID. Плохой дизайн, непродуманый!
Дизайн приемлемый. По крайней мере, в этом дизайне предусмотрен способ опознать тот из бесчисленных firefox.exe, который мне нужен.
blp>Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна
Я и так сомневаюсь Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.
Познакомился с ними — такие же люди, как везде. В разработке — такой же бардак, как у нас. Решения — такие же, как у нас. Где-то — офигенные, где-то — слабые. А где-то вообще джуну дали реализовать, и там во все стороны верёвки торчат. Поэтому считаю совершенно нормальным обсуждать любые решения, принятые в Редмонде, не пытаясь сразу встать на позицию "раз это МС — значит это круто, даже если я не понимаю".
На всякий случай поясню: на позиции "раз винда — значит отстой" я тоже не стою.
Поэтому как раз интересно выяснить подробности — зачем вообще нужны per-user services, и являются ли они оптимальными для того, для чего позиционируются.
В MSDN про это ничего не написано. Остаётся только надеяться на то, что кто-то из евангелистов напишет таки блог про это. Либо, что на этом форуме найдутся люди, достаточно квалифицированные для обсуждения данного вопроса. В том смысле, что уже прочли MSDN вдоль и поперёк, и смогли сопоставить фрагменты документации для получения целостной картины.
Вы, вроде бы, как раз такой человек. Но почему-то всё время скатываетесь на обсуждение личности оппонентов и на задачи уровня "мне сказали запилить сервис — я запилил. Сказали бы запилить приложение — запилил бы приложение".
Вот представьте себя в роли архитектора. Вы пишете какое-то приложение для windows 10. Требования к нему формулирует product manager — в терминах прикладных сценариев. Ему вообще неважно, будет это сервис, пользовательский сервис, драйвер, или веб-страничка. В каких случях вы бы рассмотрели применение per-user service в рамках этого приложения? А в каких случаях бы решили обойтись без него?
У вас нет никакого senior architect, который примет решение за вас. Предположительно, вы настолько хорошо знаете "MSDN", что можете сами принять решение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, blp, Вы писали:
blp>>Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать. S>Простите, но с т.з. архитектуры такое понимание задачи — это уровень джуниор-девелопера. Ему сказали "написать функцию" — он написал функцию. Сказали бы "написать класс" — он бы написал класс.
Хорошо, это понимание на уровне джуниор-девелопера, но именно так процесс разработки работает в больших компаниях. Кто-то архитектурит, рождает список задач, и эти задачи потом решаются. А не меняются, как удобнее в задачи "нарисовать лошадку".
S>Вы рассуждаете на каком-то сверхнизком уровне принятия решений — в рамках задачи "написать per-user service" задача "написать per-user service" очевидно является единственным возможным выбором. S>Интересует не она, а то, откуда вообще взялась задача "написать per-user service".
Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение.
S>Я, с точки зрения своего опыта работы продукт менеджером, делаю вывод о том, что была поставлена какая-то прикладная задача. При обсуждении кто-то предложил прикостылить вот эти вот per-user services.
Ну то есть опять ваши субьективные оценки сверху. "Прикостылить" и т д. Неинтересно. Было бы интересно, если бы вы сами спроектировали какую-нибудь подсистему ОС.
S>Судя по всему, единодушной поддержки это решение не получило; его приняли с условием "ок, давайте попробуем; если окажется, что проблем создаётся больше, чем решается — откатим обратно".
Судя по чему именно?
>>>Что именно было отрефакторено? blp>>Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы S>Эмм, вы уверены?
Да. Только умоляю, не спрашивайте, почему. Я уже устал объяснять очевидные вещи.
>CDPSvc никуда не делся.
А он должен был?
>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc,
Да.
> или его код вынесен в сервис из каких-то приложений, которые до этого бегали в пользовательской сессии?
Не понял, какие еще приложения? Раньше был просто CDPSvc
S>Как мы знаем — нет. Ну так какой смысл рассуждать в терминах стажёрских задач?
Давайте я вам анекдот расскажу.
Международный съезд пивоваров. После напряженного рабочего дня директора крупнейших пивоварен мира тусуются в баре.
Директор Бадвайзера громко, чтобы все слышали, заказывает:
— Дайте мне любимый напиток каждого американца, жажду утоляющий, легко пьющийся в любое время дня, прозрачный как слеза ребенка — БАД ЛАЙТ!!
Ему наливают, он сидит и потягивает Бад с блаженным видом.
Директор Короны прочищает горло, и тоже:
— Дайте мне гордость всей Мексики, древнейший напиток цивилизованного человека, ароматную, янтарную, восхитительную КОРОНУ!!
Получает, начинает смаковать, а сам давит косяка на директора Гиннеса — как, мол, тот выпендрится.
— А мне, любезнейший, стакан Кока Колы, — говорит директор Гиннеса.
Ему наливают, и он с наслаждением высасывает охлажденную шипучку. Все в шоке.
Директор Короны спрашивает, почему он не заказал Гиннес.
— Дык, из солидарности, — отвечает директор Гиннеса. — Вы пиво не пьете, так что же я буду?
я общаюсь на уровне собеседников.
S>Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться.
Где писали? Дайте ссылку, пожалуйста, я, видимо, пропустил.
blp>>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи? S>Потому что объём ресурсов всегда ограничен.
Вы вообще в курсе как бюджеты в МС планируются? Например, в курсе ли вы что QA и разработка не имеют общего бюджета? Что у них нет общего "менеджера"? Что "тестирование" виндовса это совсем не то, что вы думаете?
>Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза.
В рамках аутсорсинговой компании эта логика работает. В рамках корпорации вроде МСа, релизящего ОС на миллиарды машин — нет.
S>Взаимодействие с десктопом тут дело десятое.
Это почему? Потому что вам так удобнее?
> Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике.
Ну можно было. Только не нужно было. Я же сказал — они не per-user logon session. Там проблемы совсем другие и решаются они по-другому.
S>>>Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры. S>Нет там никаких костылей в ядре. Говорит нам эксперт по виндовому ядру, знающий его вдоль и поперек?
Есть они, как раз те самые недокументированные. Начать хотя бы с того, как SSL реализован в обход красивой архитектуры с lsass.exe и LPC.
S>>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя? blp>>Как запущен? ну вот реально как? S>Запущен через CreateProcessWithToken, например.
О мама-миа... Где вы токен возьмете? Только не говорите про LogonUser — пароля юзера у вас нет.
blp>>что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное? S>Оконное приложение, которое не создаёт никаких окон.
Ну вот про него в MSDN вполе подробно написано.
blp>>ShutdownBlockReasonCreate вызывался? S>Нет, мы говорим не о шатдауне, а о logoff.
Они с точки зрения поведения системы при завершении приложений во многом совпадают, в MSDN отдельно логофф не описывается, это часть того, что называется "шатдаун". Он просто разный бывает. Читать MSDN все-таки придется, если хотите разобраться.
blp>>Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д. S>О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл.
Это называется "тип шатдауна". Как такового понятия "логофф" с точки зрения "приложения" нет — ему говорят что "надо бы завершиться" либо надо завершится "прямщаз". В статье что я привел это вполне подробно описывается. Оттуда интересующие вещи можно детально поискать — ENDSESSION_CRITICAL там и все такое.
S>Это я читал. Ничего интересного в рамках нашей дискуссии там нет.
Есть.
>Напомню, что мы обсуждаем именно logoff
В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l
>- задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис.
На колу мочало... Вам надо задержать логофф чтобы ваши системные процессы не прибились и корректно деинициализировались — как именно вы это сделаете без серивсов, так чтобы юзер не мог на это повлиять? Я думал, что один раз спросить будет достаточно, но вот приходится повторять...
blp>>Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами. S>Ну, это же вы рассказываете мне, что именно сервис имеет возможность задерживать логофф, в отличие от приложения. Вот и расскажите, как именно.
Я уже все рассказал и даже ссылки в MSDN показал. Вы увидели там слово "shutdown" и почему-то решили, что их читать не надо.
S>"Запустить" — а в чём, собственно, проблема? CreateThread() и поехали.
Никаких проблем. "Все отнять и поделить" (с) Шариков.
S>Ну, вы же уже прочитали, и уверены в том, что хорошо во всём разобрались. Если нет — так и напишите, будем вместе читать. А критика чужой квалификации без демонстрации своей — неубедительна, увы.
Печально, чо. Я за вас MSDN читать не буду. Приведенных мною ссылок и комментариев вполне достаточно, чтобы понять, что я имею в виду. Sapienti sat.
blp>>Не могу вам его дать S>Ну, спасибо что признались.
Не за что, обращайтесь!
blp>>Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true. S>Ну как же так?
Ну правда — нету его. Нету сервиса, который так называется.
>Ладно, давайте остановим сервис CDPUserSvc, т.к. я не подключаю устройства, для которых он нужен.
и сервиса CDPUserSvc тоже нет.
>Только, пожалуйста, тот, который в моей сессии — не хочу случайно стопнуть чужой сервис.
Да сколько можно!
S>Вы же говорите, что существующие тулзы прекрасно работают с этими новыми сервисами, так?
Дв, прекрасно работают.
>Ну ладно, фиг с ним с настройками сервиса (которые выдают invalid parameter — см. заглавное сообщение). Но уж старт-стоп то мы должны получить на халяву, нет? Иначе не очень понятно, какие такие преимущества даёт нам запиливание этой функциональности в виде сервиса, а не обычного процесса.
start-stop вы получаете нахаляву. Надо просто правильно формулировать, что вам блин надо запустить или остановить.
Для этого надо перестать требовать себе розового пони и сформулировать вопрос в терминах, в которых работают тулы. Тулам нужно указать имя сервиса. Надо напрячься и подумать, как получить это имя по критериям, которые вам нужны. Для начала эти самые критерии сформулировать. Это это все сложно и скучно, давайте какашками кидаться!
Я включу телепата, ибо мне надоело, но больше я это делать не буду.
"который в моей сессии" — что блин за ваша сессия, их может быть много. Есть terminal services, есть powershell remoting.
Ну ладно, допустим вы запустили qwinsta и видите там что-то вот такое:
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
1 Down
>console ВАШ ЛОГИН 3 Active
7a78855482a04... 65536 Listen
дальше делаем net stop CDPUserSvc_180c2626 / net start CDPUserSvc_180c2626.
Как сделать это на павершелле оставлю как самостоятельное упражнение.
blp>>Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна S>Я и так сомневаюсь
нет, вы ведете себя так, как будто лучше знаете что и как проектировать. Сыпите терминами вроде kludge, "кривой", "приемлемый дизайн" и т. д.
>Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.
Зачем во что-то "верить"? Почему нельзя просто логически мыслить?
S>Познакомился с ними — такие же люди, как везде. В разработке — такой же бардак, как у нас. Решения — такие же, как у нас. Где-то — офигенные, где-то — слабые. А где-то вообще джуну дали реализовать, и там во все стороны верёвки торчат. Поэтому считаю совершенно нормальным обсуждать любые решения, принятые в Редмонде, не пытаясь сразу встать на позицию "раз это МС — значит это круто, даже если я не понимаю".
Отличие в том, что я как раз понимаю. Не понимают тут собеседники, которые сходу кидаются утверждать, что если им что-то непонятно или для них что-то выглядит странным, это "костыль", "плохой дизайн", "криворуки обеьяны" и т д
S>Поэтому как раз интересно выяснить подробности — зачем вообще нужны per-user services, и являются ли они оптимальными для того, для чего позиционируются.
Не знаю, как вы определяете "оптимальность", обьяснения, зачем там именно сервисы, я уже привел. Придется напрячься и почитать MSDN, по-другому никак.
S>В MSDN про это ничего не написано.
В MSDN много чего про это и не про это написано. Даже слишком много. Не все хотят его читать. Некоторые ещё, видимо, не могут.
>Остаётся только надеяться на то, что кто-то из евангелистов напишет таки блог про это.
Маловероятно. Этих "евангелистов" подразогнали в рамках недавних увольнений. Толку от них мало было.
S>Вы, вроде бы, как раз такой человек. Но почему-то всё время скатываетесь на обсуждение личности оппонентов
Ну характер у меня такой. Когда собеседники сходу начинают шариковское "не согласен я!" и бросаться словами типа "костыль", попутно демонстрируя полное непонимание ряда вполне себе документиованных особенностей винды, невозможно не поязвить.
Здравствуйте, blp, Вы писали: blp>Хорошо, это понимание на уровне джуниор-девелопера, но именно так процесс разработки работает в больших компаниях. Кто-то архитектурит, рождает список задач, и эти задачи потом решаются. А не меняются, как удобнее в задачи "нарисовать лошадку".
Ну вот мне и интересно поговорить с точки зрения того, кто архитектурит. А не с точки зрения того, кто заполняет шаблон класса кодом по образцу.
blp>Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение.
Отлично. Почему не устроила изоляция при помощи worker process, как это сделано в IIS? Почему все эти процессы надо было оформлять именно как сервисы? Ну, и по-прежнему непонятно, как это повлияет на количество крэшей.
Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю.
blp>Ну то есть опять ваши субьективные оценки сверху. "Прикостылить" и т д. Неинтересно. Было бы интересно, если бы вы сами спроектировали какую-нибудь подсистему ОС.
Да, было бы интересно.
blp>Судя по чему именно?
Судя по тому, что документацию и инструменты было решено не доделывать.
S>>Эмм, вы уверены? blp>Да. Только умоляю, не спрашивайте, почему. Я уже устал объяснять очевидные вещи.
Как раз это — совсем не очевидные вещи.
Давайте, рассказывайте.
>>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, blp>Да.
Можете раскрыть источник своей уверенности?
blp>Не понял, какие еще приложения? Раньше был просто CDPSvc
Ну, я не знаю — может быть были. Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей?
blp>я общаюсь на уровне собеседников.
Не, вы лучше на своём уровне общайтесь.
S>>Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться. blp>Где писали? Дайте ссылку, пожалуйста, я, видимо, пропустил.
Цитирую:
Далее — изоляция неприятностей. Тут есть несколько аспектов. Например, почему бы не потратить инвестиции в новую архитектуру в собственно QA? Это уменьшит количество багов, а не последствия каждого из них. Какая может быть причина? Типичные случаи — исполнение пользовательского кода, для которого нет гарантий качества. Тут да — архитектура может помочь сделать так, чтобы скрипты пользователя A не положили работу сервиса для пользователя B. Опять возникает вопрос: а можно ли добится этого другими способами? А исполняют ли все эти сервисы пользовательский код? Есть ли у нас перед глазами примеры других решений такой задачи?
blp>>>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи? S>>Потому что объём ресурсов всегда ограничен. blp>Вы вообще в курсе как бюджеты в МС планируются? Например, в курсе ли вы что QA и разработка не имеют общего бюджета? Что у них нет общего "менеджера"? Что "тестирование" виндовса это совсем не то, что вы думаете?
Нет, не в курсе. Ну, то есть те части продукции Microsoft, которые наблюдаю лично я, вообще в последние годы никакого QA не проходят. Это видно по тому, как в публичный API уезжают баги, которые должы были быть отловлены любым автотестом. Мы узнаём о них потому, что у нас (в отличие от Microsoft) есть набор автоматизированных тестов того API, который нас интересует.
А в те времена, когда я активно интересовался процессом разработки в Редмонде (коллеги собеседовались и уезжали), вообще не было деления на QA и Dev; а были инженеры, которые типа должны делать и то и другое.
Поэтому ситуация, когда кто-то принимает решение потратить +$100K на R&D, чтобы снизить количество крэшей, но при этом не готов выделить $100K на QA, который бы эти крэши предотвратил, мне не понятна.
Если у вас есть какая-то инсайдерская инфа — делитесь, это как раз интересно.
>>Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза. blp>В рамках аутсорсинговой компании эта логика работает. В рамках корпорации вроде МСа, релизящего ОС на миллиарды машин — нет.
Вы что-то путаете. Как раз в рамках аутсорсинговой компании решения о том, что релизить, принимает заказчик. Я как бы отработал свой срок в аутсорсинговой компании
И в компании, которая релизит свои продукты — тоже. И у нас в компании бывших сотрудников МС поработало тоже в ассортименте, так что "лучшие практики" оттуда к нам внедряли.
blp>Это почему? Потому что вам так удобнее?
Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом.
>> Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике. blp>Ну можно было. Только не нужно было. Я же сказал — они не per-user logon session. Там проблемы совсем другие и решаются они по-другому.
А в чём специфика проблем per-user-logon-session? И почему надо было именно per user logon session, а не per user? Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано?
blp> Говорит нам эксперт по виндовому ядру, знающий его вдоль и поперек? blp>Есть они, как раз те самые недокументированные. Начать хотя бы с того, как SSL реализован в обход красивой архитектуры с lsass.exe и LPC.
S>>>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя? blp>>>Как запущен? ну вот реально как? S>>Запущен через CreateProcessWithToken, например. blp>О мама-миа... Где вы токен возьмете? Только не говорите про LogonUser — пароля юзера у вас нет.
Хороший вопрос. А где берётся токен для per-user service?
S>>Оконное приложение, которое не создаёт никаких окон. blp>Ну вот про него в MSDN вполе подробно написано.
В као blp>>>ShutdownBlockReasonCreate вызывался? S>>Нет, мы говорим не о шатдауне, а о logoff. blp>Они с точки зрения поведения системы при завершении приложений во многом совпадают, в MSDN отдельно логофф не описывается, это часть того, что называется "шатдаун". Он просто разный бывает.
Ну, на мой взгляд шатдаун радикально отличается тем, что при нём из-под нас исчезают ресурсы. То есть если я, скажем, не успел сбросить буфера на диск до пропадания питания, то они будут потеряны.
Понятно, что правильнее писать код так, чтобы внеплановый шатдаун не поломал структуру данных (и это не rocket science), но уж если не удалось — то да, шатдаун нужно задерживать как раз для того, чтобы успеть записать данные на диск.
А с логоффом-то что не так? Грубо говоря, если у меня бежит обычное приложение в рамках пользовательской сессии, и ему намекают про WM_QUERYENDSESSION, то нужно по-быстрому отдать данные сервису (а это можно сделать _очень_ быстро, даже если этих данных там гигабайт), и быть готовым к WM_ENDSESSION/WM_CLOSE. Пусть пользователь себе логоффится, а записью данных будет заниматься сервис, которому пользовательская сессия не нужна.
Вот когда у нас приедет шатдаун, то этот наш сервис как раз имеет возможность сказать "погоди, у меня тут ещё уникальные гигабайты не записаны".
Вроде всё норм. А вот зачем задерживать именно логофф — тут я не понимаю. Как, впрочем, не понимаю, какими средствами это можно сделать в рамках хоть приложения, хоть сервиса.
blp>Читать MSDN все-таки придется, если хотите разобраться.
Ок, где именно читать?
S>>О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл. blp>Это называется "тип шатдауна". Как такового понятия "логофф" с точки зрения "приложения" нет — ему говорят что "надо бы завершиться" либо надо завершится "прямщаз". В статье что я привел это вполне подробно описывается. Оттуда интересующие вещи можно детально поискать — ENDSESSION_CRITICAL там и все такое.
Тогда о чём вообще вы говорили в рамках идеи задержать логофф? Вы же хотите именно логофф задерживать — как это делается?
>>Напомню, что мы обсуждаем именно logoff blp>В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l
По ссылке написано, что приложение не может отличит логофф от шатдауна.
>>- задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис. blp>На колу мочало... Вам надо задержать логофф чтобы ваши системные процессы не прибились и корректно деинициализировались — как именно вы это сделаете без серивсов, так чтобы юзер не мог на это повлиять? Я думал, что один раз спросить будет достаточно, но вот приходится повторять...
Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы?
blp>Я уже все рассказал и даже ссылки в MSDN показал. Вы увидели там слово "shutdown" и почему-то решили, что их читать не надо.
Почему же не надо? Я всё прочитал. Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли". Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии — его надо переносить в классический сервис, и пусть он заканчивает критический код, не запрещая пользователю делать logoff.
blp>Никаких проблем. "Все отнять и поделить" (с) Шариков.
Ну, в MSDN написано именно так .
blp>Печально, чо. Я за вас MSDN читать не буду. Приведенных мною ссылок и комментариев вполне достаточно, чтобы понять, что я имею в виду. Sapienti sat.
Ок, жаль. А только было началось что-то интересное.
blp>Ну правда — нету его. Нету сервиса, который так называется.
blp>Да сколько можно!
Столько, сколько нужно.
>>Ну ладно, фиг с ним с настройками сервиса (которые выдают invalid parameter — см. заглавное сообщение). Но уж старт-стоп то мы должны получить на халяву, нет? Иначе не очень понятно, какие такие преимущества даёт нам запиливание этой функциональности в виде сервиса, а не обычного процесса. blp>start-stop вы получаете нахаляву. Надо просто правильно формулировать, что вам блин надо запустить или остановить. blp>Для этого надо перестать требовать себе розового пони и сформулировать вопрос в терминах, в которых работают тулы.
blp>Я включу телепата, ибо мне надоело, но больше я это делать не буду. blp>"который в моей сессии" — что блин за ваша сессия, их может быть много. Есть terminal services, есть powershell remoting. blp>Ну ладно, допустим вы запустили qwinsta и видите там что-то вот такое:
blp>
blp> SESSIONNAME USERNAME ID STATE TYPE DEVICE
blp> services 0 Disc
blp> 1 Down
>>console ВАШ ЛОГИН 3 Active
blp> 7a78855482a04... 65536 Listen
blp>
blp>из чего делаем вывод, что session id у нас 3
blp>делаем blp>
blp>дальше делаем net stop CDPUserSvc_180c2626 / net start CDPUserSvc_180c2626.
blp>Как сделать это на павершелле оставлю как самостоятельное упражнение.
Ну вот видите — можете же, когда захотите! Немножечко отполировать — и можно в продакшн.
Если уж вас потянуло на откровенность — расскажите, почему не стали именовать сервисы в стиле CDPUserSvc$3 — ведь их же ровно 1 на сессию, конфликта имён не будет. Зато угадывать имена сервисов стало бы проще, можно обойтись без tasklist, одним qwinsta.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот мне и интересно поговорить с точки зрения того, кто архитектурит.
Да оно понятно. Все хотят говорить про архитектуру, тольку уровень "разговоров" все равно на уровне джуниоров, которым ничего архитектурить не дают.
lp>>Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение. S>Отлично. Почему не устроила изоляция при помощи worker process, как это сделано в IIS? Почему все эти процессы надо было оформлять именно как сервисы?
Я уже это объяснял, но вы не поняли. Не "не устроила изоляция при помощи worker process" — системный код просто нельзя запихать в просто приложения, чтобы он корректно стартовал и деинициализировался при логоне-логоффе. Ваши попытки сформулировтаь, как именно это сделать, приводили пока либо
— к решению другой задачи (рисовать лошадку) — per-user стейт держать в одном процессе-сервисе, а не process per user session — прямо противоречит изоляции по процессам
— к предложению просто неработающих решений на базе приложений, которые будут "как-то" запускаться при логоне и "как-то" потом завершаться — когда были заданы детальные вопросы, вы на них не ответили.
> Ну, и по-прежнему непонятно, как это повлияет на количество крэшей.
Ну, непонятно так непонятно. Жизнь-боль и т. д.
S>Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю.
Вместе с CDPSvc будут потенциально крашиться зависящие от него процессы. Не только Васи, но и у Пети, сидящем на той же машине по RDP.
После рефакторинга никто, кроме Васи зааффекчен не будет (если ситуация, приводящая к крашу, возникает в коде. который выполняется для Васи).
Ну хоть немного головой думать надо...
>>>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, blp>>Да. S>Можете раскрыть источник своей уверенности?
Little birdie told me.
blp>>Не понял, какие еще приложения? Раньше был просто CDPSvc S>Ну, я не знаю
Ну вот вы не знаете, но зачем-то какую-то чушь порете и потом просите что-то вам доказывать и детально разжевывать, объясняя, почему то чушь. Это до какой-то степени забавно, но я уже устал.
>Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей?
Предлагаю самостоятельно попробовать найти ответ на этот вопрос. Это не сложно. Начните с вопроса "А взаимодействовует ли сейчас CDPUserSvc с десктопами пользователей?"
blp>>я общаюсь на уровне собеседников. S>Не, вы лучше на своём уровне общайтесь.
На более высоком уровне имеет смысл общаться с людьми, которые
— сами хорошо разбираются в предмете
— в состоянии хорошо в нем разобраться после указания на доступные материалы
— задают интересные и оригинальные вопросы
ничего из вышеописанного не происходит, увы.
Серьезно заниматься тут просвещением ширнармасс и борьбой с религиознвым мракобесием можно только за деньги =)
S>Цитирую:
Здесь нет ничего конкретного. На последующий вопрос как именно вы будете без сервисов процессы запускать и трекать на каждый логин логофф вы ничего путного не ответили. "Сделаем как в iis " не ответ потому что в iis не надо делать per-session. А если делать один большой сервис, то это решение другой задачи, изоляции не будет.
S>Нет, не в курсе. Ну, то есть те части продукции Microsoft, которые наблюдаю лично я
О, что наблюдаете лично вы это несомненно очень важно. Может, вы смотрите на какой-нибудь адов продукт типа шарепоинта. Как это относится к разработке центральных компонентов ОС, сервисов и т д — неведомо. Автотесты на API у них какие-то. Какой API, где документирован, сколько человек его использует...
S>Если у вас есть какая-то инсайдерская инфа — делитесь, это как раз интересно.
Может и интересно, только не в коня корм. Думаю, не стоит, да и нельзя наверное.
\blp>>Это почему? Потому что вам так удобнее? S>Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом.
Мы с самого начала обсуждаем как сделать чтобы системный код был изолирован per-user-logon-session. Срач начался с "чем это лучше чем таски или банальный авторан?"
Вы зачем-то привели нерелеватный пример iis, который просто создает w3wp процессы, никак к логон сессям не привязанные. Если бы надо было создавать несколько процессов, никак не привязаных к циклу логина — логоффа — оно было бы релеватно хоть как-то.
S>А в чём специфика проблем per-user-logon-session?
Зачем вы меня спрашиваете? Себя спросите.
> И почему надо было именно per user logon session, а не per user?
Потому что жизнь такая
>Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано?
Зависит от многих факторов. Multiple different RDP sessions per user вполне возможны. HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" fSingleSessionPerUser -> 0 и т д
S>Хороший вопрос. А где берётся токен для per-user service?
Где же он действительно берется? Задайте себе еще более интересный вопрос — где берется токен, под которым запускаются вообще все юзерские приложения, explorer.exe там и т д. Где берется токен, используемый для per-user сервисов?
S>>>Нет, мы говорим не о шатдауне, а о logoff.
Вы просто говорите о вещах, в которых не разбираетесь.
S>Ну, на мой взгляд шатдаун радикально отличается тем
Кого волнует, чемони на ваш взгляд отличаются
S>А с логоффом-то что не так?
Логофф — это такой тип шатдауна.
> Грубо говоря, если у меня бежит обычное приложение в рамках пользовательской сессии, и ему намекают про WM_QUERYENDSESSION, то нужно по-быстрому отдать данные сервису (а это можно сделать _очень_ быстро, даже если этих данных там гигабайт), и быть готовым к WM_ENDSESSION/WM_CLOSE. Пусть пользователь себе логоффится, а записью данных будет заниматься сервис, которому пользовательская сессия не нужна.
Да, давайте опять сделаем центральный сервис вместо того, чтобы изолировать процессы разный логон-сессий. Потому что цикровая лошать умеет только бегать по кругу. Мне уже надоело по третьему разу это комментировать.
S>Вроде всё норм. А вот зачем задерживать именно логофф — тут я не понимаю. Как, впрочем, не понимаю, какими средствами это можно сделать в рамках хоть приложения, хоть сервиса.
Ну, не понимаете, так не понимаете. Что ж тут поделать. Ссылки я давал — перечитайте мои ответы со ссылками и содержимое ссылок — может, поможет, не знаю. Второй раз разжевывать я не буду. Sapienti sat.
blp>>Читать MSDN все-таки придется, если хотите разобраться. S>Ок, где именно читать?
S>Тогда о чём вообще вы говорили в рамках идеи задержать логофф? Вы же хотите именно логофф задерживать — как это делается?
при логоффе per-user-session сервисы останавливаются, после того, как завершены все приложения, относящиеся к сессии.
Пока сервисы не остановятся, логофф не заканчивается.
Таймаут на свою остановку сервис определяет сам, и он может быть довольно большим (3 минуты по умолчанию). Если бы вы читали ссылки, что я даю, вы бы это и так знали.
>>>Напомню, что мы обсуждаем именно logoff blp>>В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l S>По ссылке написано, что приложение не может отличит логофф от шатдауна.
Ага. В голове ничего не щелкнуло?
S>Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы?
Потому что у вас системный процесс со временем жизни в юзерскую логон-сессию? Для изоляции, помните?
S>Почему же не надо? Я всё прочитал.
Ну значит прочитали и не поняли.
>Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли".
А таймаут остановки сервиса определяете самим сервисом. Улавливаете?
> Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии
Ну не видите и не видите. Конечно, то, чего вы не видите, не существует.
blp>>Никаких проблем. "Все отнять и поделить" (с) Шариков. S>Ну, в MSDN написано именно так .
Нет, в MSDN так не написано.
S>Ок, жаль. А только было началось что-то интересное.
Се ля ви.
S>Если уж вас потянуло на откровенность — расскажите, почему не стали именовать сервисы в стиле CDPUserSvc$3 — ведь их же ровно 1 на сессию, конфликта имён не будет. Зато угадывать имена сервисов стало бы проще, можно обойтись без tasklist, одним qwinsta.
Потому что LUID в имени сервиса — гарантированно уникальный на каждый логон эвент на все время, пока машину не перезагрузят, а session id может переиспользоваться в ряде случаев.
Здравствуйте, blp, Вы писали:
blp>Я уже это объяснял, но вы не поняли. Не "не устроила изоляция при помощи worker process" — системный код просто нельзя запихать в просто приложения, чтобы он корректно стартовал и деинициализировался при логоне-логоффе.
Мы ходим по кругу. "Зачем деинциализироваться при логоффе" — "Потому что все процессы в сессии будут убиты". "А зачем вам тащить пользовательские процессы в сессию" — "чтобы они прибивались при логоффе".
Может, как-то выйдем из режима кольцевого обоснования?
blp>- к решению другой задачи (рисовать лошадку) — per-user стейт держать в одном процессе-сервисе, а не process per user session — прямо противоречит изоляции по процессам
Почему в одном-то? Сколько надо, столько и запустим. blp>- к предложению просто неработающих решений на базе приложений, которые будут "как-то" запускаться при логоне и "как-то" потом завершаться — когда были заданы детальные вопросы, вы на них не ответили.
А зачем задавать риторические вопросы? Вот у меня при логоне стартует большая пачка приложений. Есть N+1 способ их стартовать.
Что делать при шатдауне мы уже обсудили — вы мне минимум трижды привели ссылку на статью, в которой подробно написано, как приложение должно реагировать на закрытие сессии.
S>>Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю. blp>Вместе с CDPSvc будут потенциально крашиться зависящие от него процессы.
Потенциально зависящие? А то в зависимостях от CDPSvc ничего не прописано. blp>Не только Васи, но и у Пети, сидящем на той же машине по RDP. blp>После рефакторинга никто, кроме Васи зааффекчен не будет (если ситуация, приводящая к крашу, возникает в коде. который выполняется для Васи). blp>Ну хоть немного головой думать надо...
Конечно надо. Например, надо отличать количество крэшей от их объёма. Вы зачем-то пишете про количество, вместо того, чтобы писать про область поражения.
S>>Можете раскрыть источник своей уверенности? blp>Little birdie told me.
Вы либо рассказывайте, либо нет. А вот это вот "есть секретная информация, но я вам её не скажу" — фу-фу-фу.
blp>Ну вот вы не знаете, но зачем-то какую-то чушь порете и потом просите что-то вам доказывать и детально разжевывать, объясняя, почему то чушь. Это до какой-то степени забавно, но я уже устал.
Я задаю вопросы. А вы с таинственным и пренебрежительным видом от них отмахиваетесь.
>>Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей? blp>Предлагаю самостоятельно попробовать найти ответ на этот вопрос. Это не сложно. Начните с вопроса "А взаимодействовует ли сейчас CDPUserSvc с десктопами пользователей?"
Я не знаю. В MSDN про это не написано.
blp>Здесь нет ничего конкретного.
Здесь есть вопросы, которые вы проигнорировали. Попробую разжевать помедленнее, чтобы вам было понятно. Итак, вот у нас валится какой-то код. Почему он валится? При наличии телеметрии и крэш дампов это должно быть выясняемо. Людей, которые хотели заниматься разработкой per-user services, сажаем разбирать крэш дампы и чинить нарушения инвариантов.
Этот вариант не работает в том случае, если крэшится не наш код. Это как раз случай IIS — там криворукие веб-девелоперы потенциально могут любую дрянь пытаться выполнять. Поэтому разумный способ — запускать эту дрянь в отдельном процессе. Ровно для ограничения границ катастрофы (а никак не для снижения её частоты).
Отсюда возникают вопросы: а есть ли вообще "неотлаживаемый" код в этих процессах? Если есть — то всё понятно, ок, решение обосновано. Если нет — то возвращаемся к вопросу "почему бы не починить баги, вместо того, чтобы их замазывать"?
blp>На последующий вопрос как именно вы будете без сервисов процессы запускать и трекать на каждый логин логофф вы ничего путного не ответили. "Сделаем как в iis " не ответ потому что в iis не надо делать per-session. А если делать один большой сервис, то это решение другой задачи, изоляции не будет.
Почему же "без сервисов"? В рамках классического system-wide сервиса: https://docs.microsoft.com/en-us/windows/win32/services/receiving-events-in-a-service
А вообще, пишут что вроде бы можно просто подписаться на события SERVICE_CONTROL_SESSIONCHANGE.
blp>О, что наблюдаете лично вы это несомненно очень важно. Может, вы смотрите на какой-нибудь адов продукт типа шарепоинта. Как это относится к разработке центральных компонентов ОС, сервисов и т д — неведомо. Автотесты на API у них какие-то. Какой API, где документирован, сколько человек его использует...
Давайте не будем отвлекаться от per-user services.
blp>Может и интересно, только не в коня корм. Думаю, не стоит, да и нельзя наверное.
Ну, тогда наверное лучше дискуссию завершить. Ничего полезного вы рассказать не хотите, а жаль.
S>>Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом. blp>Мы с самого начала обсуждаем как сделать чтобы системный код был изолирован per-user-logon-session. Срач начался с "чем это лучше чем таски или банальный авторан?"
Да, и несмотря на три десятка сообщений в ветке простые вопросы так и не были отвечены:
1. зачем было принято решение изолировать системный код для каждой сессии.
2. Было ли порождение сервисов по шаблону наилучшим решением данной задачи
3. Почему было принято решение не документировать разработку таких сервисов
>> И почему надо было именно per user logon session, а не per user? blp>Потому что жизнь такая
Ну, опять. "начальник сказал — мы сделали". Вот как раз это — скучно.
>>Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано? blp>Зависит от многих факторов. Multiple different RDP sessions per user вполне возможны. HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" fSingleSessionPerUser -> 0 и т д
Я знаю. Так сервисов будет много или один? Судя по вашим отдельным намёкам, их будет несколько. То есть per-user тут как бы неверное название, надо бы называть per-session service.
blp>Где же он действительно берется? Задайте себе еще более интересный вопрос — где берется токен, под которым запускаются вообще все юзерские приложения, explorer.exe там и т д.
Большинство юзерских приложений наследуют токен родительского процесса.
blp>Где берется токен, используемый для per-user сервисов?
Ну так вы же эксперт, разве нет? Вот и расскажите. В MSDN про это ничего нету.
Заодно расскажите, почему нельзя выполнять эту работу под системным аккаунтом.
blp>Вы просто говорите о вещах, в которых не разбираетесь.
Конечно. Нельзя же всё время говорить только о вещах, в которых я разбираюсь — так я не узнаю ничего нового.
blp>Да, давайте опять сделаем центральный сервис вместо того, чтобы изолировать процессы разный логон-сессий. Потому что цикровая лошать умеет только бегать по кругу. Мне уже надоело по третьему разу это комментировать.
Ну, так объясняете, значит.
blp>при логоффе per-user-session сервисы останавливаются, после того, как завершены все приложения, относящиеся к сессии. blp>Пока сервисы не остановятся, логофф не заканчивается. blp>Таймаут на свою остановку сервис определяет сам, и он может быть довольно большим (3 минуты по умолчанию). Если бы вы читали ссылки, что я даю, вы бы это и так знали.
В ссылках, которые вы привели, нет ничего про задержку логофф.
S>>Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы? blp>Потому что у вас системный процесс со временем жизни в юзерскую логон-сессию? Для изоляции, помните?
Да-да, я помню. Четвёртый круг нарезаем.
>>Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли". blp>А таймаут остановки сервиса определяете самим сервисом. Улавливаете?
И? Давайте это переведём в прикладную плоскость. Что за действия могут потребоваться сервису, которые не влезают в 30 секунд, но влезают в 300? Были бы интересны примеры.
Желательно хотя бы с намёком на объяснение причин, по которым эти действия нельзя переписать так, чтобы они успевали отрабатывать меньше, но быстрее. Ну, вот как например в базах данных коммит транзакции сделан так, чтобы не зависеть от внесения изменений в собственно данные. Да, потом при старте может потребоваться время на rollback/rollforward, зато целостность никак не зависит от возможности отложить пропадание питания в датацентре на 300 секунд.
Читаем MSDN:
Customers require fast shutdown of the operating system. For example, if a computer running on UPS power cannot complete shutdown before the UPS runs out of power, data can be lost. Therefore, services should complete their cleanup tasks as quickly as possible. It is a good practice to minimize unsaved data by saving data on a regular basis, keeping track of the data that is saved to disk, and only saving your unsaved data on shutdown. Because the computer is being shut down, do not spend time releasing allocated memory or other system resources. If you need to notify a server that you are exiting, minimize the time spent waiting for a reply, because network problems could delay the shutdown of your service.
>> Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии blp>Ну не видите и не видите. Конечно, то, чего вы не видите, не существует.
Нет, просто я ожидаю от более квалифицированых людей способности давать объяснения чуть более подробно, чем "это не ваше дело", и "если сказали, делать per-user-session, то будем делать per-user-session".
blp>Нет, в MSDN так не написано.
Цитирую:
If a service must do lengthy processing when the service is executing the control handler, it should create a secondary thread to perform the lengthy processing, and then return from the control handler.
switch (control)
{
case SERVICE_CONTROL_STOP:
case SERVICE_CONTROL_SHUTDOWN:
case SERVICE_CONTROL_PRESHUTDOWN:
{
m_status.dwCurrentState = SERVICE_STOP_PENDING;
VERIFY(::SetServiceStatus(m_handle,
&m_status));
CHandle thread(::CreateThread(0, // default security
0, // default stack size
StopThread,
this, // context
0, // no flags
0)); // ignore thread idbreak;
}
blp>Потому что LUID в имени сервиса — гарантированно уникальный на каждый логон эвент на все время, пока машину не перезагрузят, а session id может переиспользоваться в ряде случаев.
А чем это переиспользование плохо?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Да, и несмотря на три десятка сообщений в ветке простые вопросы так и не были отвечены: S>1. зачем было принято решение изолировать системный код для каждой сессии. S>2. Было ли порождение сервисов по шаблону наилучшим решением данной задачи S>3. Почему было принято решение не документировать разработку таких сервисов
1. Пока больше похоже на то, что был нужен механизм отслеживания использования служб пользователем в течении сеанса. И механизм влияния на действия в сеансе, не затрагивая других сеансов.
3. Чтобы иметь преимущество в использовании механизмов отслеживания и влияния. И быть может, продавать доступ к механизмам как услугу.
Но это слишком конспиративно. Поскольку сам обратил внимание на такие службы, когда ОС принуждала мои станции к обновлению.
K>самое бестолковое, что могли придумать скудоумые индусы — они думают, что UNIX — это хороший пример для подражания.
UNIX хороший пример для подражания. Если подражать Trusted BSD, SELinux, или XNU MACF/AMFI/Entitlements. А не допотопной модели безопасности, где кроме юзеров и групп и нет ничего.
А и хрен бы на неё. Wine прогрессирует семимильными шагами. Не успеваешь следить за новыми фичами. DX12, Vulkan, DXVK. Все больше и больше поддерживаемых игорей. Фотожопа тоже, по слухам, норм работает с GPU–ускорением.
PS. А такими темпами, как сейчас искусственно гробят винду, не исключено что при нашей жизни, наконец, свершится невозможное. И даже ReactOS обгонит её по качеству. Наглядно продемонстрировав апорию о черепахе и Ахиллесе.
Здравствуйте, serj.e, Вы писали:
SE>Встречный вопрос. А зачем возможность отключения выведена в MMC?
Это эволюционный отбор. Воинствующая некомпетентность, лезущая что-то отключать, не разобравшись зачем, будет платить за восстановление, благодаря чему либо научится сначала думать, либо станет кормовой базой для эникейщиков по вызову.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, serj.e, Вы писали:
SE>А и хрен бы на неё. Wine прогрессирует семимильными шагами. Не успеваешь следить за новыми фичами. DX12, Vulkan, DXVK. Все больше и больше поддерживаемых игорей. Фотожопа тоже, по слухам, норм работает с GPU–ускорением.
Оно если и прогрессирует то как то не там где я его использую.
.
Я же вам написал — тот экземпляр сервиса, который запущен в моей сессии. Вы продолжаете выкручиваться.
Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.
