1

While doing a run of the mill apt upgrade, a Tomcat 7 post install script ran with the common A new version of configuration file /etc/default/tomcat7 is available.... Unfortunately, I didn't attend to it quickly enough and the SSH connection was reset. How do I recover from this? Can I reattach to the post install screen? Is it safe to kill it? If I kill it, is there a script somewhere I should be manually executing?

I saw this question about doing an upgrade of OS versions, but either the solution (screen -r) isn't relevant or I'm not using it correctly.

$ screen -r
There is no screen to be resumed.

I can see the process running:

$ ps -a
  PID TTY          TIME CMD
  416 pts/2    00:00:00 frontend
  423 pts/2    00:00:00 tomcat7.postins
  430 pts/2    00:00:00 ucf
  475 pts/2    00:00:00 whiptail
  634 pts/1    00:00:00 ps

As suggested by Dmitry Zayats I've looked at the Tomcat 7 post install script. In my installation of Ubuntu 14.04, it's found here: /var/lib/dpkg/info/tomcat7.postinst

Opening that up, I believe I see the relevant line where I initially lost my connection:

ucf --debconf-ok --sum-file /usr/share/tomcat7/defaults.md5sum $tmpfile $CONFFILE

Community
  • 1
Toby Murray
  • 111
  • 1
  • 3
  • screen -r command assumes that you was running your update from inside screen. That way even if you disconnected - you can reconnect to screen session later. There is no way to re attach to previously running ssh session connection to which was lost if you was not using some sort of terminal multiplexer (screen or tmux for instance). – Dmitry Zayats Nov 06 '16 at 19:01
  • [One of the answers](http://serverfault.com/a/321527) on the linked questions says the author believes "screen" or similar should be used as much as possible. I'm not at all familiar with it - have I just been reckless with how I was doing this? Is the *real* answer here that I'm missing a best practice for these kind of operations? – Toby Murray Nov 06 '16 at 19:08
  • Answering my own question a bit, [this question](http://askubuntu.com/q/8884) and [this question](http://askubuntu.com/q/222587) seem to answer that pretty concretely. – Toby Murray Nov 06 '16 at 19:16

2 Answers2

5

Kill the dpkg/apt session and re-issue the command. It will re-deploy in-progress packages. With most pre/post install scripts it will work out okay. In the few cases where the upgrades packages don't work as expected, reinstall the packages.

And, as the others said: tmux/screen.

John Keates
  • 681
  • 4
  • 9
1

Whenever you work on a remote machine (even with stable network connection in enterprise network) the best practice is to use terminal multiplexer for long running and important tasks.
I suggest to invest time and learn how to use screen or tmux, this will increase your productivity and will make those upgrades much safer.
Not only you will be able to reconnect in case connection was lost - but there is so much more.
Like logging your entire session, splitting screens so you can have multiple terminals in same window running on a single ssh connection. Horizontal split / vertical split.

Dmitry Zayats
  • 1,378
  • 6
  • 7
  • I see that now, I definitely was not aware of that before. Given that I haven't used a terminal multiplexer in this situation, what's my best option for recovering from my current situation? – Toby Murray Nov 06 '16 at 19:18
  • While this is certainly very good information, it does not seem to propose a resolution to the question. – Paul Nov 06 '16 at 19:18
  • Examine post install tomcat script. See if it created any logs. You can see what this pid is currently doing with strace. strace -f -p pidid. You can see what files this pid has open with lsof -p pid. Without this information the only answer I can give would be to kill this pid and repeat your update. – Dmitry Zayats Nov 06 '16 at 19:24
  • And if you figure out that it waits for some user input - take a look here https://serverfault.com/questions/188936/writing-to-stdin-of-background-process/297095 This might help. – Dmitry Zayats Nov 06 '16 at 19:30