Hi,
I have a quite strange circumstance and I have not found anything on the internet regarding it.

I did an apt upgrade in a server.
It started installing what had to be installed but at some time when it was setting up php5-fpm upgrade process needed attention.

Setting up php5-fpm (5.5.9+dfsg-1ubuntu4.25) ...

Configuration file '/etc/php5/fpm/pool.d/www.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.

I tried to reply the question, but when I tried, ssh connection had died.

*** www.conf (Y/I/N/O/D/Z) [default=N] ? packet_write_wait: Connection to XX.XX.XX.XXX port 22: Broken pipe

So I ssh the server again.

Now, estrangely enough, i cannot restart apt upgrade because the old process has not died. It is in SLEEP state (waiting for a keystroke I supose).

root@www:~# apt upgrade
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

I could kill apt upgrade process, but you don't want to kill an upgrade process in the middle, do you? That could create a ton of problems. Murphy's law is around.

So I thought if I only could send a N keystroke to the process IO file, that should resume the process and easily overcome the problem. It is not common that apt upgrade needs attention. It should finish ok if I am a little lucky.

Are you following yet?

I googled around and found that /proc/PID/fd/0 should be the file/stream i should echo to. But the problem is that this standard IO fd is dead.

root@www:/proc# ls -lah 25902/fd/
lrwx------ 1 root root 64 May 25 09:39 0 -> /dev/pts/2 (deleted)
lrwx------ 1 root root 64 May 25 09:39 1 -> /dev/pts/2 (deleted)
...

So I cannot echo anything to it.

root@www:/proc# echo n > /dev/pts/2
-bash: /dev/pts/2: Permission denied

root@www:~# echo n > /proc/25902/fd/0
-bash: /proc/25902/fd/0: Input/output error

So, the question is: Did anybody had this problem before? Did you manage to send a keystroke to apt upgrade process without having to kill it? Any clues?

if I list /proc/PID/fd/ it has a ton of /var/lib/apt files opened (normal) and some others I don't know what are they used for. Any clue?

lrwx------ 1 root root 64 May 25 09:39 71 -> /dev/ptmx
lrwx------ 1 root root 64 May 25 09:39 72 -> /dev/pts/3
lr-x------ 1 root root 64 May 25 09:39 73 -> pipe:[2695925055]

Thank you very much. Any help or clue will be appreciated.


PS: Maybe there is another way to solve it, such as sending the process a signal through kill (not -9 but another) so the process finishes correctly.

lot of confusion. a sleeping process is not a process which waits for a keystroke. If /proc/25902/fd/0 is unavailable the process was already died (most probably).
If an upgrade process is waiting for user input but there is no tty to press any key - you can safely kill that process and restart again.

ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 25902 1.6 0.3 106436 61148 ? S 09:24 4:29 apt upgrade

It does not seem dead and STAT is S. It keeps consuming CPU. in fact I see another process that looks like it is the one that is waiting for input.

root 28117 0.0 0.0 17800 3996 pts/3 Ss+ 09:24 0:00 /usr/bin/dpkg --status-fd 74 --configure libkmod2:amd64 libprocps3:amd64 kmod:amd64 mo


yet I try to send
root@www:~# echo n > /proc/28117/fd/0

And nothing happens.

PS: I know I could kill the process. But it can be a problem and I feel there might be a way to resume it. I guess I can kill process 28117 and that should let 25902 continue unlocking apt lock file. I am not sure what signal to send to 28117 so it finishes without giving back an error. I guess if I send it a -9 it might leave with error and make apt fail also.

Ok, I finished killing dpkg process (kill -9 28117) and that killed apt process also.

After that i called apt update and apt told me dpkg had been killed and asked me to resume it.

It resumed installation and asked again for the very first question.

Question not solved. Problem solved.

looks like your apt database is corrupted and sometimes that can cause such things.

apt database is not corrupted. I do let the thread open because I did not find a solution to the main problem. If a process loose its virtual tty from a broken ssh connection and does not die... is there any way to send that process the keystrokes needed so it continues? Is there anyway to fool a process to use a new IO file/stream (0,1,2) once it is already running and the IO file/stream has been killed?

no, if the original filehandlers are lost there is no way to attach new ones (at least I don't know). But in such cases a sigpipe or similar should be sent.

The apt package manager is extremely robust and it is safe to interrupt and resume it.

The problem with using an SSH connection is that all processes started in that session will be killed. Or at least should be.

You can avoid that by installing screen. In your terminal you start a new, named terminal process. This terminal process keeps running even if the SSH connection is gone. All output is sent to that terminal. You can resume it anytime. For remote operations which can take some time it is a great solution.

Create the screen process:
Detach a running screen:
Re-attach in a new SSH session:
List running screen processes:
When reattaching you only need to use the name, e.q. myupdate. Only if multiple screens with the same name exist you need to reattach with <unique_id>.myupdate

jlinkels

Could you explain me a little more about the sigpipe thing?

https://en.wikipedia.org/wiki/Signal_(IPC)#SIGPIPE
https://en.wikipedia.org/wiki/Pipeline_(Unix)
if you really use ssh: your local tty (which is usually handled by the terminal) will be inherited by the local ssh command, will be piped/redirected to the remote server where it will somehow inherited by the remote process started by sshd. This chain will be broken if any of those processes died (either on client or server side). Usually you will get a connection lost/sigpipe/sigchild or something similar in that case. And usually the remote end will die.
As it was mentioned screen may help to solve this issue.

But I still don't know what was really happened, what you posted is just the "result".
By the way you munt not use kill -9, but sigterm in usual cases.