From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 24 Dec 2001 18:45:49 +0300 (MSK) From: Ivan Zakharyaschev X-X-Sender: ivan@arrakis.zephyrous To: devel@altlinux.ru Subject: Re: [devel] INCOMING: uw-imap-2001a-alt2 In-Reply-To: <20011224151410.GB27202@ldv.office.alt-linux.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1805008162-1009208749=:2395" Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: devel@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Archived-At: List-Archive: List-Post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1805008162-1009208749=:2395 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT On Mon, 24 Dec 2001, Dmitry V. Levin wrote: > On Mon, Dec 24, 2001 at 06:01:50PM +0300, Ivan Zakharyaschev wrote: > > > > в altair:/user/INCOMING/imz/ > > > > > > Это не годится: > > > rpm -q --scripts uw-imap |fgrep reload > > > > > > Если и делать так, то лучше использовать condreload. > > > Впрочем, "xinetd condreload" еще не реализован... > > > > А что такого плохошо: xinetd reload не запустить демон, если он уже > не > > запущен. reload просто посылает существующему демону сигнал, > требуя, > > чтобы он перечитал конфигурацию. Если его нет -- ничего и не > происходит. > > > > Может быть, в этом случае лучше не xinetd reload (HARD reload), а > > xinetd sreload (SOFT reload)? А разницы между reload и еще не > > реализованным condreload я не вижу. > > uw-imap > uw-imap: Installing your stunnel.pem certificate as imapd.pem > succeeded. > uw-imap: Installing your stunnel.pem certificate as ipop3d.pem > succeeded. > Reloading xinetd (HARD): [FAILED] Понятно, разница только в сообщении, режущем глаза. А что делать: использовать нереализованный condreload/condsreload? Предлагаю уточнить сообщение, которое killproc() из /etc/init.d/functions посылает в лог в случае, когда демона нет (когда он есть, там используется два варианта сообщения) -- патч прицеплен. Можно ли что-нибудь придумать, чтобы xinetd не перезапускался при переходах между runlevel 3 и 5, когда у него нет сервисов для обслуживания? Это происходит неприятно долго. Если бы у него были сервисы для обслуживания, он бы запустился один раз и с ним ничего не происходило бы при переходах между runlevels 3 и 5. А так он завершается сразу же после прочтения конфигурации, и его потом telinit всегда пытается перезапустить. Я сейчас подумал, что в таких ситуациях существующая реализация xinetd не будет делать, чего от нее хотелось бы. Предположим, изначалльно при загрузке у xinetd не было сервисов на обслуживание, и он завершился, прочитав конфигурацию и обнаружив это. Потом добавили в его конфигурацию действующий сервис, сделали service xinetd reload, ожидая, что он заработает, а так как процесса xinetd нет, он не примет сигнал, не запустится и не перечитает конфигурацию. Как эту проблему решать? -- Best regards, Ivan Z. --8323328-1805008162-1009208749=:2395 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="functions.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: make the msg of killproc() more exact (for initscripts-5.49-ipl33mdk) Content-Disposition: attachment; filename="functions.patch" LS0tIGZ1bmN0aW9ucy5vcmlnCU1vbiBEZWMgMjQgMTg6MzI6NDggMjAwMQ0K KysrIGZ1bmN0aW9ucwlNb24gRGVjIDI0IDE4OjM0OjE3IDIwMDENCkBAIC0y NTYsNyArMjU2LDEyIEBADQogCQkJZmkNCiAJCWZpDQogCWVsc2UNCi0JCWZh aWx1cmUgIiRiYXNlIHNodXRkb3duIg0KKwkJaWYgWyAiJG5vdHNldCIgPSAi MSIgXTsgdGhlbg0KKwkJICBmYWlsdXJlICIkYmFzZSBzaHV0ZG93biINCisJ CSMgdXNlIHNwZWNpZmllZCBsZXZlbCBvbmx5DQorCQllbHNlDQorCQkgIGZh aWx1cmUgIiRiYXNlICRraWxsbGV2ZWwiDQorCQlmaQ0KIAlmaQ0KIA0KIAkj IFJlbW92ZSBwaWQgZmlsZSBpZiBhbnkuDQo= --8323328-1805008162-1009208749=:2395--