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

  • 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 6 '16 at 19:01
  • One of the answers 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 6 '16 at 19:08
  • Answering my own question a bit, this question and this question seem to answer that pretty concretely. – Toby Murray Nov 6 '16 at 19:16
3

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.

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.

  • 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 6 '16 at 19:18
  • While this is certainly very good information, it does not seem to propose a resolution to the question. – Paul Nov 6 '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 6 '16 at 19:24
  • And if you figure out that it waits for some user input - take a look here serverfault.com/questions/188936/… This might help. – Dmitry Zayats Nov 6 '16 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.