[Aptitude-devel] Bug#411979: aptitude: can't suspend

Sun Nov 8 15:18:55 UTC 2015

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 <manuel.montezelo at gmail.com>