From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dumalogiya.ru; s=mail; t=1610887862; bh=U6Ui6KRQrcaaHnWQRPHoJenGcUL2cnkp7oBLKyn+u28=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=MmsrE6ExG35wRKdgUC6kVngFcPgGHsxZDebN6oIDJ6F0yEjrTKkrFKIWXxikge1+3 XG+ZPdXGWiy6ROtTPm5GXnQDGOyrFI2A1WaIwoPmHvu6q7iMFeiMR8JAWVIUUKm1nW +UeG1MukyhrtbpoYWeusU8YlQAy+Ibb8vSmrB4jE= Authentication-Results: myt5-c177f9f90ce4.qloud-c.yandex.net; dkim=pass header.i=@dumalogiya.ru To: sisyphus@lists.altlinux.org References: <20210113113825.GI27847@imap.altlinux.org> <20210115175757.GJ3784@imap.altlinux.org> From: =?UTF-8?B?0JzQuNGF0LDQuNC7INCd0L7QstC+0YHQtdC70L7Qsg==?= Message-ID: <37302daa-b85c-5f1b-e1b5-af2db616b10c@dumalogiya.ru> Date: Sun, 17 Jan 2021 15:51:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210115175757.GJ3784@imap.altlinux.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [sisyphus] =?utf-8?b?0KfRgtC+INC00LXQu9Cw0YLRjCDRgSBzeXN0ZW1kPw==?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 12:51:04 -0000 Archived-At: List-Archive: List-Post: 15.01.2021 20:57, Michael Shigorin пишет: > On Wed, Jan 13, 2021 at 03:32:15PM +0300, Михаил Новоселов wrote: >>>> systemd так и задуман, чтоб КАЖДАЯ перезагрузка проходила с >>>> новым порядком запуска юнитов с непредсказуемым результатом? >>> Ну не умеют эти "архитехтуры" головой думать. Умели бы -- хоть >>> проверку ацикличности графа делали бы при изменении вводных, >>> чтоб проблемы вылезали по возможности не при запуске/останове, >>> а тогда, когда с ними получается что-то сделать разумным >> Затыки возникают из-за ошибок уже после запуска сервиса или их >> слишком долгой работы, разве проверка на ацикличность поможет >> это избежать? > Затыки возникают из-за головотяпства. Яркая иллюстрация -- > искуственно созданные проблемы при отсутствующих блочных > устройствах (свопе, например). Казалось бы, какое твоё дело, > пиналки сервисов -- когда свалится (если свалится), вот там > и надо смотреть; но нет, надо заблокировать процесс на минуты > без возможности сказать "проехали". Есть такое, особенно когда ждет завершения графической сессии, а вернуться в нее уже нельзя. В целом на мой взгляд такое поведение имеет смысл, ведь, например, гипервизор может получить сигнал и начать выключать виртуалки, что не моментально происходит, вполне разумно его подождать, а потом прибить SIGKILL'ом, если сам не завершится. sd_notify полезная штука, сервис может сообщить systemd, что он действительно начал выключаться, к примеру. Что касается задержки при неудачном монтировании устройств, оно же, по-моему, пытается его смонтировать много раз, какой-то смысл в этом есть, мне кажется. В общем для таких недостатков надо придумывать решения и обсуждать с апстримом, который вполне адекватный (да-да), конкретно здесь у меня не получается придумать что-то принципиально лучшее, чем имеющееся. А не просто так кричать, что systemd плох. Он хорош, чем-то плох, но по совокупности -- хорош. > > PS: я *много* лет собирал регулярки/стартеркиты и с sysvinit, > и с systemd -- насмотрелся предостаточно "новых и улучшенных" > режимов отказа. Параллелизация работы требует больше работы по продумыванию системы. > -- ------ С уважением, Михаил Новоселов | mikhailnov@dumalogiya.ru | https://nixtux.ru