upgrading/installing in a background process
René J.V. Bertin
rjvbertin at gmail.com
Tue May 5 02:47:14 PDT 2015
On Tuesday May 05 2015 10:19:28 Mihai Moldovan wrote:
>> apart from the weird fact that this apparently is the whole log, I wonder if there would be a way to avoid the abort on the flush error. It's not the first time I run into something like this, and it's rather annoying (the upgrade should have finished by now if it weren't for that otherwise trivial flush error).
>The error isn't weird. The terminal STDOUT/STDERR/STDIN were connected to all of
Never said that.
>a sudden vanished. What's weird about erroring out in such a case, especially if
>the kernel is telling your application that it couldn't handle a write operation
>on some specific FD?
But thinking about it, there's something that does strike me as odd. All the output goes to the log, and only part of it goes to the tty (I did a `port -v upgrade`). I don't know how that's accomplished, but the file descriptor corresponding to the log file should not disappear.
>If you want to be able to "call it a night", start port like any other process
>on UNIX-like operating systems -- within tmux or screen, so that the file
"start like any other process on UNIX-like operating systems" ... I'm sure that sounded different in your head...
In any case, tmux and screen are both overkill, or would require me to kill the running port command to relaunch it before I leave it to its own. I don't know tmux, but screen tends to get in my way with its attempt to be clever with the scrollback buffer etc.
Guess I'll have to try nohup and see if that does what I want.
More information about the macports-dev