Your message dated Mon, 15 Apr 2019 00:18:53 +0200
with message-id <[email protected]>
and subject line Re: Bug#905454: php-common: Update to php-common (1:62) stuck
in php.common-post at systemd-tty-ask
has caused the Debian Bug report #905454,
regarding php-common: Update to php-common (1:62) stuck in php.common-post at
systemd-tty-ask
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
905454: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905454
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: php-common
Version: 1:62
Severity: normal
Dear Maintainer,
While updating to php-common 1:62 the update gets stuck at:
...
Unpacking mesa-va-drivers:amd64 (18.1.5-1) over (18.1.4-1) ...
Preparing to unpack .../17-php-common_1%3a62_all.deb ...
Unpacking php-common (1:62) over (1:61) ...
Preparing to unpack .../18-php7.2-xml_7.2.8-2_amd64.deb ...
Unpacking php7.2-xml (7.2.8-2) over (7.2.4-1) ...
...
Processing triggers for libc-bin (2.27-5) ...
Setting up mesa-va-drivers:amd64 (18.1.5-1) ...
Setting up php-common (1:62) ...
<no more output>
Looking at the process tree reveils the following:
| |-konsole -session
10dd616e75000153319032500000014310008_1533191244_922307
| | |-bash
| | | `-update-debian.s /home/jaap/bin/update-debian.sh
| | | `-sudo aptitude
| | | `-aptitude
| | | |-dpkg --status-fd 96 --configure --pending
| | | | `-php-common.post
/var/lib/dpkg/info/php-common.postinst configure 1:61
| | | | `-systemctl start phpsessionclean.timer
| | | | `-systemd-tty-ask --watch
| | | `-{aptitude}
Somehow systemd-tty-ask tries to get something from us, but can't?
Ended up killing the systemd-tty-ask and systemctl processes to get the update
to complete.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500,
'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages php-common depends on:
ii psmisc 23.1-1
ii sed 4.5-1
php-common recommends no packages.
php-common suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Jaap
On Tue, 7 Aug 2018 21:18:16 +0200 Jaap Keuter <[email protected]> wrote:
> On 05-08-18 18:32, Michael Biebl wrote:
> > Am 05.08.2018 um 18:14 schrieb Jaap Keuter:
> >
> >> As a further experiment I've entered the following in a bash shell to see
> >> what
> >> would happen:
> >>
> >> $ systemctl start phpsessionclean.timer
> >>
> >> It pops up a dialog "Authentication Required - PolicyKit1 KDE Agent"
> >> which says "Authentication is required to start 'phpsessionclean.timer".
> >> It sits there for 25 seconds, after which it disappears outputting on the
> >> shell:
> >> "Failed to start phpsessionclean.timer: Connection timed out
> >> See system logs and 'systemctl status phpsessionclean.timer' for details."
> >>
> >> So this is what might be happening on the update as well. As I was doing
> >> other
> >> things at the time, the dialog must have long since disappeared during the
> >> update.
> >
> >
> > "$" indicates, that you were running the above command as unprivileged
> > user. In that case it is expected that you are prompted for authentication.
> >
>
> That is correct. The experiment was to see what would happen in that case, how
> the authentication action would proceed.
>
>
> > dpkg/apt must be run with root privileges, in which case no separate
> > authentication is required.
>
> That is what I am expecting from running 'sudo aptitude'.
>
>
> > "sudo systemctl start phpsessionclean.timer" will/should not trigger a
> > polkit authentication dialog.
> >
>
> Indeed it does not.
>
> >>> Assuming you haven't rebooted the system, please also include the output
> >>> of "journalctl -alb" and dmesg.
> >
> > If you have persistent journal enabled, you might still have the logs
> > from the previous boot.
> >
>
> Unfortunately I do not.
>
>
> > Now that you've rebooted, does "sudo apt install --reinstall php-common"
> > trigger this issue again, ie. do you have a way to reproduce it?
> >
>
> Running this command does not trigger the issue again. It finishes normally.
> Note that in this case the phpsessionclean.timer is already started.
> Stopping the timer and then running the command also does not trigger the
> issue.
>
> Further testing was performed by downgrading php-common to 1:49 (stable) and
> stopping the phpsessionclean.timer. From there the same update-debian.sh
> script
> was used to start an update. Still this did not trigger the issue.
>
Apparently we have no way to reproduce this issue and with the given
information it's not possible to further triage this issue. Might have
been a fluke.
So I'm closing this bug report at this point.
If you run into this again, please provide an strace of the hanging
process. It might also be useful to turn systemd into debug mode (via
systemd-analyze set-log-level debug) and attach a journalctl -alb output.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
