Hello,

update-inetd should allow a non-interactive mode to avoid the use of
debconf.

Indeed, I get the following warning when I use update-inetd in a script
executed under udev responsability :

debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype

I looked at update-inetd code source and, in my opinion, DebianNet.pm
should load debconf code only if needed (if --multi is not present for
example) but this is always done.

This is the command I tried:

    update-inetd --disable --multi $1 >/dev/null 2>>$log

Thanks for your work!

Regards,
Philippe.

Hi Philippe,

On Tue, Nov 15, 2011 at 04:41:26PM +0100, Philippe Basinska wrote [edited]:
[..]

I sympathise with the aim, but debconf is needed in pretty much all invocation
modes. That's because the user is prompted to make a choice when a service
selector matches more than one entry (which is terrible; check out DEP9 for an
alternative design)

Feel free to clarify if I'm missing something, or else I'll just close the
bug.

cheers,
sez

Le 22.11.2011 23:46, Serafeim Zanikolas a écrit :

Hi Serafeim,

I understand why Debconf is needed by update-inetd most of the time.
The point is that there is no debconf screen if --multi is used (since
there is no need to ask admin agreement).

Moreover, there is no more Debconf question when a wrong name of
service is given to update-inetd :

server-bl:~# TERM=
server-bl:~# update-inetd --disable wrong_name
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline

(I cleared out $TERM to emulate the problem I encounter when
update-inetd is executed by udev).

So, if there is no Debconf usage in these two situations, maybe it is
not necessary to load Debconf module. It would solve my issue (the
warning about TERM value) and optimize update-inetd. I think it would be
interesting not to load Debconf module if --multi is given to CLI.

Do not hesitate if you need more information and feel free to close the
report if you really think this is not to fix.

Regards,

Hi again Philippe,

Thanks for clarifying. I'd be happy to apply a patch, but I'm uncertain
whether the issue warrants a stable-release update (which is probably what you
need), and I would rather focus on update-inetd's replacement than
prepare/test the patch myself.

cheers,
sez