Re: [devel] INCOMING: uw-imap-2001a-alt2

[Ivan Zakharyaschev <imz@altlinux.ru>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2218 bytes --]

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.

[-- Attachment #2: make the msg of killproc() more exact (for initscripts-5.49-ipl33mdk) --]
[-- Type: TEXT/PLAIN, Size: 341 bytes --]

--- functions.orig	Mon Dec 24 18:32:48 2001
+++ functions	Mon Dec 24 18:34:17 2001
@@ -256,7 +256,12 @@
 			fi
 		fi
 	else
-		failure "$base shutdown"
+		if [ "$notset" = "1" ]; then
+		  failure "$base shutdown"
+		# use specified level only
+		else
+		  failure "$base $killlevel"
+		fi
 	fi
 
 	# Remove pid file if any.