Здравствуйте, AlexRK, Вы писали:
ARK>Чтобы ответить на этот вопрос, надо знать все уязвимости во всех сервисах. Однако, учитывая, что они постоянно обновляются, ответа на этот вопрос вообще не существует — сегодня 0.0001%, а завтра с новым говнообновлением 90%.
ARK>Чем меньше кода работает (и даже вообще присутствует в любой системе) — тем лучше.
Ну т.е. ты не знаешь, но мнение имеешь.
ARK>Хватает, не хватает — не имеет значения. Бесполезный мусор не нужен.
Почему бесполезный? Например, если его не трогать, то ты завтра не начнешь кричать, что у тебя что-то не работает, греша на всех, кроме себя.
ARK>В win 10 нереально. В 7 еще реально.
Нет, это нереально с самого появления многозадачных ОС с фоновыми процессами.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
S>Вот я и о том же: вы даже не пытаетесь разбираться в теме, но мнение имеете.
Ты сейчас на полном серьёзе утверждаешь что человек который прошёлся по сервисам, почитал про них, половину отрубил, и полностью доволен результатом "не пытается разбираться в теме"? А тот кто поставил то что поставилось, и забил болт на то что у него безостановочно что-то пишется на винт, чем-то занято одно ядро CPU, и постоянно висят коннекты незнамо куда — значит в теме разбирается??
Спасибо, кажется веселее в этом обсуждении уже не будет Пойду, почитаю другие темы...
Здравствуйте, 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", что можете сами принять решение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
O>>Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда. blp>Ну расскажите, поделитесь, что же вам было понятно. Флаг не работает (ну или "не так работает") начиная с Висты.
Я дал достаточно информации чтобы тот кто знает про то как этот флаг не работает понял что я это тоже знаю. Если вы этого не поняли — значит вы тоже неквалифицированный разработчик. Ну или не разработчик вовсе — читать ваши сообщения на кывте влом. Но я дам вам второй шанс: на самом деле он "не так работает" гораздо раньше — начиная с 2000й винды так точно. Просто начиная с висты это стало видно по умолчанию.
O>>Я ответил. Неквалифицированные разработчики, привыкшие делать по быстрому и через жопу, и считающие что так и должно быть. Имеющегося функционала хватало на решение любой задачи. Если обладаете тайными знания — расскажите. А я расскажу как можно было это сделать не через жопу. blp>Ну я ж и говорю — типичный эффект Даннинга-Крюгера. Вы-то лучше всех знаете, как можно было сделать. И в вашем уютном мирке разницы между автораном и сервисами, запускаемыми в контексте юзерской сессии, нету, потому что вы ее не видите. А то, чего вы не видите, очевидно, не существует.
Ну то есть технической информацией и пониманием сути проблемы вы не располагаете, предпочитая тонкий, как вам кажется, троллинг. Просто еще одно подтверждение вашей неквалифицированности.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 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, но своё мнение у них по любому вопросу есть.
Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.
Ops>Э, нет. Если следовать первоначальной аналогии, продукт тут ОС, а сервисы — это ингредиенты. Ты же, условно, занимаешься выковыриванием изюма из булочек, т.к. изюм не любишь.
Если следовать аналогии, в булочки вместо изюма засунули мух, а продавец втирает что это такой новый изюм, без которого булочку не сделать. Не знаю как ты, а я выковыряю
Здравствуйте, Ops, Вы писали:
ARK>>Ты читать умеешь? Если да, то прочти внимательно еще раз мой пост и постарайся понять, что твой вопрос разумного ответа не имеет. Ops>Т.е. вопрос веры, а не научного подхода? Ок.
В науке есть множество дисциплин, расчеты в которых либо неимоверно сложны, либо вообще нерешаемы на текущий момент — какие-нибудь уравнения Навье-Стокса, например, первое, что в голову пришло. Ответ на твой мудрейший вопрос, наверное, не настолько сложен, но он далеко за пределами возможностей не только одного человека, но и научного института. Для ответа необходимо знать полный набор уязвимостей ОС и полный набор существующих на данный момент эксплуататоров этих уязвимостей. Теоретически узнать это возможно, но практически — вряд ли. И самое главное, что это бессмысленное занятие, потому что, во-первых, ОС и вирусы обновляются непрерывно, а во-вторых, чисто статистически уязвимости есть в любом коде и отключение этого кода снижает их количество на некоторое число, большее нуля. Если тебе эти элементарные вещи непонятны, то уже мне непонятно, как ты можешь работать программистом (если ты программист, конечно).
ARK>>А то, что любое, пусть и сколь угодно малое, число всегда строго больше нуля — это я знаю точно. Ops>Конечно. Но ты же не ходишь везде с молниеотводом, хотя шанс что шарахнет отнюдь не нулевой.
Если бы ношение молниеотвода мне ничего не стоило (как в случае с отключением сервисов), то я бы с ним везде ходил.
Здравствуйте, _ilya_, Вы писали:
__>Называют себя UnistackSvcGroup __>Генерируют службы с рандомным именем, и их не просто отключить. __>Винда конечно уже не та, но чтобы так откровенно вредосоны доставлять "клиентам". Лучше бы просто застрелились.
а это случайно не те "push уведомления" за счёт которых телеграмм работает ?
Здравствуйте, blp, Вы писали: >>Я лишь объяснил что в нем нет ничего особенного. Как и в остальных особенностях сервисов. blp>Нету ничего особенного, да. Просто особенности есть. И когда в особенностях детально разбираешься, становится понятно, почему нельзя взять и запихать сервисы в авторан. А так — да, ничего особенного.
Ну вот если вы разобрались, то напишите простым языком прямо сюда результаты ваших разборок. Ваши намёки на то, что вы знаете больше, чем собеседник, выглядят плохо.
Лучший способ бравировать знаниями — демонстрировать их. Худший — тот, что вы демонстрируете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, C C>Да, забейте Вы на этого тролля. Я уже несколько дней слежу за этой дискуссией, ничего по делу он не сказал вовсе. C>
C>Если вы ученый, квантовый физик и не можете в двух словах объяснить пятилетнему ребенку, чем вы занимаетесь, — вы шарлатан.
C>Вот енто про него сказано.
На самом деле, такие очень стимулируют. Эти изворачивания, результат постоянного стресса и попыток выплыть в проигрышной ситуации. Страха что попрут в любой момент. Я видел и откровенных зомби и таких вот, изворотливых.
Это как слабая антилопа поедаемая львами, стимулирует остальных бежать впереди стада. И дает ощущения радости, что "хорошо, что это не я, побегу я еще быстрее"
Но потенциал стимуляции уже исчерпан. Посмотрим, напишет ли кто-то что-то дельное.
S>Как бы я не против, чтобы все эти штуки развлекались своими делами. Но не так, чтобы мешать мне работать. S>Машина в 25000 раз быстрее моего первого 1ВМ РС АТ работает визуально медленнее, т.к. 80% её мощности расходуется на посторонние вещи. S>Иногда хочется, чтобы я мог претендовать хотя бы на 80% от этих мощностей.
Наконец-то не просто здравая мысль, их тут было, а здравая мысль в точку…
PS: не помню у кого в блоге, но читал с год назад. Характерная ситуация
В общем, парень занимается какой-то там мобильной разработкой. На машинке стоит 10-ка. И куча тулов девелоперских к ней. С треть аль с половину Microsoft`овских тулов. Всякие там редакторы, дебаггеры, профайлеры, эмуляторы и прочия. В разработке частенько используется большая их часть одновременно, вот прям рядом крутятся…
Бинго! Ура! Наконец-то!!! Microsoft всё улучшила, зе-е-е-р гут!!! Поют сердца! Ну вроде теперь поработаем. Все эти девелоперские тулы опять разом стартуют, открываются проекты, вроде сейчас пальчики наши застучат по клаве…
Угу! Щаз!!! А вот хрен вам. И тут Windows Update радостно находит и еще какое-то обновление для уже какой-нить другой тулы, и опять без спросу начинает ставить его… Ну спасиб, йопта, вот именно сейчас, именно его и не хватало…
За кадром играет тревожная музыка… Зритель замер в ожидании. Вообще-то он не зритель, он разработчик. Но его никто не спрашивает. Теперь он зритель, и ему только и остается что замирать в ожидании.
После чего 10-ка опять перезрагружает машинку…
И так может продолжаться полдня… Это не опечатка — именно полдня!!! Без спросу и согласия хозяина машины…
Не, ну блин, это что нормально?
На этот раз у историков даже не два, а один вопрос: они там что, в Microsoft, совсем ох?*%ли?
Здравствуйте, blp, Вы писали:
S>>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем. blp>Потому что задача — сделать per-user сервис.
Это не задача. Это решение. Задача в чём?
blp>Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода.
Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен.
blp>per-user сервисы нужны, чтобы, например, изолировать юзерские данные специфичные для этого сервиса друг от друга, что физически невозможно, когда данные разных юзеров лежат памяти одного процесса. Также, например, per-user сервисы можно запускать в security-контексте того юзера, для которого они созданы / запущены и с правами этого юзера, а не с системными правами.
Ну, ок. Допустим, аргумент про изоляцию.
blp>Что в лоб, что по лбу. System-wide сервис никак не сможет заблокирвать logoff (он не может останавливаться на logoff eventе) — он максимум может заблокировать shutdown при своей остановке. Ну очевидно же.
А зачем блокировать Logoff event?
blp>а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу.
Не получается.
blp>Ага. Я — всегда готов, многим людям просто не нужно многое из того, что я могу рассказать (судя по их ответам) Им нужно самоутвердиться и рассказать, какие они были крутые архитекторы 20 лет назад.
Меньше думайте о людях; больше — о технических подробностях.
blp>Непонятно, почему вы так решили.
Это гипотеза, которая призвана объяснить отсутствие документации по их написанию.
blp>За второй: чтобы не делать релизы винды раз в 3-4 года (а "нормально винды" раз в 5-6 лет), как раньше, а быть on par с вещами вроде андроида, фичи выпускают чаще, документации по ним может не быть какое-то время.
Ну, то есть сама фича продумана хорошо, архитектура норм, а документация просто "не успевает". Когда там выпустили эти сервисы? Судя по отзывам, прошло уже два с половиной года.
Либо в Редмонде системный кризис с техдоками, либо эта версия неверна.
blp>а что сразу не "тот, который был запущен в Рамадан в 2019 году"? Может вы еще придумаете каких-то ограничений, про которые не в курсе существющие инструменты, которые работают с именами сервисов? Есть способ получить список сервисов с их именами и описаниями. Если способ перезапустить сервис по имени. Способа "найти сервис, который относится к текущей сессии пользователя" не было и нет. Равно как и "найти сервис который был запущен в определенную фазу луны".
Вот видите, как всё плохо. Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить", вызывает какое-то извивание хребтом вместо простого ответа. Нет ни инструментов, ни решения "из палок". Для сравнения: со "старыми" сервисами такой проблемы нет — есть детерминированный способ узнать имя сервиса.
Вот, к примеру, для именованных инстансов SQL Server: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/start-stop-pause-resume-restart-sql-server-services?view=sql-server-ver15
blp>Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно.
А вот мне очень весело. Во-первых, я получаю полезные знания, а во вторых, получаю эстетическое удовольствие, глядя на то, как вы выкручиваетесь из положения, в которое сами себя загнали.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ops, Вы писали:
Ops>Нет, это изюм. Пример, кстати, из жизни, недалеко от меня сейчас человек, который изюм не любит, и называет его как раз тараканами. Ну а у любителей все поотключать, превратив систему в ту булку, после выковыривания из нее изюма, свои тараканы в голове: перфекционизм, мания, паранойя, еще что-то, нужное подчеркнуть. И вряд ли им это упрощает жизнь.
Вот если честно, я иногда понимаю этих людей.
Приходишь на работу, открываешь ноут — а там открытие новой табы в FF занимает 15 секунд, а паузы между появлениями буков при наборе текста в аутлуке видны визуально.
Смотришь в таск менеджер, а там — вакханалия. Три ядра из четырёх заняты каким-то блоатваром, типа Касперского (который тудычит файлуху), Цисковского какого-то антималвара (надо же проверить, не приехало ли по сети что-то вредное), и таниум над всем этим, чтобы наши корпоративные админы могли делать мне хорошо. Плюс ещё какой-нибудь Intel Zero Config Service периодически начинает жрать такты и память, как не в себя.
Как бы я не против, чтобы все эти штуки развлекались своими делами. Но не так, чтобы мешать мне работать.
Машина в 25000 раз быстрее моего первого 1ВМ РС АТ работает визуально медленнее, т.к. 80% её мощности расходуется на посторонние вещи.
Иногда хочется, чтобы я мог претендовать хотя бы на 80% от этих мощностей.
У меня такой возможности нет — машинка не моя, а корпоративная. Компания имеет право делать с ней что угодно — хоть запрещать мне ставить торрент-клиента (вот для чего нужен таниум ), хоть майнить койны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
O>>Изначально были юзерские процессы и сервисы. Отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания. blp>Ооооо, блин. Какое у вас глубокое понимание виндовой архитектуры, аж плакать хочется. Про флаг SERVICE_INTERACTIVE_PROCESS вы не в курсе, про много чего еще, видимо, тоже.
Я про этот флаг узнал лет 20 назад, возможно вас тогда еще и в проекте не было. И тогда его установка приводила к тому что гуй сервиса действительно был интерактивен. Потом его сломали сервисы оказались на отдельной сессии, но подкостылили мониторингом созданмя видимых top-level окон к той сессии.
O>>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше? blp>Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты.
Потому что для решения их задачи был уже и не один способ помимо того чтоб сломать изначальную архитектуру. Не идиоты — это все же клинический диагноз, а я не врач чтоб его ставить, просто недостаток знаний.
В конце концов, даже юзая сервисы можно было бы сделать по нормальному, а не генеря ИмяСервиса_рандом. Этож какое то наколенное решение. Оно воняет.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 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, который я наблюдаю в своей карьере.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Называют себя UnistackSvcGroup
Генерируют службы с рандомным именем, и их не просто отключить.
Винда конечно уже не та, но чтобы так откровенно вредосоны доставлять "клиентам". Лучше бы просто застрелились.
Здравствуйте, Ops, Вы писали:
ARK>>Уменьшить площадь потенциальной атаки. Ops>И на сколько именно, в цифрах?
Чтобы ответить на этот вопрос, надо знать все уязвимости во всех сервисах. Однако, учитывая, что они постоянно обновляются, ответа на этот вопрос вообще не существует — сегодня 0.0001%, а завтра с новым говнообновлением 90%.
Чем меньше кода работает (и даже вообще присутствует в любой системе) — тем лучше.
ARK>>Не тратить попусту ресурсы. Ops>Не хватает?
Хватает, не хватает — не имеет значения. Бесполезный мусор не нужен.
ARK>>Не позволять ОС жить своей жизнью. Ops>Это давно нереально, смирись.
Здравствуйте, hi_octane, Вы писали:
_>Если следовать аналогии, в булочки вместо изюма засунули мух, а продавец втирает что это такой новый изюм, без которого булочку не сделать. Не знаю как ты, а я выковыряю
Если следовать аналогии, то сейчас вы рассуждаете как противник пищевых добавок: мол если в продукте есть E330, то "Ой всё, буржуи нас травят!!!".
blp>>>https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows O>>Оксюморон какойто. Сервисы — процессы отвязанные от юзерской сессии. И чем это better чем таски да и банальный авторан?.. blp>https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Да причем тут даннинг крюгер когда имеет место явный костыль.
Изначально были юзерские процессы и сервисы. Отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания.
Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше? Это просто избыточный функционал и извращение изначальной идеи NT Service. Вот как это выглядит:
Гдето в 198х: давайте сделаем автозапуск виндовых апликух, autoexec.bat это не кошерно, сделаем папочку, назовем ее Startup
Гдето в 199х: давайте сделаем автозапуск виндовых апликух, папочка Startup надоела, сделаем ключ в реестре SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Гдето в 200х: SOFTWARE\Microsoft\Windows\CurrentVersion\Run не солидно, команда at тоже, сделаем супер-шедулятор с возможностью автоматического запуска тасок при логине юзера
Гдето в 201х: никто в команде не помнит как юзать супер-шедулятор для запуска пользовательских апликух, но нашелся один человек который знает про CreateService, но он не умеет запускать пользовательские апликухи. Давайте попросим windows services team добавить такую возможность.
...а гдето в углу тихо плачет некто Д. Катлер
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Vetal_ca, Вы писали:
blp>>Какой именно один сервис? Обсуждаемых сервисов там существенно больше одного они все имеют свой цикл жизни, могу независимо запускаться и останавливаться. Вы предлагаете какой-то свой адов альтернативный дизайн и думаете, я телепат и пойму, что вы там где видели и что имели в виду. V_>Понятно, общение бесполезно. Темой не владеешь.
Да, забейте Вы на этого тролля. Я уже несколько дней слежу за этой дискуссией, ничего по делу он не сказал вовсе.
Если вы ученый, квантовый физик и не можете в двух словах объяснить пятилетнему ребенку, чем вы занимаетесь, — вы шарлатан.
Вот енто про него сказано.
PS: Но… это… народ! Вы действо не прекращайте, мне вот интересно мнение ononim`а, да и прочих с-а-а-всем небезынтересно…
Я сам в этой теме исключительный боксер-теоретик: интересовался, читал то-сё, в общих чертах что-то (мне кажется) понимаю. Но впрямую с разработкой сервисов жизнь так и не столкнула. А послушать профи все ж интересно. "Ибо завсегда есть нюанс" (бородатый анекдот уж приводить не будем )
Здравствуйте, blp, Вы писали: blp>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый.
Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем бойлерплейта для превращения приложения в сервис.
S>>Ну, так-то приложения тоже можно запускать и останавливать штатными средствами. blp>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает?
Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION blp>Как сделать так, чтобы на это мог/не мог повлиять юзер?
Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
Если вам что-то непонятно, то спрашивайте. Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню. blp>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
Не убедили. S>>Ну вот видите, три из четырёх "отличий" оказываются спорными. blp>это они вашей точки зрения спорные.
Отож. Пока что вы не рассказали ничего интересного. Возможность рестартнуть приложение через SCM сама по себе не очень интересна — либо я чего-то не понимаю.
blp>Нет, недостаточно. Причин больше, да и привиденные мной причины отметать не получится.
Пока что получается. Пишите больше причин.
blp>забыли упомянуть что?
Забыли упомянуть, зачем они вообще нужны. blp>Эти новые типы сервисов (USER_OWN_PROCESS / USER_SHARE_PROCESS TEMPLATE/INSTANCE — https://github.com/processhacker/processhacker/blob/master/phlib/svcsup.c) — они недокументированные. В виндах много чего недокументированного, что именно вас удивляет?
Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
Это же вы привели эту ссылку. Другое дело — что релизили их настолько поспешно, что документация представлена чисто номинально.
blp>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент.
Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой. Почему-то когда релизили "обычные" сервисы, никто не говорил "есть простой способ послать сигнал сервису — простая программа в 140 строк на С++ сделает вам рестарт сервиса" или "поправьте реестр, если не хотите, чтобы сервис стартовал автоматически". Их поддерживает нахрен вся инфраструктура винды — от Group policy до Windows Installer и Task Manager. Ок, хрен с ним — не успели припилить нормальный гуй. Но что мешало хотя бы error message сделать нормальный при попытке сделать configure такому сервису? Нет же, просто отдадим The parameter is incorrect и пусть жертва гадает, что это за херня приехала по интернету.
А per-user services именно что и выглядят, как нашлёпка сбоку, которую не успели встроить в винду полноценно. blp> Инстансы этих шаблонов — вполне себе сервисы и с ними инструменты работают, как написано в документации. blp>Если весь сыр-бор от того, что МС не сделал красивый гуй для редактирования шаблонов — то да, это конечно страшная трагедия и несоменено сигнализирует о кривизне чьих-то рук.
Весь сыр-бор — из-за того, что банальная штука "сделать, чтобы сервис не стартовал при каждом логине", работает для всех сервисов, кроме вот этих новых. То есть даже с инстансом шаблона не выйдет работать как с обычным сервисом.
Далее — "обычные" сервисы можно программно идентифицировать по их короткому имени, как обычно и делается при скриптинге. У этих сервисов имена генерятся рандомно — покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера. Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, blp, Вы писали:
blp>Здравствуйте, Sinclair, Вы писали: blp>>>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д) S>>Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии. blp>Читаем внимательно: надо не просто сделать запуск одной копии приложения. Надо еще написать всю остальную функциональность, которая уже есть для сервисов. Например, запуск зависимых сервисов, перезапуск сервиса, если он внезапно завершился, правильная очередность остановки и т. д. — по сути вся функциональность SCM. Я понимаю, что в вашем уютном мире ничего, кроме запуска одной копии сервиса и его остановки, не нужно, но в реальном мире не так.
Ну вот, уже лучше. Видите, насколько полезнее писать конкретные вещи, чем общие соображения — начинается содержательная дискуссия.
Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем.
blp>Добавьте туда еще то, что код per-user сервисов — это отрефактореный код существующих сервисов и драйверов (виндовые драйвера больше поохожи на виндовые сервисы в плане организации кода и интеграции с SCM). Ваше предложение предполагает взять существующие сервисы/драйвера и поменять их архитекутуру, сделав просто приложениями, да еще и впилить в каждое из них кусок логики SCMа для запуска/перезапуска. Улавливаете?
Эмм, то есть вот эти вот per-user сервисы когда-то были system wide, а потом их решили перевелосипедить на per-user?
Это интересно. Можете рассказать, зачем это было сделано?
blp>Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
Очень хорошо. Почему бы такие вещи не доверить system-wide сервису? Заодно разрешаем пользователю сделать logoff прямо сейчас, не вынуждая его ждать минуту, пока там сервис соизволит завершить асинхронные задачи.
Shutdown — дело другое, можно и подождать.
blp>Ну вот, еще один. Писал что-то там 17 лет назад, не помнит специфики, следовательно ее нет. Скучно.
Концепция сайтов, подобных этому, построена не только на тех, кто хочет научиться, но и на тех, кто хочет научить. Вы хотите, чтобы те посетители, которые знают больше вас, рассказывали вам что-то интересное. Если они будут придерживаться вашей стратегии ведения дискуссии, то вы так и не прочтёте ничего нового. А значит что? Значит всегда надо быть готовым что-то рассказать самому — тем, кто знает меньше вас.
Логика понятна? blp>еще раз — недокументированы новые типы сервисов, как их например самому писать.
Давайте попробуем угадать: эти сервисы — какое-то зло, которое лучше не давать разрабатывать рядовым разработчикам. Если так, то отсутствие документации по ним — это норм, вменяемое решение. Отсутствие гуя — это намеренный, здравый ход, нацеленный на промоушен обновлённых курсов MCSA.
Но если такой тип сервисов — это полезная штука, полноценная часть экосистемы винды, то задокументировать их хотели, но релиз был поспешным, и задокументировать их просто не успели.
Третий вариант — никакого осознанного решения не апдейтить тулзы и документацию не было, просто в Редмонде окончательно развалился менеджмент, и межкомандная координация осталась где-то там, в тех временах, когда я ещё писал сервисы под винду.
Вы за какой вариант выступаете?
blp>Существующие инструменты прекрасно управляют тем, что есть и вписывается в набор сущностей, которыми они управляют.
Ок, откуда тогда error message? Вернёмся к корневому сообшению. >> покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера. blp>Какой именно из "сервис WpnUserService на машине топикстартера"?
Их на машине может быть больше одного. А может быть 0, если на машину топкстартера никто не залогинен. Ответьте на этот вопрос, может быть просветление снизойдет на вас.
Отличный вопрос. Давайте для начала тот, который относится к текущей сессии пользователя. Чтобы избежать вырожденных случаев, ограничимся интерактивным запуском скрипта — т.е. на машине гарантированно кто-то залогинен.
blp>Скучно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 может переиспользоваться в ряде случаев.
Здравствуйте, Kolesiki, Вы писали:
K>Я б начал с более глубокого вопроса: а что, без десятки — никак?
На новом железе увы никак, поднасрали с дровами.
K>Юзаю Win7 и там всё работает, никто не лезет обновляться, никакого самоуправства на моём ПК.
Да, на 7ке всё пучком.
K>Я понимаю, что есть новые ноуты, которые не имеют дров к семёрке, но всё равно можно попробовать поставить — вдруг заработает? А если и отвалится какой-нть блюпуп — так и фиг с ним!
Увы, там всё куда хуже — все дрова под новое железо только под 10ку. А это считай всё что встроено в мать.
blp>Соверешнно верно. Еще умные люди умеют внятно формулировать вопросы или не задавать вопросы, когда ответы на них вполне можно найти самостоятельно если просто сформулировать вопрос правильно.
Но ты, надув щеки создавал видимость знания. Ошибся, каюсь, не стоило тратить время.
Все что ты донес, что с сервисами хаос и непонимание. Плюс куча не специалистов с надутыми щеками крутятся у умирающего трупа Windows. Ничего нового.
blp>Поток сознания какой-то. Вас что-то беспокоит и вы хотите об этом поговорить?
Таким со мной некомфортно, да. Это нормальная реакция. Отбраковка работает.
>>Вот мой ответ, четкий и ясный. blp>Ваш ответ на вопрос "что такое стандартный способ?" из предыдущего сообщения, которое было про сервисы. Оукеей.
Сервис + per-user userspace GUI/headless процесс.
Пару примеры этого стандартного подхода (с моего PC) —
blp>А, ну то есть вместо решения конкретной задачи, с которой начался этот срач ("чем эти сервисы лучше, чем таски или банальный авторан") мы теперь решаем другую (сервис оставляем, но он у нас один, а какую-то часть логики пихаем в приложения) — рисуем лошадку.
blp>И когда нас пытаются вернуть к суровой реальности, в которой нужен сервис на юзерскую сессию (работающий под аккаунтом юзера и, например, блокирующий логофф, пока сервисы не завершится), мы лепечем что-то про "неквалицифированных людей". blp>Если вы на своей работе так же задачи решаете — меняете задачу на более вам удобную и потом придумываете как ее решить, какому-то работадателю сильно не повезло
Видишь ли, я ставлю задачи и делаю реальность сам. Вместо того чтобы подстраиваться под косяки других. У меня это получается, выхлоп хороший и, как результат, доверие и власть "делать реальность" мне даны.
Это называется самореализацией и это мне нравится.
Повышай квалификацию и не придется разгребать г-но из-под неквалифицированных индусов. Которые тебе дают задачи и у тебя нет иных вариантов, кроме как подчиниться
blp>Вы явно хотите мне что-то сказать, но постоянно от вас одни намеки. Скажите уже прямо.
Пока "делать писанину" с нулевым выхлопом это твоя привилегия. Заметь, это не только мое мнение
Здравствуйте, 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 может переиспользоваться в ряде случаев.
А чем это переиспользование плохо?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Можно просто в реестре поставить:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Имя_Сервиса\Start = 4, если не даёт поставить Disabled через Services
Ops>А зачем тебе их отключать? Цель какая?
Чисто математически:
В современных программах примерно 4-10 ошибок на 10000 строк кода. В новом коде ошибок больше. Получается чем меньше новых сервисов работает, тем мой комп стабильнее и надёжнее
Здравствуйте, hi_octane, Вы писали:
_>Чисто математически: _>В современных программах примерно 4-10 ошибок на 10000 строк кода. В новом коде ошибок больше. Получается чем меньше новых сервисов работает, тем мой комп стабильнее и надёжнее
Тебе жмут эти ошибки "где-то там", если они тебя не затрагивают? Я вот уже и не помню, когда система у меня последний раз падала, зато во времена, когда "сервисы были маленькие и понятные", это случалось с завидной периодичностью.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Ops>Тебе жмут эти ошибки "где-то там", если они тебя не затрагивают? Я вот уже и не помню, когда система у меня последний раз падала, зато во времена, когда "сервисы были маленькие и понятные", это случалось с завидной периодичностью.
А вспомнить? Совсем недавно тут писал, причём тебе же
А вот ноут сразу после установки винды был всегда тёплый и шумел, а теперь он холодный при сидении в браузере кулер вообще не включается. Собственно если внезапно шуметь начинает — уже индикатор что пора очередную вошь ловить.
Есть ощущение что каждая ошибка в подписанных MS сервисах активирует запись дампа и отправку его куда-то. Это всё может быть очень важно сотрудникам МС, но мне какой интерес? Вот сделали бы Microsoft Telemery Coin, который начисляли за каждую уникальную ошибку — я был бы их сбоящим сервисам рад, сдавал бы "намайненное" на бирже и богател. А так как сейчас — словно криптомайнер подхватил.
Здравствуйте, hi_octane, Вы писали:
_>Вот я из всего ассортимента выбираю хорошие продукты, а плохие оставляю на полке магазина. И с сервисами также — нужные мне запущены, остальные валяются где-то на диске.
Э, нет. Если следовать первоначальной аналогии, продукт тут ОС, а сервисы — это ингредиенты. Ты же, условно, занимаешься выковыриванием изюма из булочек, т.к. изюм не любишь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, hi_octane, Вы писали:
S>>Если следовать аналогии, то сейчас вы рассуждаете как противник пищевых добавок: мол если в продукте есть E330, то "Ой всё, буржуи нас травят!!!". _>Начиная с win8 эти добавочки живут своей жизнью и шевелятся когда сами того захотят. То-ли червячки то-ли глисты какие. По-сравеннию с NT4 — реально же "Ой всё, буржуи нас травят!!!".
Вот я и о том же: вы даже не пытаетесь разбираться в теме, но мнение имеете.
Здравствуйте, AlexRK, Вы писали:
ARK>>>Уменьшить площадь потенциальной атаки. Ops>>И на сколько именно, в цифрах?
ARK>Чтобы ответить на этот вопрос, надо знать все уязвимости во всех сервисах. Однако, учитывая, что они постоянно обновляются, ответа на этот вопрос вообще не существует — сегодня 0.0001%, а завтра с новым говнообновлением 90%.
ARK>Чем меньше кода работает (и даже вообще присутствует в любой системе) — тем лучше.
По такой логике надо антивирус, фаервол отключать.
Здравствуйте, vsb, Вы писали:
ARK>>Чтобы ответить на этот вопрос, надо знать все уязвимости во всех сервисах. Однако, учитывая, что они постоянно обновляются, ответа на этот вопрос вообще не существует — сегодня 0.0001%, а завтра с новым говнообновлением 90%. ARK>>Чем меньше кода работает (и даже вообще присутствует в любой системе) — тем лучше.
vsb>По такой логике надо антивирус, фаервол отключать.
По такой логике надо отключать то, что не используется.
Здравствуйте, kgd, Вы писали:
kgd>Не изюма, а непонятных включений, которые невозможно идентифицировать, как изюм. Может это тушки тараканов, может гнилой юзюм, а может крысиные какашки.
Нет, это изюм. Пример, кстати, из жизни, недалеко от меня сейчас человек, который изюм не любит, и называет его как раз тараканами. Ну а у любителей все поотключать, превратив систему в ту булку, после выковыривания из нее изюма, свои тараканы в голове: перфекционизм, мания, паранойя, еще что-то, нужное подчеркнуть. И вряд ли им это упрощает жизнь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ononim, Вы писали:
__>>Называют себя UnistackSvcGroup O>Танцующие инопланетяне, причем из касты неприкасаемых. Даже не представляю какой длины была спаггетина в ланче того мз них, кто решил делать сервисы с рандомными именами.
Не, это просто эти клованы решили что надо каждому юзеру запускать свою копию сервиса, чтоб если они там опять дыру забудут то дальше юзера вылезти не получилось.
Ну а поскольку существующая инфраструктура сервисов не предполагала такого зоопарка они просто решили делать "уникальные" сервисы через имена.
Здравствуйте, CreatorCray, Вы писали:
CC>Не, это просто эти клованы решили что надо каждому юзеру запускать свою копию сервиса, чтоб если они там опять дыру забудут то дальше юзера вылезти не получилось.
Ну так а дальше и не надо! От имени юзера можно перезаражать ВСЕ его файлы, вылезти в сеть, залить что-то на шареный ресурс и т.п. Работать от имени юзера — это вообще самое бестолковое, что могли придумать скудоумые индусы — они думают, что UNIX — это хороший пример для подражания.
>>И тогда его установка приводила к тому что гуй сервиса действительно был интерактивен. Потом его сломали сервисы оказались на отдельной сессии, но подкостылили мониторингом созданмя видимых top-level окон к той сессии. blp>Спешное гугление и чтение МСДНа. Лучше поздно, чем никогда.
Безосновательные инсенуации.
blp>Подумайте еще немного, может быть до вас дойдет, зачем же все-таки нужна это функциональность, которую сломали, почему ее сломали и кто и зачем ее сломал.
Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда.
O>>>>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше? blp>>>Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты. O>>Потому что для решения их задачи был уже и не один способ помимо того чтоб сломать изначальную архитектуру. blp>"Зачем", а не "почему". Вы не ответили пока на этот вопрос.
Я ответил. Неквалифицированные разработчики, привыкшие делать по быстрому и через жопу, и считающие что так и должно быть. Имеющегося функционала хватало на решение любой задачи. Если обладаете тайными знания — расскажите. А я расскажу как можно было это сделать не через жопу.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
blp>>Подумайте еще немного, может быть до вас дойдет, зачем же все-таки нужна это функциональность, которую сломали, почему ее сломали и кто и зачем ее сломал. O>Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда.
Ну расскажите, поделитесь, что же вам было понятно. Флаг не работает (ну или "не так работает") начиная с Висты.
O>>>>>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше? blp>>>>Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты. O>>>Потому что для решения их задачи был уже и не один способ помимо того чтоб сломать изначальную архитектуру. blp>>"Зачем", а не "почему". Вы не ответили пока на этот вопрос. O>Я ответил. Неквалифицированные разработчики, привыкшие делать по быстрому и через жопу, и считающие что так и должно быть. Имеющегося функционала хватало на решение любой задачи. Если обладаете тайными знания — расскажите. А я расскажу как можно было это сделать не через жопу.
Ну я ж и говорю — типичный эффект Даннинга-Крюгера. Вы-то лучше всех знаете, как можно было сделать. И в вашем уютном мирке разницы между автораном и сервисами, запускаемыми в контексте юзерской сессии, нету, потому что вы ее не видите. А то, чего вы не видите, очевидно, не существует.
Здравствуйте, ononim, Вы писали:
O>>>Ну то есть технической информацией и пониманием сути проблемы вы не располагаете blp>>Почему не располагаю, вполне располагаю. Вот, ссылку на msdn дал для тех, кто не знал, что это за процессы. Вдумчивое чтение содержимого этой ссылки иногда приводит к просветлению, но явно не у всех. O>В ссылке и в сервисах нет никакого ноухау. Упоминание SERVICE_INTERACTIVE_PROCESS позволяет мне предположить, что вы считаете "неинтерактивность" некоей особой привилегией сервисов, недоступной обычным процессам, но нет.
Я его упоминал в контексте "много чего еще" как реакцию на ваще сообщение про виндовые сервисы.
отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания.
Я говорил, что человек, делающий заявление такого космического масштаба и такой космической же глупости, много про чего не в курсе. Вы прицепились к этому флагу и к интерактивности, но есть много чего еще, что отличает виндовые сервисы от обычных приложений. И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта".
>>> предпочитая тонкий, как вам кажется, троллинг. blp>>Обожемой, да какой тут троллинг? Разве ж это троллинг... O>Обычный грубый троллинг.
Ну ладно, раз обычный и грубый, пусть будет троллинг.
>>>Просто еще одно подтверждение вашей неквалифицированности. blp>>Ужас, буду страдать. O>Нет, не будете. По крайнер мере, не сейчас.
Вот блин, и тут засада.
Здравствуйте, ononim, Вы писали:
O>Ага ага на скрине корневой мессаги очень хорошо видно как эти штатные средства работают с данными сервисами
Они работают, ровно так, как должны . То, что что-то там задевает чьи-то эстетические чувства, когда они видят непонятное сообщение об ошибке, не меняет этого факта
O>Причем это документировано, конечно же: O>
You can't manage all of the per-user service templates services using normal Group Policy management methods. Because the per-user services aren't displayed in the Services management console, they're also not displayed in the Group Policy Services policy editor UI.
: "не должно было разломать существующие админские процессы"
Да, представьте себе — существующих админских процессов, связаных с этими сервисами, еще нет.
Зато есть другие существующие админские процессы, в которые таски из авторана не вписываются. Но откуда про это знать людям, которые, например, никогда не админили сеть, в которой было бы хотя бы несколько десятков тысяч виндовых машин в нескольких доменах.
Здравствуйте, blp, Вы писали: blp>Навскидку, некоторые отличия сервисов от "приложений из авторана" или "тасков" blp>1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
Не вижу причины, по которой нельзя просто запустить приложение после какого-то определяемого системой события. blp>2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe
Ну, так-то приложения тоже можно запускать и останавливать штатными средствами. blp>3. Сервису можно послат сигнал штатными средствами.
Как, впрочем, и приложению. blp>4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)
Ну, вот это, похоже, единственное более-менее заметное функциональное отличие приложения от сервиса blp>заметьте, ничего из того, что выше написано, не является тайными знаниями, которыми обладаю лично я которые нельзя прочитать в МСДН в разделе "сервисы".
Ну вот видите, три из четырёх "отличий" оказываются спорными. Достаточно ли этой единственной причины для того, чтобы оправдать разработку целой отдельной категории приложений?
(Причём всунутую настолько костыльно, насколько возможно. Что не является тайными знаниями, которые нельзя прочитать в МСДН — вам уже указали на то, что с шаблонами сервисов не работает ничего из существующих процессов, кроме прямой правки реестра.)
Или, может быть, есть ещё какая-то причина, о которой просто "забыли" упомянуть в MSDN?
Вот вам после прочтения MSDN очевидны какие-то вещи. Мне (и не мне одному) именно прочтение MSDN делает очевидным то, что это решение сделано впопыхах и абы как. При этом необходимость или хотя бы польза такого решения как раз не очевидна.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hi_octane, Вы писали:
_>а воду из трубы например от непонятных добавок очищаю фильтром
Вы всё ещё кипятите?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinclair, Вы писали: blp>>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д) S>Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
Читаем внимательно: надо не просто сделать запуск одной копии приложения. Надо еще написать всю остальную функциональность, которая уже есть для сервисов. Например, запуск зависимых сервисов, перезапуск сервиса, если он внезапно завершился, правильная очередность остановки и т. д. — по сути вся функциональность SCM. Я понимаю, что в вашем уютном мире ничего, кроме запуска одной копии сервиса и его остановки, не нужно, но в реальном мире не так.
S>В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый. S>Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем
Вы забыли, что таких "приложений" у нас много — получается что весь этот код нам теперь придется тащить в каждое приложение вместо того, чтобы держать его снаружи (как сейчас в SCM). Это создает проблемы с поддержкой и патчами — поэтому адекватные люди, дизайнящие ОС, так не делают.
>бойлерплейта для превращения приложения в сервис.
Добавьте туда еще то, что код per-user сервисов — это отрефактореный код существующих сервисов и драйверов (виндовые драйвера больше поохожи на виндовые сервисы в плане организации кода и интеграции с SCM). Ваше предложение предполагает взять существующие сервисы/драйвера и поменять их архитекутуру, сделав просто приложениями, да еще и впилить в каждое из них кусок логики SCMа для запуска/перезапуска. Улавливаете?
blp>>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает? S>Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION blp>>Как сделать так, чтобы на это мог/не мог повлиять юзер? S>Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications S>Если вам что-то непонятно, то спрашивайте.
Мне как раз все понятно. Это опять эффект Даннинга-Крюгера.
Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
in a critical shutdown, where the user has clicked the Shut down now button in the new Windows UI and applications will no longer be allowed to block shutdown
Best Practices for Handling Shutdown in Windows Vista
... Applications should not block shutdown
>Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню.
Ну вот, еще один. Писал что-то там 17 лет назад, не помнит специфики, следовательно ее нет. Скучно.
blp>>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой. >Не убедили.
Печально. А вроде выглядели адекватно.
S>Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
еще раз — недокументированы новые типы сервисов, как их например самому писать. Тупо эти константы, которые передаются в CreateService в MSDN не описаны. Сами сервисы, что они делают — документированы. Чтобы адекватные люди могли понять, что это за сервисы и как себя ведут.
blp>>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент. S>Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой.
Существующие инструменты прекрасно управляют тем, что есть и вписывается в набор сущностей, которыми они управляют. Я же сказал — отсутсвие красивого красивого GUI для темплейтов серивсов никак не относится к инструментам работы с самими сервисами. Сервисы (не темплейты) так же можно, например, запускать и останавливать, зная их имя. Можно получать список имен сервисов и т. д.
> покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера.
Какой именно из "сервис WpnUserService на машине топикстартера"? Их на машине может быть больше одного. А может быть 0, если на машину топкстартера никто не залогинен. Ответьте на этот вопрос, может быть просветление снизойдет на вас.
>Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.
Скучно.
blp>Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
Сразу предупреждаю, Windows разработку закинул давно.
>>Почему другие могут а здесь не получилось? blp>Другие могут что? что у кого не получилось здесь? И эти люди мне говорят что-то про обтекаемые фразы...
У меня опыт ни раз подтвержденный: Чем умнее человек и чем лучше он понимает тему, тем проще и короче он может донести мысль.
blp>что такое "стандартный способ"? Способ делать что?
Очистить микрософт от гнилых "специалистов", понятно что. Причем так, чтобы они из Микрософта никуда дальше не перескочили. Без заслушивания никчемной воды от никчемных людей. Вот мой ответ, четкий и ясный.
blp>Какой именно один сервис? Обсуждаемых сервисов там существенно больше одного они все имеют свой цикл жизни, могу независимо запускаться и останавливаться. Вы предлагаете какой-то свой адов альтернативный дизайн и думаете, я телепат и пойму, что вы там где видели и что имели в виду.
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, blp, Вы писали:
>>>Почему другие могут а здесь не получилось? blp>>Другие могут что? что у кого не получилось здесь? И эти люди мне говорят что-то про обтекаемые фразы... V_>У меня опыт ни раз подтвержденный: Чем умнее человек и чем лучше он понимает тему, тем проще и короче он может донести мысль.
Соверешнно верно. Еще умные люди умеют внятно формулировать вопросы или не задавать вопросы, когда ответы на них вполне можно найти самостоятельно если просто сформулировать вопрос правильно.
blp>>что такое "стандартный способ"? Способ делать что? V_>Очистить микрософт от гнилых "специалистов", понятно что. Причем так, чтобы они из Микрософта никуда дальше не перескочили. Без заслушивания никчемной воды от никчемных людей.
Поток сознания какой-то. Вас что-то беспокоит и вы хотите об этом поговорить?
>Вот мой ответ, четкий и ясный.
Ваш ответ на вопрос "что такое стандартный способ?" из предыдущего сообщения, которое было про сервисы. Оукеей.
blp>>Какой именно один сервис? Обсуждаемых сервисов там существенно больше одного они все имеют свой цикл жизни, могу независимо запускаться и останавливаться. Вы предлагаете какой-то свой адов альтернативный дизайн и думаете, я телепат и пойму, что вы там где видели и что имели в виду.
V_>Понятно, общение бесполезно. Темой не владеешь.
И вам не хворать!
Здравствуйте, blp, Вы писали:
V_>>Сервис + per-user userspace GUI/headless процесс. blp>Да, тут больше текста, но все равно непонятно. Задача, которую решает юнистек — это много сервисов, каждый из которых per-user-logged-on. blp>Как ваша адова архитектура с одинм сервисом и потенциально несколькими процессами, в это вписывается? Например, как эти процессы корректно шатдаунить, когда юзер делает log off, чтобы они гарантированно успели деинициализироваться?
Сервис содержит в себе контекст пользователя. При закрытии user space app информируется сервис, далее делается необходимый shutdown на уровне сервиса.
Можно и shutdown/startup зависимости добавить с другими, "singleton-kind" сервисами, не вижу в этом проблемы
User-space процессы шатдаунятся стандартным способом (SIGTERM, WM_CLOSE или что-там, без разницы). Что-то критичное, для чего нужно "попридержать" shutdown (buffers flush etc), выполняется в onUserLogOff(userContext), в контексте сервиса.
Здравствуйте, serj.e, Вы писали:
SE>Встречный вопрос. А зачем возможность отключения выведена в MMC?
Это эволюционный отбор. Воинствующая некомпетентность, лезущая что-то отключать, не разобравшись зачем, будет платить за восстановление, благодаря чему либо научится сначала думать, либо станет кормовой базой для эникейщиков по вызову.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Ops>Нет, производители кладут. Ты все добавки перед едой извлекаешь?
Ну если на аналогиях про еду, то некоторые виды еды я просто перестал есть, а воду из трубы например от непонятных добавок очищаю фильтром
Здравствуйте, hi_octane, Вы писали:
_>Ну если на аналогиях про еду, то некоторые виды еды я просто перестал есть, а воду из трубы например от непонятных добавок очищаю фильтром
Т.е. питаешься исключительно самостоятельно выращенным?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
ARK>>Чтобы ответить на этот вопрос, надо знать все уязвимости во всех сервисах. Однако, учитывая, что они постоянно обновляются, ответа на этот вопрос вообще не существует — сегодня 0.0001%, а завтра с новым говнообновлением 90%. ARK>>Чем меньше кода работает (и даже вообще присутствует в любой системе) — тем лучше. Ops>Ну т.е. ты не знаешь, но мнение имеешь.
Ты читать умеешь? Если да, то прочти внимательно еще раз мой пост и постарайся понять, что твой вопрос разумного ответа не имеет.
А то, что любое, пусть и сколь угодно малое, число всегда строго больше нуля — это я знаю точно.
ARK>>Хватает, не хватает — не имеет значения. Бесполезный мусор не нужен. Ops>Почему бесполезный?
Потому что мне он не нужен.
Ops>Например, если его не трогать, то ты завтра не начнешь кричать, что у тебя что-то не работает, греша на всех, кроме себя.
По себе судишь? Лично я не кричу и никого не обвиняю. 70% сервисов отключено.
ARK>>В win 10 нереально. В 7 еще реально. Ops>Нет, это нереально с самого появления многозадачных ОС с фоновыми процессами.
До какой-то степени реально. Но в постоянно обновляемой говносистеме "Windows 10" — совершенно нереально, это верно.
Здравствуйте, AlexRK, Вы писали:
ARK>Ты читать умеешь? Если да, то прочти внимательно еще раз мой пост и постарайся понять, что твой вопрос разумного ответа не имеет.
Т.е. вопрос веры, а не научного подхода? Ок.
ARK>А то, что любое, пусть и сколь угодно малое, число всегда строго больше нуля — это я знаю точно.
Конечно. Но ты же не ходишь везде с молниеотводом, хотя шанс что шарахнет отнюдь не нулевой.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Ops>Т.е. питаешься исключительно самостоятельно выращенным?
В эту игру можно играть вдвоём!
Т.е. ты жрёшь всё подряд не глядя что за продукт берёшь с полки и съедобный ли он вообще?
Скрытый текст
Вот я из всего ассортимента выбираю хорошие продукты, а плохие оставляю на полке магазина. И с сервисами также — нужные мне запущены, остальные валяются где-то на диске.
Но ты продолжай. Мне интересно как будешь дальше выкручиваться…
S>Если следовать аналогии, то сейчас вы рассуждаете как противник пищевых добавок: мол если в продукте есть E330, то "Ой всё, буржуи нас травят!!!".
Начиная с win8 эти добавочки живут своей жизнью и шевелятся когда сами того захотят. То-ли червячки то-ли глисты какие. По-сравеннию с NT4 — реально же "Ой всё, буржуи нас травят!!!".
vsb>По такой логике надо антивирус, фаервол отключать.
Так то в штатном антивирусе за его историю было 5+ RCE при проверке специально сгенерированных файлов, и пачка багов поменьше Microsoft » Windows Defender : Security Vulnerabilities
При чём не знаю как у других, у меня всё что делал этот самый дефендер — так это удалял программульки типа nssm, и блокировал свежескомпилированные экзешники секунд на 30. Ни одного словленного вируса или трояна. Наверное потому что все вирусописатели в обязательном порядке проверяют свои поделия на самом последнем дефендере. Ну и нафига он тогда?
__>Называют себя UnistackSvcGroup
Танцующие инопланетяне, причем из касты неприкасаемых. Даже не представляю какой длины была спаггетина в ланче того мз них, кто решил делать сервисы с рандомными именами.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Ops, Вы писали:
_>>Вот я из всего ассортимента выбираю хорошие продукты, а плохие оставляю на полке магазина. И с сервисами также — нужные мне запущены, остальные валяются где-то на диске.
Ops>Э, нет. Если следовать первоначальной аналогии, продукт тут ОС, а сервисы — это ингредиенты. Ты же, условно, занимаешься выковыриванием изюма из булочек, т.к. изюм не любишь.
Не изюма, а непонятных включений, которые невозможно идентифицировать, как изюм. Может это тушки тараканов, может гнилой юзюм, а может крысиные какашки.
Здравствуйте, Somescout, Вы писали:
S>Если следовать аналогии, то сейчас вы рассуждаете как противник пищевых добавок: мол если в продукте есть E330, то "Ой всё, буржуи нас травят!!!".
Как насчет покушать E123 (родственник Оранж-агента)?
Здравствуйте, vsb, Вы писали:
ARK>>Чтобы ответить на этот вопрос, надо знать все уязвимости во всех сервисах. Однако, учитывая, что они постоянно обновляются, ответа на этот вопрос вообще не существует — сегодня 0.0001%, а завтра с новым говнообновлением 90%.
ARK>>Чем меньше кода работает (и даже вообще присутствует в любой системе) — тем лучше.
vsb>По такой логике надо антивирус, фаервол отключать.
Не держу антивирусов (но иногда прогоняю проверку), апдейты запрещаю, посещваю сомнительные сайты, полет нормальный. Не имею проблем с зависанием Windows от апдейтов.
Здравствуйте, marcopolo, Вы писали:
S>>Если следовать аналогии, то сейчас вы рассуждаете как противник пищевых добавок: мол если в продукте есть E330, то "Ой всё, буржуи нас травят!!!".
M>Как насчет покушать E123 (родственник Оранж-агента)?
Найдёте продукт (разрешённый к продаже) где она используется?
Ops>Нет, это изюм. Пример, кстати, из жизни, недалеко от меня сейчас человек, который изюм не любит, и называет его как раз тараканами. Ну а у любителей все поотключать, превратив систему в ту булку, после выковыривания из нее изюма, свои тараканы в голове: перфекционизм, мания, паранойя, еще что-то, нужное подчеркнуть. И вряд ли им это упрощает жизнь.
Мне как раз пофигистично, лишь бы потрепаться и побрюзжать, не бежать же поперек поезда, жизнь коротка и так.
Здравствуйте, AlexRK, Вы писали:
Ops>>А зачем тебе их отключать? Цель какая?
ARK>Уменьшить площадь потенциальной атаки. Не тратить попусту ресурсы. Не позволять ОС жить своей жизнью.
Здравствуйте, _ilya_, Вы писали:
__>Винда конечно уже не та, но чтобы так откровенно вредосоны доставлять "клиентам". Лучше бы просто застрелились.
Я б начал с более глубокого вопроса: а что, без десятки — никак? Юзаю Win7 и там всё работает, никто не лезет обновляться, никакого самоуправства на моём ПК.
Я понимаю, что есть новые ноуты, которые не имеют дров к семёрке, но всё равно можно попробовать поставить — вдруг заработает? А если и отвалится какой-нть блюпуп — так и фиг с ним!
Здравствуйте, hi_octane, Вы писали:
S>>Вот я и о том же: вы даже не пытаетесь разбираться в теме, но мнение имеете. _>Ты сейчас на полном серьёзе утверждаешь что человек который прошёлся по сервисам, почитал про них, половину отрубил, и полностью доволен результатом "не пытается разбираться в теме"? А тот кто поставил то что поставилось, и забил болт на то что у него безостановочно что-то пишется на винт, чем-то занято одно ядро CPU, и постоянно висят коннекты незнамо куда — значит в теме разбирается??
"Вот и вы говорите" (с).
Я могу судить только по тому, что вы пишите в теме, и по этом комментариям ваши знания тянут на уровень "скачать суперскрипт для отключения слежки в Windows и запустить из под админа". Так что "я всё изучил и узнал" вот вообще не вяжется с этим, поэтому рискну не поверить вашим словам.
CC>Не, это просто эти клованы решили что надо каждому юзеру запускать свою копию сервиса, чтоб если они там опять дыру забудут то дальше юзера вылезти не получилось.
Но зачем тогда именно сервис? Я аналогичную проблему решал запуском per-user-logon апликухи из сервиса: phandlerFunctionEx SERVICE_CONTROL_SESSIONCHANGE
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Sinclair, Вы писали:
S>Вот если честно, я иногда понимаю этих людей. S>Приходишь на работу, открываешь ноут — а там открытие новой табы в FF занимает 15 секунд, а паузы между появлениями буков при наборе текста в аутлуке видны визуально. S>Смотришь в таск менеджер, а там — вакханалия. Три ядра из четырёх заняты каким-то блоатваром, типа Касперского (который тудычит файлуху), Цисковского какого-то антималвара (надо же проверить, не приехало ли по сети что-то вредное), и таниум над всем этим, чтобы наши корпоративные админы могли делать мне хорошо. Плюс ещё какой-нибудь Intel Zero Config Service периодически начинает жрать такты и память, как не в себя.
Осталось только понять, что из этого зоопарка часть винды, а что — нет. По моему опыту, из того что действительно относится к винде, и может замедлять работу или создавать сложности — это только антивирус, да и он, видимо, в твоем случае заменен касперским. А все остальное, что идет с системой искаропки, ничего такого из описанного не творит, по крайней мере чтобы это было заметно. Ну разве что ngen иногда после установки или обновления софта напрягается (хотя последнее время не замечал этого), но это вполне оправданная нагрузка.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Осталось только понять, что из этого зоопарка часть винды, а что — нет. По моему опыту, из того что действительно относится к винде, и может замедлять работу или создавать сложности — это только антивирус, да и он, видимо, в твоем случае заменен касперским. А все остальное, что идет с системой искаропки, ничего такого из описанного не творит, по крайней мере чтобы это было заметно. Ну разве что ngen иногда после установки или обновления софта напрягается (хотя последнее время не замечал этого), но это вполне оправданная нагрузка.
Ну вот да — у меня весь блоатварь либо корпоративный, либо от вендоров железа. И это я ещё выбрал машинку с интегрированной видяхой — потому что софт от видеоделов просто днище, он мне ещё на семёрке всю кровушку выпил.
А вот то, на что жалуется ТС — это как раз часть винды. Я так понимаю, что у меня её нет, т.к. не пользуюсь ни встроенным мейлом, ни мессенджером.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ononim, Вы писали:
blp>>>>https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows O>>>Оксюморон какойто. Сервисы — процессы отвязанные от юзерской сессии. И чем это better чем таски да и банальный авторан?.. blp>>https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect O>Да причем тут даннинг крюгер когда имеет место явный костыль.
O>Изначально были юзерские процессы и сервисы. Отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания.
Ооооо, блин. Какое у вас глубокое понимание виндовой архитектуры, аж плакать хочется. Про флаг SERVICE_INTERACTIVE_PROCESS вы не в курсе, про много чего еще, видимо, тоже.
O>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше?
Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты.
Здравствуйте, ononim, Вы писали:
O>>>Изначально были юзерские процессы и сервисы. Отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания. blp>>Ооооо, блин. Какое у вас глубокое понимание виндовой архитектуры, аж плакать хочется. Про флаг SERVICE_INTERACTIVE_PROCESS вы не в курсе, про много чего еще, видимо, тоже. O>Я про этот флаг узнал лет 20 назад, возможно вас тогда еще и в проекте не было.
Если вы про него узнали 20 лет назад, а не пару минут назад, то видимо, потом забыли. Говорить про от, что "сервисы, не привязаные к юзерской сессии" — суть сервисов можно только очень ограниченно понимая архитетуру виндов.
>И тогда его установка приводила к тому что гуй сервиса действительно был интерактивен. Потом его сломали сервисы оказались на отдельной сессии, но подкостылили мониторингом созданмя видимых top-level окон к той сессии.
Спешное гугление и чтение МСДНа. Лучше поздно, чем никогда. Подумайте еще немного, может быть до вас дойдет, зачем же все-таки нужна это функциональность, которую сломали, почему ее сломали и кто и зачем ее сломал.
O>>>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше? blp>>Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты. O>Потому что для решения их задачи был уже и не один способ помимо того чтоб сломать изначальную архитектуру.
"Зачем", а не "почему". Вы не ответили пока на этот вопрос.
Здравствуйте, ononim, Вы писали:
O>>>Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда. blp>>Ну расскажите, поделитесь, что же вам было понятно. Флаг не работает (ну или "не так работает") начиная с Висты. O>Я дал достаточно информации чтобы тот кто знает про то как этот флаг не работает понял что я это тоже знаю.
К сожалению, понять, что именно вы знаете, а что спешно нагуглили, ни по каким приведенным вам ответам нельзя. Так что особо не старайтесь.
> Если вы этого не поняли — значит вы тоже неквалифицированный разработчик.
Нет, я просто не могу поверить вам наслово, когда вы бьете себя пяткой в грудь и говорите про то, что знали про что-то 20 лет назад. Может, и правда знали, но забыли. Или знали, но не понимали нормально.
blp>>Ну я ж и говорю — типичный эффект Даннинга-Крюгера. Вы-то лучше всех знаете, как можно было сделать. И в вашем уютном мирке разницы между автораном и сервисами, запускаемыми в контексте юзерской сессии, нету, потому что вы ее не видите. А то, чего вы не видите, очевидно, не существует. O>Ну то есть технической информацией и пониманием сути проблемы вы не располагаете
Почему не располагаю, вполне располагаю. Вот, ссылку на msdn дал для тех, кто не знал, что это за процессы. Вдумчивое чтение содержимого этой ссылки иногда приводит к просветлению, но явно не у всех.
> предпочитая тонкий, как вам кажется, троллинг.
Обожемой, да какой тут троллинг? Разве ж это троллинг...
>Просто еще одно подтверждение вашей неквалифицированности.
Ужас, буду страдать.
O>>Ну то есть технической информацией и пониманием сути проблемы вы не располагаете blp>Почему не располагаю, вполне располагаю. Вот, ссылку на msdn дал для тех, кто не знал, что это за процессы. Вдумчивое чтение содержимого этой ссылки иногда приводит к просветлению, но явно не у всех.
В ссылке и в сервисах нет никакого ноухау. Упоминание SERVICE_INTERACTIVE_PROCESS позволяет мне предположить, что вы считаете "неинтерактивность" некоей особой привилегией сервисов, недоступной обычным процессам, но нет. SERVICE_INTERACTIVE_PROCESS просто говорит о том что процесс сервиса должен запускаться на оконной станции WinSta0, если его нет — он запускается на WinStationService-блаблабла. Так вот, _любой_ процесс может создать оконную станцию и работать в ней, вызвав SetProcessWindowStation. И стать таким же неинтерактивным как юзермодный-сервис-без-флага-SERVICE_INTERACTIVE_PROCESS.
>> предпочитая тонкий, как вам кажется, троллинг. blp>Обожемой, да какой тут троллинг? Разве ж это троллинг...
Обычный грубый троллинг. Вот 20 лет назад в я IRC примерно так же троллил, да, правда термина тогда такого еще не было :
blp>К сожалению, понять, что именно вы знаете, а что спешно нагуглили, ни по каким приведенным вам ответам нельзя. Так что особо не старайтесь.
blp>Нет, я просто не могу поверить вам наслово, когда вы бьете себя пяткой в грудь и говорите про то, что знали про что-то 20 лет назад. Может, и правда знали, но забыли. Или знали, но не понимали нормально.
>>Просто еще одно подтверждение вашей неквалифицированности. blp>Ужас, буду страдать.
Нет, не будете. По крайнер мере, не сейчас.
Как много веселых ребят, и все делают велосипед...
blp>отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания. blp>Я говорил, что человек, делающий заявление такого космического масштаба
Это не космический масштаб, это достаточно очевидная вещь.
blp>и такой космической же глупости, много про чего не в курсе.
Грубо.
blp>Вы прицепились к этому флагу и к интерактивности, но есть много чего еще, что отличает виндовые сервисы от обычных приложений.
Это вы первый прицепились к этому флагу. Я лишь объяснил что в нем нет ничего особенного. Как и в остальных особенностях сервисов. Я (будучи архитектором) разрабатывал систему user mode application virtualization которая в том числе умела запускать сервисы как процессы, эмулируя весь SCM API. Но да, это было задолго до десятки.
blp>И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта".
Я ж говорю — в тиме unistack не нашлось того кто знал как сделать в рамках своей задачи. Попросили core-team придумать чтонить этакое. Там не нашлось того что мог бы реализовать адекватным решением, добавив в таскшедулер чего им там хотелось или еще что. Сделали костыль, с сервисами с рандомно генеренными именами.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
blp>>отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания. blp>>Я говорил, что человек, делающий заявление такого космического масштаба O>Это не космический масштаб, это достаточно очевидная вещь.
Да я не спорю, в котексте ограниченных знаний она явно очевидна. Ссылку на статью в википедии про механизм этого эффекта я уже приводил.
blp>>Вы прицепились к этому флагу и к интерактивности, но есть много чего еще, что отличает виндовые сервисы от обычных приложений. O>Это вы первый прицепились к этому флагу.
Я его привел для прмиера того, что не вписывается в наивную картину. Прицепились к нему вы. >Я лишь объяснил что в нем нет ничего особенного. Как и в остальных особенностях сервисов.
Нету ничего особенного, да. Просто особенности есть. И когда в особенностях детально разбираешься, становится понятно, почему нельзя взять и запихать сервисы в авторан. А так — да, ничего особенного.
>Я (будучи архитектором) разрабатывал систему user mode application virtualization которая в том числе умела запускать сервисы как процессы, эмулируя весь SCM API. Но да, это было задолго до десятки.
Во-во. Эмуляция SCM API. Для виртуализации чего-то там, что в ряде случаев внезапно почему-то работает не так, когда виртуализируется. Впрочем по ответам было какбэ понятно.
blp>>И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта". O>Я ж говорю — в тиме unistack не нашлось того кто знал как сделать в рамках своей задачи. Попросили core-team придумать чтонить этакое. Там не нашлось того что мог бы реализовать адекватным решением, добавив в таскшедулер чего им там хотелось или еще что. Сделали костыль, с сервисами с рандомно генеренными именами.
А, я понял. У вас LUID в качестве части видимого имени сервиса вызывает такие эмоции. Ну бывает, чо.
blp>>>И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта". O>>Я ж говорю — в тиме unistack не нашлось того кто знал как сделать в рамках своей задачи. Попросили core-team придумать чтонить этакое. Там не нашлось того что мог бы реализовать адекватным решением, добавив в таскшедулер чего им там хотелось или еще что. Сделали костыль, с сервисами с рандомно генеренными именами. blp>А, я понял. У вас LUID в качестве части видимого имени сервиса вызывает такие эмоции.
Само решение сделать вид сервисов, привязанных к юзерской сессии — стратегический косяк, впрочем далеко не первый в винде. А UID в имени — это тактический косяк. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот. Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей. Грустно все это, за державу винду обидно. Впрочем тому тоже есть причины. Микрософту винда не нужна, но это тема уже совершенно иного срача.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
blp>>А, я понял. У вас LUID в качестве части видимого имени сервиса вызывает такие эмоции. O>Само решение сделать вид сервисов, привязанных к юзерской сессии — стратегический косяк
эх. Что в лоб, что по лбу.
>. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот.
Комплексные косяки МСа — это фичи, например, Висты, которые дизайнились идиотами, не работали и потом были выпилены и задепрекейчены, а их архитекторы — задемоучены или совсем убраны из компании. То, что вы видите — это как раз работающая реализация чего-то, что требовало обратной совместимости и не должно было разломать существующие админские процессы.
>Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей.
А, ну вот с этого и надо было начинать.
>Микрософту винда не нужна, но это тема уже совершенно иного срача.
В целом, Микрософту не нужен этот багаж liability по поддержанию совместимости с кодом и процессами, написанным 20 лет назад (и как следствие — адски сложная архитектура чего угодно внутри винды), и он стремительно от него избавляется. Но деньги МСу платят в том числе и за эту совместимость.
>>. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот. blp>Комплексные косяки МСа — это фичи, например, Висты, которые дизайнились идиотами, не работали и потом были выпилены и задепрекейчены, а их архитекторы — задемоучены или совсем убраны из компании. То, что вы видите — это как раз работающая реализация чего-то, что требовало обратной совместимости и не должно было разломать существующие админские процессы.
Дада, 'оно работает', а больше ничего и не нужно, да?
>>Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей. blp>А, ну вот с этого и надо было начинать.
Вот в линухе как раз такого полно. Там все так пишут. В винде лучше. Было. Теперь, наверное, линуксоидов набрали на работу.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
>>>. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот. blp>>Комплексные косяки МСа — это фичи, например, Висты, которые дизайнились идиотами, не работали и потом были выпилены и задепрекейчены, а их архитекторы — задемоучены или совсем убраны из компании. То, что вы видите — это как раз работающая реализация чего-то, что требовало обратной совместимости и не должно было разломать существующие админские процессы. O>Дада, 'оно работает', а больше ничего и не нужно, да?
Оно не просто работает, оно работает на миллионах сценариев, о существовании которых среднестатистиеский красноглазик-линуксоид, ничего кроме веб-серверов в жизни не видевший, и не подозраевает.
>>>Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей. blp>>А, ну вот с этого и надо было начинать. O>Вот в линухе как раз такого полно. Там все так пишут.
В линухе всего полно.
>В винде лучше. Было. Теперь, наверное, линуксоидов набрали на работу.
В винде по-другому. Я не сказал бы, что "лучше" применимо. Это как сравнивать что лучше — БТР или Мерседес.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот если вы разобрались, то напишите простым языком прямо сюда результаты ваших разборок.
С моей точки зрения, писать очевидные после прочтения МСДН вещи довольно скучно (хотя можно).
Особенно скучно писать их людям, которые верут себя так, будто они и так лучше знают, как что нужно дизайнить.
> Ваши намёки на то, что вы знаете больше, чем собеседник, выглядят плохо.
Возможно. Собеседники сходу встающие в позу "ну посмотрите, какие криворукие это дизайнили и имплементили", выглядят по-моему, хуже.
Навскидку, некоторые отличия сервисов от "приложений из авторана" или "тасков"
1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe
3. Сервису можно послат сигнал штатными средствами.
4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)
заметьте, ничего из того, что выше написано, не является тайными знаниями, которыми обладаю лично я которые нельзя прочитать в МСДН в разделе "сервисы".
blp>1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
Обычный процесс тоже можно не прописывать в авторан (любым из указанных ранее способов)
blp>2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe blp>3. Сервису можно послат сигнал штатными средствами. blp>4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)
Ага ага на скрине корневой мессаги очень хорошо видно как эти штатные средства работают с данными сервисами
Причем это документировано, конечно же:
You can't manage all of the per-user service templates services using normal Group Policy management methods. Because the per-user services aren't displayed in the Services management console, they're also not displayed in the Group Policy Services policy editor UI.
: "не должно было разломать существующие админские процессы"
И это действительно, только исходя из чтения мсдн. Какие там еще есть незадокументированные косяки в реальности . Надеюсь хотябы поддержку COM/AppID=LocalService сделали нормальную, или оно тоже глючит? Это пожалуй единственное, что могло бы слегка оправдать существование этого костылепеда.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, blp, Вы писали: blp>>Навскидку, некоторые отличия сервисов от "приложений из авторана" или "тасков" blp>>1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства) S>Не вижу причины, по которой нельзя просто запустить приложение после какого-то определяемого системой события.
Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
blp>>2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe S>Ну, так-то приложения тоже можно запускать и останавливать штатными средствами.
это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает? Как сделать так, чтобы на это мог/не мог повлиять юзер?
blp>>4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен) S>Ну, вот это, похоже, единственное более-менее заметное функциональное отличие приложения от сервиса
Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
S>Ну вот видите, три из четырёх "отличий" оказываются спорными.
это они вашей точки зрения спорные.
>Достаточно ли этой единственной причины для того, чтобы оправдать разработку целой отдельной категории приложений?
Нет, недостаточно. Причин больше, да и привиденные мной причины отметать не получится.
S>Или, может быть, есть ещё какая-то причина, о которой просто "забыли" упомянуть в MSDN?
забыли упомянуть что? Эти новые типы сервисов (USER_OWN_PROCESS / USER_SHARE_PROCESS TEMPLATE/INSTANCE — https://github.com/processhacker/processhacker/blob/master/phlib/svcsup.c) — они недокументированные. В виндах много чего недокументированного, что именно вас удивляет?
>с шаблонами сервисов не работает ничего из существующих процессов, кроме прямой правки реестра.
шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент. Инстансы этих шаблонов — вполне себе сервисы и с ними инструменты работают, как написано в документации.
Если весь сыр-бор от того, что МС не сделал красивый гуй для редактирования шаблонов — то да, это конечно страшная трагедия и несоменено сигнализирует о кривизне чьих-то рук.
S>Вот вам после прочтения MSDN очевидны какие-то вещи. Мне (и не мне одному) именно прочтение MSDN делает очевидным то, что это решение сделано впопыхах и абы как. При этом необходимость или хотя бы польза такого решения как раз не очевидна.
Кому очевидна, кому не очень. Вы по крайней мере не кидаетесь делать заявления космического масштаба и космической же глупости, не разобравшись.
Здравствуйте, Vetal_ca, Вы писали:
V_>Сразу предупреждаю, Windows разработку закинул давно.
V_>Тупой вопрос: почему нельзя по следующей схеме: V_>system-сервис <-> per-user-app ?
Да можно как угодно. Можно в гамаке и стоя, можно вверх ногами.
V_>Почему per-user-service с "граблями" ?
Потому что это изначально сервис, которому сделали просто несколько инстансов по числу юзерских сессий, а не приложение. Сделать из существующих сервисов приложения и написать повторно все, что нужно, чтобы их запускать / трекать как можно прямо сейчас сервисы в разы геморройнее чем сделать per-user service.
Здравствуйте, blp, Вы писали:
blp>Да можно как угодно. Можно в гамаке и стоя, можно вверх ногами.
Это не ответ. Или объясни без мути и обтекаемых фраз или признай, что не способен. Неужели ты думаешь, что такое действо я в первый раз вижу?
blp>Потому что это изначально сервис, которому сделали просто несколько инстансов по числу юзерских сессий, а не приложение. Сделать из существующих сервисов приложения и написать повторно все, что нужно, чтобы их запускать / трекать как можно прямо сейчас сервисы в разы геморройнее чем сделать per-user service.
То есть, костыль? Почему другие могут а здесь не получилось? Только без нубовского надувания щек, для меня это как шоу сельского призывника перед психиатром призывной комиссии.
В чем принципиальная невозможность написать стандартным способом в данном конкретном случае? Один сервис + per user app.
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, blp, Вы писали:
blp>>Да можно как угодно. Можно в гамаке и стоя, можно вверх ногами.
V_>Это не ответ.
Это ответ. Вы спросили "почему нельзя". Вопрос неверный потому что можно. Можно в гамаке и стоя, можно вверх ногами, но удобнее все-таки в кровати.
blp>>Потому что это изначально сервис, которому сделали просто несколько инстансов по числу юзерских сессий, а не приложение. Сделать из существующих сервисов приложения и написать повторно все, что нужно, чтобы их запускать / трекать как можно прямо сейчас сервисы в разы геморройнее чем сделать per-user service.
>Почему другие могут а здесь не получилось?
Другие могут что? что у кого не получилось здесь? И эти люди мне говорят что-то про обтекаемые фразы...
>Только без нубовского надувания щек, для меня это как шоу сельского призывника перед психиатром призывной комиссии. V_>В чем принципиальная невозможность написать стандартным способом в данном конкретном случае?
что такое "стандартный способ"? Способ делать что?
>Один сервис + per user app.
Какой именно один сервис? Обсуждаемых сервисов там существенно больше одного они все имеют свой цикл жизни, могу независимо запускаться и останавливаться. Вы предлагаете какой-то свой адов альтернативный дизайн и думаете, я телепат и пойму, что вы там где видели и что имели в виду.
V_>Четко и по теме, или никак.
Баюс-баюс.
Здравствуйте, Vetal_ca, Вы писали:
V_>Но ты, надув щеки создавал видимость знания. Ошибся, каюсь, не стоило тратить время.
Вы же уже один раз ушли, громко хлопнув дверью. Зачем возвращаетесь?
V_>Все что ты донес, что с сервисами хаос и непонимание.
Несомненно. Вот у некоторых людей в голове — хаос и непонимание про сервисы. Некоторые из этих людей фонтанируют идеями про то как можно без сервисов все сделать.
>Плюс куча не специалистов с надутыми щеками крутятся у умирающего трупа Windows. Ничего нового.
Вот интересно, вы себя к кому относите? Если вы не крутитесь вокруг умирающего трупа (умрающий труп — это вообще прекрасная фигура речи, да. Труп, умирающий. Повторно, видимо), зачем вы так активно беседуете на тему архитектурных решений в windows? Вас они почему волнуют?
blp>>Поток сознания какой-то. Вас что-то беспокоит и вы хотите об этом поговорить? V_>Таким со мной некомфортно, да. Это нормальная реакция. Отбраковка работает.
Каким с вами некомфортно? Какая отбраковка? Постарайтесь почетче сформулировать мысль, а то собеседник может не заметить, как именно вы хотели на него наехать — слишком витиевато получается
V_>Сервис + per-user userspace GUI/headless процесс.
Да, тут больше текста, но все равно непонятно. Задача, которую решает юнистек — это много сервисов, каждый из которых per-user-logged-on.
Как ваша адова архитектура с одинм сервисом и потенциально несколькими процессами, в это вписывается? Например, как эти процессы корректно шатдаунить, когда юзер делает log off, чтобы они гарантированно успели деинициализироваться?
Здравствуйте, Vetal_ca, Вы писали:
V_>User-space процессы шатдаунятся стандартным способом (SIGTERM, WM_CLOSE или что-там, без разницы). Что-то критичное, для чего нужно "попридержать" shutdown (buffers flush etc), выполняется в onUserLogOff(userContext), в контексте сервиса.
Ну то есть вместо нескольких сервисов на юзера, никак не связаных друг с другом для разных юзеров, мы имеем один сервис на систему, который хранит в себе стейт всех юзеров. Это не есть решение той самой задачи, которую решает юнистек — а именно полностью независимые друг от друга сервисы для разных юзеров.
Если решать другую задачу, решение можно придумать любое.
Например, можно сказать, что задачей было нарисовать лошадку и нарисовать лошадку.
Здравствуйте, blp, Вы писали:
blp>Здравствуйте, Vetal_ca, Вы писали:
V_>>User-space процессы шатдаунятся стандартным способом (SIGTERM, WM_CLOSE или что-там, без разницы). Что-то критичное, для чего нужно "попридержать" shutdown (buffers flush etc), выполняется в onUserLogOff(userContext), в контексте сервиса. blp>Ну то есть вместо нескольких сервисов на юзера, никак не связаных друг с другом для разных юзеров, мы имеем один сервис на систему, который хранит в себе стейт всех юзеров.
Да, это system wide service по определению.
blp>Это не есть решение той самой задачи, которую решает юнистек — а именно полностью независимые друг от друга сервисы для разных юзеров.
Вот это и есть криворукость. Системный сервис (daemon, и т.д.) это не per user entity. Вот так наберут неквалифицированных людей. А потом они про лошадок лепечут перед тем, как вылететь пинком под зад.
blp>Если решать другую задачу, решение можно придумать любое.
Я уже давно считаю массовые увольнения благом. Не хватающим для некоторых контор вокруг меня
blp>Например, можно сказать, что задачей было нарисовать лошадку и нарисовать лошадку.
Здравствуйте, Vetal_ca, Вы писали:
blp>>Это не есть решение той самой задачи, которую решает юнистек — а именно полностью независимые друг от друга сервисы для разных юзеров.
V_>Вот это и есть криворукость. Системный сервис (daemon, и т.д.) это не per user entity. Вот так наберут неквалифицированных людей. А потом они про лошадок лепечут перед тем, как вылететь пинком под зад.
А, ну то есть вместо решения конкретной задачи, с которой начался этот срач ("чем эти сервисы лучше, чем таски или банальный авторан") мы теперь решаем другую (сервис оставляем, но он у нас один, а какую-то часть логики пихаем в приложения) — рисуем лошадку.
И когда нас пытаются вернуть к суровой реальности, в которой нужен сервис на юзерскую сессию (работающий под аккаунтом юзера и, например, блокирующий логофф, пока сервисы не завершится), мы лепечем что-то про "неквалицифированных людей".
Если вы на своей работе так же задачи решаете — меняете задачу на более вам удобную и потом придумываете как ее решить, какому-то работадателю сильно не повезло
blp>>Если решать другую задачу, решение можно придумать любое. V_>Я уже давно считаю массовые увольнения благом. Не хватающим для некоторых контор вокруг меня
Вы явно хотите мне что-то сказать, но постоянно от вас одни намеки. Скажите уже прямо.
Здравствуйте, Sinclair, Вы писали: S>Ну вот, уже лучше. Видите, насколько полезнее писать конкретные вещи
Полезно конкретно формулировать вопросы и иногда читать MSDN после корректных формулировок.
S>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем.
Потому что задача — сделать per-user сервис. Работающий под аккаунтом юзера, но имеющий свойства сервиса — например, блокирующий логофф/шатдаун до своего завершения. Тут особо одаренные люди уже кинулись менять задачу на более удобную им и радостно показывать, как они умеют ее лучше решать.
S>Эмм, то есть вот эти вот per-user сервисы когда-то были system wide, а потом их решили перевелосипедить на per-user? S>Это интересно. Можете рассказать, зачем это было сделано?
Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода.
per-user сервисы нужны, чтобы, например, изолировать юзерские данные специфичные для этого сервиса друг от друга, что физически невозможно, когда данные разных юзеров лежат памяти одного процесса. Также, например, per-user сервисы можно запускать в security-контексте того юзера, для которого они созданы / запущены и с правами этого юзера, а не с системными правами.
S>Очень хорошо. Почему бы такие вещи не доверить system-wide сервису?
Что в лоб, что по лбу. System-wide сервис никак не сможет заблокирвать logoff (он не может останавливаться на logoff eventе) — он максимум может заблокировать shutdown при своей остановке. Ну очевидно же.
>Заодно разрешаем пользователю сделать logoff прямо сейчас, не вынуждая его ждать минуту, пока там сервис соизволит завершить асинхронные задачи. S>Shutdown — дело другое, можно и подождать.
а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу.
S>Концепция сайтов, подобных этому, построена не только на тех, кто хочет научиться, но и на тех, кто хочет научить. Вы хотите, чтобы те посетители, которые знают больше вас, рассказывали вам что-то интересное.
Я с этим в целом не спорю. Адекватным людям приятно рассказать что-то интересное.
>Если они будут придерживаться вашей стратегии ведения дискуссии, то вы так и не прочтёте ничего нового.
Если собеседники начинают разговоры с заявлений "посмотрите, какие идиоты! Смотрите какой я умный!", у людей, которым очевидна их глупость, ничего, кроме желания поглумиться, они не вызывают. Это как что-то доказывать антипрививочникам или плоскоземельщикам.
>А значит что? Значит всегда надо быть готовым что-то рассказать самому — тем, кто знает меньше вас. S>Логика понятна?
Ага. Я — всегда готов, многим людям просто не нужно многое из того, что я могу рассказать (судя по их ответам) Им нужно самоутвердиться и рассказать, какие они были крутые архитекторы 20 лет назад.
S>Давайте попробуем угадать: эти сервисы — какое-то зло, которое лучше не давать разрабатывать рядовым разработчикам.
Непонятно, почему вы так решили. Но это вполне вписывается в религиозную картину "МС-империя зла", и соотвественно, творит зло. С ней невозможно спорить.
>Если так, то отсутствие документации по ним — это норм, вменяемое решение. Отсутствие гуя — это намеренный, здравый ход, нацеленный на промоушен обновлённых курсов MCSA.
Ну ок.
S>Но если такой тип сервисов — это полезная штука, полноценная часть экосистемы винды, то задокументировать их хотели, но релиз был поспешным, и задокументировать их просто не успели.
Скорее всего
S>Третий вариант — никакого осознанного решения не апдейтить тулзы и документацию не было, просто в Редмонде окончательно развалился менеджмент, и межкомандная координация осталась где-то там, в тех временах, когда я ещё писал сервисы под винду. S>Вы за какой вариант выступаете?
За второй: чтобы не делать релизы винды раз в 3-4 года (а "нормально винды" раз в 5-6 лет), как раньше, а быть on par с вещами вроде андроида, фичи выпускают чаще, документации по ним может не быть какое-то время.
S>Отличный вопрос. Давайте для начала тот, который относится к текущей сессии пользователя.
а что сразу не "тот, который был запущен в Рамадан в 2019 году"? Может вы еще придумаете каких-то ограничений, про которые не в курсе существющие инструменты, которые работают с именами сервисов? Есть способ получить список сервисов с их именами и описаниями. Если способ перезапустить сервис по имени. Способа "найти сервис, который относится к текущей сессии пользователя" не было и нет. Равно как и "найти сервис который был запущен в определенную фазу луны"
blp>>Скучно. S>
Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно.
Здравствуйте, Vetal_ca, Вы писали:
blp>>Если вы на своей работе так же задачи решаете — меняете задачу на более вам удобную и потом придумываете как ее решить, какому-то работадателю сильно не повезло
V_>Видишь ли, я ставлю задачи и делаю реальность сам.
А, отлично. Так и запишем — живет в собственной реальности, разговаривать с осторожностью
> Вместо того чтобы подстраиваться под косяки других.
Хорошо вам.
>У меня это получается, выхлоп хороший и, как результат, доверие и власть "делать реальность" мне даны.
Отлично, рад за вас. Расскажите больше, чем вы занимаетесь, что это за доверие, кто вам его дал и как вы его применяете. Очень интересно, да и вам явно очень хочется, но повода нет.
V_>Это называется самореализацией и это мне нравится.
Очень хорошо. Зачем вы занимаетесь еще самутвеждением на форуме RSDN тогда? Доказываете мне тут что-то, постоянно пытаясь намекнуть и т д?
V_>Повышай квалификацию и не придется разгребать г-но из-под неквалифицированных индусов. Которые тебе дают задачи и у тебя нет иных вариантов, кроме как подчиниться
Ну вот опять.
Вы явно хотите мне что-то сказать, но постоянно от вас одни намеки. Скажите уже прямо.
Здравствуйте, 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, который я наблюдаю в своей карьере.
Ваше экспертное мнение очень важно, продолжайте вести наблюдения!
Здравствуйте, 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>Да, и несмотря на три десятка сообщений в ветке простые вопросы так и не были отвечены: 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>А и хрен бы на неё. Wine прогрессирует семимильными шагами. Не успеваешь следить за новыми фичами. DX12, Vulkan, DXVK. Все больше и больше поддерживаемых игорей. Фотожопа тоже, по слухам, норм работает с GPU–ускорением.
Оно если и прогрессирует то как то не там где я его использую.
Пойду, почитаю другие темы...
Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.
В науке есть множество дисциплин, расчеты в которых либо неимоверно сложны, либо вообще нерешаемы на текущий момент — какие-нибудь уравнения Навье-Стокса, например, первое, что в голову пришло. Ответ на твой мудрейший вопрос, наверное, не настолько сложен, но он далеко за пределами возможностей не только одного человека, но и научного института. Для ответа необходимо знать полный набор уязвимостей ОС и полный набор существующих на данный момент эксплуататоров этих уязвимостей. Теоретически узнать это возможно, но практически — вряд ли. И самое главное, что это бессмысленное занятие, потому что, во-первых, ОС и вирусы обновляются непрерывно, а во-вторых, чисто статистически уязвимости есть в любом коде и отключение этого кода снижает их количество на некоторое число, большее нуля. Если тебе эти элементарные вещи непонятны, то уже мне непонятно, как ты можешь работать программистом (если ты программист, конечно).
Ну вроде теперь поработаем. Все эти девелоперские тулы опять разом стартуют, открываются проекты, вроде сейчас пальчики наши застучат по клаве…
), хоть майнить койны.
