Control: tags -1 + moreinfo
Hi all,
2007-02-22 17:29 Ian Zimmerman:
Package: aptitude
Version: 0.4.4-1
Severity: normal
In some circumstances, which seem to involve planetary constellation,
^Z in aptitude doesn't work. At all. Like, it does nothing.
I can send along my configuration, but it is nothing special. Like
most people (I think) I disable all the frills at the top of the screen
and hide the long descriptions at the bottom.
SIGSTOP is a signal that cannot be captured/handled by the process [1],
so if aptitude is not suspended it seems to me that it's more likely
that the problem is in the path where the signal travels from the
keyboard to the process to be suspended.
The charmap looks a bit unusual to me, and you were using a custom built
kernel, but I don't know if this can be related.
In any case, have you seen this problem in the intervening years, or
found ways to reproduce it reliably?
[1]
https://www.gnu.org/software/libc/manual/html_node/Job-Control-Signals.html#Job-Control-Signals
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-7custom200702191149
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.3-6-3 0.6.46.4 Advanced front-end for dpkg
ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-21 GCC support library
ii libncursesw5 5.5-5 Shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
Versions of packages aptitude recommends:
ii aptitude-doc-en [aptitude-doc 0.4.4-1 English manual for aptitude, a ter
-- no debconf information
2007-10-30 21:38 Yann Dirson:
I have also seen such a behaviour (although not recently), as well as
a variant which may help to shed some light on the whole issue.
In the variant behaviour, I attempt to suspend aptitude while it runs
another process, while installing packages. This appears to freeze
aptitude, but a look at the processes shows that aptitude is perfectly
fine, but the subprocesses it has forked are stopped (ps report "T"
state). In this situation, sending a SIGCONT to those stopped
processes allows them to proceed - but still no way to suspend the
whole.
I observed this with various subprocesses - apt-listbugs and package
postinst scripts. After the requested installs are finished, Ctrl-Z
is functional again.
Another factor that may be worth noting, is that my aptitude process
is always run from within a screen(1) session. I'll try to think of
launching one outside of it and check how it works.
I don't know if the behaviour described here is the same as in the
original report.
Also, I think that this is the normal behaviour, the suspended package
is the one having the "focus" in the terminal, not all the chain.
Is it causing any problem or misbehaviour? Even if aptitude is not
"suspended", I imagine that it's blocked waiting for the children to
finish anyway.
2013-02-25 16:43 Axel Beckert:
Control: tag -1 + confirmed
Control: found -1 0.6.8.2-1
Hi,
Ian Zimmerman wrote in 2007:
Package: aptitude
Version: 0.4.4-1
Severity: normal
In some circumstances, which seem to involve planetary constellation,
^Z in aptitude doesn't work. At all. Like, it does nothing.
JFTR: I ran into this recently, too, in Sid, but couldn't reproduce it
again afterwards. So I'm adding the tag "confirmed", but leave the tag
"unreproducible". Feel free to remove the tag "unreproducible" if that
semantic is not wanted.
Yann Dirson wrote in 2008:
I have also seen such a behaviour (although not recently), as well as
a variant which may help to shed some light on the whole issue.
In the variant behaviour, I attempt to suspend aptitude while it runs
another process, while installing packages. This appears to freeze
aptitude, but a look at the processes shows that aptitude is perfectly
fine, but the subprocesses it has forked are stopped (ps report "T"
state). In this situation, sending a SIGCONT to those stopped
processes allows them to proceed - but still no way to suspend the
whole.
I observed this with various subprocesses - apt-listbugs and package
postinst scripts. After the requested installs are finished, Ctrl-Z
is functional again.
That's a different issue.
I think the original issue is related to http://bugs.debian.org/658271
("Quitting" from curses interface has no effect.) as it showed up
under similar yet not identical circumstances, i.e. I could reproduce
#658271 and Ctrl-Z was still working. (IIRC "q" did not
work either when Ctrl-Z did no more work, but I'm not sure.)
We fixed #658271 in the last few versions, but I am not sure if it's the
same as above.
Another factor that may be worth noting, is that my aptitude process
is always run from within a screen(1) session. I'll try to think of
launching one outside of it and check how it works.
That's mostly the case for me, too. Can't though remember if that was
the case when I ran into this issue.
Any occurence since then?
Again, as with my comment to the first report, I don't think that not
being suspended in these circumstances is a problem with aptitude,
because if the process to be suspended is aptitude, the signal is not
even supposed to reach aptitude.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
