Bug#905454: php-common: Update to php-common (1:62) stuck in php.common-post at systemd-tty-ask

[Jaap Keuter]

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.

I'm not sure what else we can do to reproduce this observation.

Thanks,
Jaap