Is there any way (besides being awake when you do it...) to keep freenx updates from killing yum mid-transaction if you run the update in a freenx session? Normally I ssh in from a session on a different host but sometimes forget...
On Wed, Dec 19, 2012 at 11:08 PM, Les Mikesell lesmikesell@gmail.com wrote:
Is there any way (besides being awake when you do it...) to keep freenx updates from killing yum mid-transaction if you run the update in a freenx session? Normally I ssh in from a session on a different host but sometimes forget...
-- Les Mikeselll lesmikesell@gmail.com _______________________________________________
maybe run is through screen?
On Wed, Dec 19, 2012 at 3:16 PM, Rudi Ahlers Rudi@softdux.com wrote:
Is there any way (besides being awake when you do it...) to keep freenx updates from killing yum mid-transaction if you run the update in a freenx session? Normally I ssh in from a session on a different host but sometimes forget...
maybe run is through screen?
It works fine to just ssh in from somewhere else without needing screen. The problem is when I forget and start the yum update from a window where freenx on the same box is the parent session. I don't need yet another way to connect - I'm looking for something to either improve my memory (unlikely...) or to keep the freenx package update from breaking the connection in progress when I forget and run it there.
On 12/19/2012 4:22 PM, Les Mikesell wrote:
need yet another way to connect - I'm looking for something to either improve my memory (unlikely...) or to keep the freenx package update from breaking the connection in progress when I forget and run it there.
How about a shell alias for yum which prints a reminder about FreeNX and waits several seconds before starting yum to give you a chance to CTRl-C it first?
Having the alias detect whether you're within a FreeNX session before actually running yum would be a neat trick, but is beyond my ability to script (if it's even possible).
On Wed, Dec 19, 2012 at 4:22 PM, Les Mikesell lesmikesell@gmail.com wrote:
It works fine to just ssh in from somewhere else without needing screen. The problem is when I forget and start the yum update from a window where freenx on the same box is the parent session. I don't need yet another way to connect - I'm looking for something to either improve my memory (unlikely...) or to keep the freenx package update from breaking the connection in progress when I forget and run it there. -- Les Mikesell
A wise man once told me:
If you don't like things that use traditional unix tools for the purposes they were designed, why are you interested in using linux at all? -- Les Mikesell
So if you don't want to use screen, which has its main purpose of preventing processes from getting killed when the terminal is killed, then how do you expect us to help?
But seriously, the alias thing is a good idea. You can also have it check if its within screen instead of detecting freenx, which is probably a lot easier if you look at $TERM.
Alternatively, you could exclude freenx from yum updates and have a cron job that emails you once a week if there's an update to it. At least that way you won't get bitten when it gets lumped into other updates.
It seems strange that an update would kill an existing connection. Updates to other critical things like ssh have not done that in years. Maybe a bug to be filed with the package vendor?
❧ Brian Mathis
On Wed, Dec 19, 2012 at 4:11 PM, Brian Mathis brian.mathis+centos@betteradmin.com wrote:
On Wed, Dec 19, 2012 at 4:22 PM, Les Mikesell lesmikesell@gmail.com wrote:
It works fine to just ssh in from somewhere else without needing screen. The problem is when I forget and start the yum update from a window where freenx on the same box is the parent session. I don't need yet another way to connect - I'm looking for something to either improve my memory (unlikely...) or to keep the freenx package update from breaking the connection in progress when I forget and run it there.
A wise man once told me:
If you don't like things that use traditional unix tools for the purposes they were designed, why are you interested in using linux at all? -- Les MikesellSo if you don't want to use screen, which has its main purpose of preventing processes from getting killed when the terminal is killed, then how do you expect us to help?
Hmmm, I didn't think anyone listened to what I said... but in this case I'd think nohup would be the traditional tool. I've always thought of screen as an unnecessary kludge when you have real window managers available. But it would be better yet if the program that needed to complete a series of operations as a transactions fielded signals on its own (and I think it does, just oddly - note what happens if you hit ctl-c while yum is downloading files). Or if the package update scripts were a little more careful not to commit suicide.
But seriously, the alias thing is a good idea. You can also have it check if its within screen instead of detecting freenx, which is probably a lot easier if you look at $TERM.
Hmmm, in the typical case $DISPLAY would have a very high number if freenx is hosting the window.
Alternatively, you could exclude freenx from yum updates and have a cron job that emails you once a week if there's an update to it. At least that way you won't get bitten when it gets lumped into other updates.
Good ideas, but they need to be set up ahead of time on every machine.
It seems strange that an update would kill an existing connection. Updates to other critical things like ssh have not done that in years. Maybe a bug to be filed with the package vendor?
Yes, I think it would be better if things just worked in the first place.... Maybe I'm unusual in using freenx as my primary access method for several machines, though.
-
Brian Mathis -
Chris Beattie -
Les Mikesell -
Rudi Ahlers