Where's the Redhat update application?
Eternally
You know that Redhat update application in 8.0 that runs silently in the
lower right hand corner by the clock, only poking it's head up when there's
an update to download and install?
Well, mine crashed a couple of weeks ago, and I haven't seen it since.
I've looked all through the menu, but I can't find it anywhere.
How do I get it back? What is it called? Where is it found? How do I
start it?
Come back to me Redhat update application!!!
Again, this is for 8.0.
Thanks a lot!
Brett E. Dufault
*grin* Okay, the little lost puppy here is called "rhn-applet-gui". You
can get it to come back by opening a terminal and running:
rhn-applet-gui &
Now you can close the terminal. Then log out, and (*critical step ahead*)
remember to put a check in the box that says "Save current setup". This
way the system will make a little note to itself so it remembers that it's
supposed to start this up again next time you log in.
Cheers!
--Brett
Eternally
Hey,
Thanks a lot! Unfortunately, it's a no go. When I ran that from the
terminal, a few numbers came up, but the application never started. I
still loged, saved the session and logged back in, but again, the
application wasn't there.
So then, I tried running it as root. This time I wrote down those numbers.
After typing in the command you gave me, it says "[1] 10069", but the
application never starts (at least, it's not by the clock in the lower
right hand corner).
Any advice?
Thanks!
Brett E. Dufault
> Thanks a lot! Unfortunately, it's a no go. When I ran that from the
> terminal, a few numbers came up, but the application never started. I
> still loged, saved the session and logged back in, but again, the
> application wasn't there.
Hmmm...the rhn-applet-gui thing normally pops up inside a special
notification area on the panel. I'm wondering if your notification area
has gone AWOL. Try right-clicking on an empty spot in the panel, then go
to "Add to Panel", then the "Utility" menu, and select Notification Area.
It's hard to see the results, but there should be a narrow vertical bar
with some diagonal stripes on it down in the panel. (It's gray-on-gray,
kinda like it's embossed on the panel.) Then open up a terminal and try
running "rhn-applet-gui&" again.
If that works, you can move the notification area back over next to the
clock by right-clicking in that gray-on-gray striped bar, selecting Move,
and dragging it over next to the clock.
I think you'll have to remember to check that "Save current setup" box
again when you log out, so that Gnome remembers to start up both the
notification area *and* the Red Hat notification applet when you log back
in again.
> So then, I tried running it as root. This time I wrote down those
> numbers. After typing in the command you gave me, it says "[1] 10069", but
> the application never starts (at least, it's not by the clock in the lower
> right hand corner).
That "[1] 10069" is saying that the command created a background job
(that's the square brackets), incidentally the first background job (the
"1" inside the brackets), and that the process ID for the command was
10069. If you typed "jobs", you'd see something like:
[1]+ Running rhn-applet-gui &
Or if you ran "ps -p 10069" you'd see something like:
10069 pts/0 00:00:05 rhn-applet-gui
I think the notification applet may have been out there running, but didn't
have a notification area in the taskbar to stick its little button in.
Give it a whirl, see what happens. :-)
Cheers!
--Brett
Eternally
We're so close. I right clicked the task bar, but there was no option that
read exactly "Add to Panel", but there was an "Add". So then I looked
around for a "Utility" or more importantly a "Notification Area", but
couldn't find one.
So then I'm thinking that that must be a Gnome thing. So I logged out and
logged into Gnome. It was. Gnome had it, I did it...and there was my red
hat application update working as it should be.
I logged back in to KDE, but it wasn't there.
So, now only thing left to do is get it running in KDE (since all my system
preferences are setup in KDE).
Is there anyway to get it working in KDE as well?
Thanks a ton for all your help!
Brett E. Dufault
> We're so close. I right clicked the task bar, but there was no option
> that read exactly "Add to Panel", but there was an "Add".
...I read this far, gave myself one of those "dope-slaps" to the forehead,
and said "Doh! I forgot about KDE!" :-)
> I logged back in to KDE, but it wasn't there.
> So, now only thing left to do is get it running in KDE (since all my
> system preferences are setup in KDE).
> Is there anyway to get it working in KDE as well?
Yep! Same idea, different name for KDE. In the Panel, right-click, and go
to Add -> Applet -> System Tray. Seems to be the KDE equivalent of Gnome's
"Notifier Area". You may have to do the
terminal/rhn-applet-gui&/exit-n-save cycle again afterwards to convince the
notification applet to show up.
Cheers!
--Brett
Eternally
That was it! Didn't even have to run the application again. It was running
in the background from the last time.
Thanks a lot!
Eternally
Hey,
Not sure if you're still checking this thread or not, but hopefully you are.
Unfortunately, everytime I reboot, the rhn application doesn't start. I
save the session, but I have to manually start it. The task bar space for
it is still there, but not the application.
Another weird thing. If I start it from a terminal logged in as myself,
then when I close the terminal, the application closes also. But, if I
start it from a terminal where I've SU'd, then it stays even after I close
the terminal. But, in either case, it never restarts when the computer
restarts.
Any suggestions?
Brett E. Dufault
> Not sure if you're still checking this thread or not, but hopefully you
> are.
Still here! Ran a little short on usenet time yesterday though...
> Unfortunately, everytime I reboot, the rhn application doesn't start. I
> save the session, but I have to manually start it. The task bar space for
> it is still there, but not the application.
> Another weird thing. If I start it from a terminal logged in as myself,
> then when I close the terminal, the application closes also. But, if I
> start it from a terminal where I've SU'd, then it stays even after I close
> the terminal. But, in either case, it never restarts when the computer
> restarts.
When you were logged in as yourself and ran rhn-applet-gui, did you put an
ampersand (&) at the end of the command? I.e. :
rhn-applet-gui &
The ampersand lets rhn-applet-gui run in the background, so it'll keep
running once you close your terminal. Without the ampersand,
rhn-applet-guid will get killed when you close the terminal.
I'm not sure why rhn-applet-gui doesn't get killed off when you're su'ed to
root, but I see the same thing on my system that you saw -- rhn-applet-gui
keeps running even after the terminal is closed off. Unfortunately (or
maybe fortunately :-), KDE can't restore the notification applet in this
case -- the applet was run as the root user, so in order for KDE to restore
it properly it would've needed to su to root all on its own, and that
wouldn't be a good thing.
So try running the applet as yourself, with the ampersand at the end of the
command, and log out with the save settings option enabled, then see if the
applet starts back up again.
Cheers!
--Brett
Eternally
I was always using the &, but just to be sure, I tried again and got the
same results. As soon as I closed the terminal it closed as well.
But I got it working now. I opened the terminal, ran it, and then logged
out and saved settings with the terminal open. I then logged back in (both
were still running) and closed the terminal. The rhn app stayed alive, so
then I logged out, saved settings, and logged back in, and it was running
on it's own with no terminal.
Thanks again for all your help!
Eternally
Do'h...I lied. That worked for logging in and out, but not for rebooting.
Oh well.
Linux Doctor
> I was always using the &, but just to be sure, I tried again and got the
> same results. As soon as I closed the terminal it closed as well.
> But I got it working now. I opened the terminal, ran it, and then logged
> out and saved settings with the terminal open. I then logged back in (both
> were still running) and closed the terminal. The rhn app stayed alive, so
Yeah, well, I did this too, and it worked for a day or two, then poof,
disappeared. Then worked for 4 hours, then poof. Now, for 10 days. I
log in and out constantly, and sometimes it disappears when I don't log
out, but just step away for a bit. Other times when I log out. Mostly,
it's there. But not always, then I have to restart it. I think
you're lucky at the moment. I just think it's flaky, period. Hopefully
someone's reported it to bugzilla. Given there are 100's of higher
priority bugs there for RH 8.0, it may be not get fixed any time soon.
Mind you, I love RH... but I have learned not to obsess over quirks like
these. There are just too many of them now. :) Neall
-- ** Remove NOSPAM from return address when making personal reply **
Eternally
Yeah...once I rebooted I lost it.
Brett E. Dufault
>> I was always using the &, but just to be sure, I tried again and got the
>> same results.
That's sorta weird. Did you change your shell at some point, or are you
still using the regular old bash shell? (Use "printenv SHELL" if you're
not sure.)
Oh, and does the same thing happen for other background apps? Like if you
run konqueror& from a terminal and then close the terminal, does konq get
killed? I remember someone posting a while back about having this problem,
where all backgrounded processes got killed when exiting a terminal, but
AFAICR nobody ever found a cause/solution.
> Do'h...I lied. That worked for logging in and out, but not for rebooting.
> Oh well.
Dangit! If you want to give it another try, run through the whole
terminal/rhn-applet-gui&/logout+save/login routine again, then log back in.
If the applet starts, take a look at this file:
.kde/share/config/ksmserverrc
You should see some lines related to rhn-applet, ex:
...
program4=rhn-applet
...
restartCommand4=/usr/bin/rhn-applet-gui,--sm-config-prefix,/rhn-applet-mD1o
ti/,--sm-client-id,11c0a80103000103600262200000016180003
...
These lines are what tells KDE to go run the notification applet when you
log in. If you then shut down, reboot, and log back in and the
notification applet *doesn't* start, could you check that file again and
see whether the rhn-applet lines are still present?
I really don't know what's going on here -- I've done half a dozen
shutdown/reboots, and the darned applet keeps coming up fine on my machine.
But then, I don't have any problems with backgrounded tasks getting killed
off either.
--Brett
Linux Doctor
Sometimes, while logged in, and sometimes, it's gone once I log out
and log back in.
To test your theories, I did a reboot for no good reason, and when I
logged back in the icon was there. Go figure. Its disappearance doesn't
seem related to booting or even logging in/out, and I don't think it's a
backgrounding problem. I suspect perhaps it "checks in" when you reboot
or log in, and if it can't make contact with rhn, maybe it terminates.
That would explain why sometimes it disappears while I'm logged in, too.
Eternally
Brett E. Dufault wrote:
> On Wednesday 30 October 2002 12:43 pm, Eternally wrote:
>
>>> I was always using the &, but just to be sure, I tried again and got the
>>> same results.
>
> That's sorta weird. Did you change your shell at some point,
Not that I know of
>or are you
> still using the regular old bash shell? (Use "printenv SHELL" if you're
> not sure.)
When I run that I get /bin/bash
> Oh, and does the same thing happen for other background apps? Like if you
> run konqueror& from a terminal and then close the terminal, does konq get
> killed?
Yeah, it does
>I remember someone posting a while back about having this
> problem, where all backgrounded processes got killed when exiting a
> terminal, but AFAICR nobody ever found a cause/solution.
>
>> Do'h...I lied. That worked for logging in and out, but not for
>> rebooting. Oh well.
>
> Dangit! If you want to give it another try, run through the whole
> terminal/rhn-applet-gui&/logout+save/login routine again, then log back
> in. If the applet starts, take a look at this file:
>
> .kde/share/config/ksmserverrc
>
> You should see some lines related to rhn-applet, ex:
>
> ...
> program4=rhn-applet
> ...
>
restartCommand4=/usr/bin/rhn-applet-gui,--sm-config-prefix,/rhn-applet-mD1o
> ti/,--sm-client-id,11c0a80103000103600262200000016180003
I reran the whole login routine and this is what I have in that file:
program3=rhn-applet
restartCommand3=/usr/bin/rhn-applet-gui,--sm-config-prefix,/rhn-applet-ucTxDd/,--sm-client-id,103acf79ad000103600620900000011000028
> These lines are what tells KDE to go run the notification applet when you
> log in. If you then shut down, reboot, and log back in and the
> notification applet *doesn't* start, could you check that file again and
> see whether the rhn-applet lines are still present?
Ok, this is where it gets really weird. I rebooted the machine. One
application that's been starting up for the last couple of days when I
reboot the machine is kscd
(probably because I have an audio cd in my drive). I always immeadiatly
close it.
This time, as soon as the machine booted up, as my mouse started going for
the X (to close) on kscd, I noticed the rhn application running,
milliseconds before I closed kscd. As soon as I closed kscd, the rhn
application was gone (this wasn't the original problem though, because rhn
was down for a couple of weeks, and I've only had an audio cd in for a
couple of days).
So, to confirm this, I rebooted the machine again. When it started up, I
made sure not to close kscd. Sure enough rhn was there. I checked the
ksmserverrc file, and the lines for rhn were still there. I closed kscd,
and rhn application automatically closed as well. I checked the file
ksmserverrc again, and the lines for rhn application were still there.
So, to seal the deal, I removed the audio cd, and rebooted the machine. Rhn
started up, but kscd didn't. So now, there's nothing to close rhn.
So, it's good! It's working! I'm not sure if we'll ever know why the
gremlins in my machine are behaving so oddly, but what's to be expected of
gremlins anyway. I'm also not sure what programs in the future will
automatically close rhn, but at least I'll have a heads up as to what's
happening.
Thanks again! You were a big help.
Brett E. Dufault
> To test your theories, I did a reboot for no good reason, and when I
> logged back in the icon was there. Go figure. Its disappearance doesn't
> seem related to booting or even logging in/out, and I don't think it's a
> backgrounding problem. I suspect perhaps it "checks in" when you reboot
> or log in, and if it can't make contact with rhn, maybe it terminates.
> That would explain why sometimes it disappears while I'm logged in, too.
It's true that the applet checks in when it first starts up (i.e., after
you log into your session), so networking issues sound plausible. I tried
some simple tests on a RH 8.0 laptop here.
Logged out of my session, then pulled the network cable off to simulate
(well, "cause" might be more accurate ;-) a network problem.
Then I logged in. The notification applet started up, sat there as a
checkmark for a while with a tooltip saying "Waiting for first checkin...".
After one or two minutes, the icon changed to a question mark, with a
tooltip saying "Error connecting to RHN...".
Logged out, logged back in. Same thing, applet switched to a question mark
after a couple of minutes. Let it sit that way for about ten minutes, then
tried reconnecting the network. La de da de da... Ten minutes later,
still just sitting there as a question mark. Clicking on the applet
brought up a window saying "Network Error -3: Temporary failure in name
resolution.". Clicked OK in that window, then the applet went back to a
checkmark, successfully connected to the net, and seemed happy with life.
Tooltip now shows the normal "No updates available (0 ignored)".
I'll try another test later on, maybe unplug the network cable after I'm
already logged in and leave it that way for a while, see if that causes it
any heartache.
BTW, are you using a proxy with your applet, or does it connect straight to
the net?
Cheers!
--Brett
Linux Doctor
> I'll try another test later on, maybe unplug the network cable after I'm
> already logged in and leave it that way for a while, see if that causes it
> any heartache.
Good idea to have run that test. I didn't think of it.
> BTW, are you using a proxy with your applet, or does it connect straight to
> the net?
No proxies. Connects directly through Comcast cable service to the net.
Well, actually, I'm on a Gateway Solo laptop with an ORiNOCO wireless
802.11b card, connected to the cablemodem via an SMC wireless
barricade/router. No ports open on my firewall (except ssh), so rhnd on
my box must be doing all the initating for checkin. Works fine... except
when that little applet goes "ta-ta." I can always invoke up2date, just
like the old days of RH 7.3 :) Neall
Brett E. Dufault
> You thought it was weird before...
Now *there's* an ominous opening... :-)
> When I run that I get /bin/bash
Okay, that's the default shell (and the same one I'm using).
>> Oh, and does the same thing happen for other background apps? Like if
>> you run konqueror& from a terminal and then close the terminal, does konq
>> get killed?
>
> Yeah, it does
Wish I knew what caused that. I think we had a dozen different people make
suggestions the previous time that someone had backgrounding problems with
RH 8.0 and /bin/bash, but nothing panned out. Does it interfere with your
work at all? (I.e., do you want to try hunting that down, or is it in your
personal "Not A [Big] Deal" category?)
> Ok, this is where it gets really weird. I rebooted the machine. One
> application that's been starting up for the last couple of days when I
> reboot the machine is kscd (probably because I have an audio cd in my
> drive). I always immeadiatly close it.
Huh! Well, I just tried running kscd, and damned if I didn't see the exact
same thing! Closing or quitting kscd also causes the RHN applet to exit on
my system. Haven't found any other KDE apps that cause this yet, but with
kscd it's highly repeatable on my systems.
Also tried this while running under Gnome. kscd doesn't kill
rhn-applet-gui there, but there's still a tiny oddity -- when kscd starts,
the rhn-applet-gui icon jumps a few pixels over to the right, and when kscd
is closed/exits, the rhn-applet-gui icon jumps back to its original
position. But the applet's process ID stays the same, so it's not like the
applet is dying and getting restarted somehow. Wonderfully wacky!
> I'm also not sure what programs in the future will automatically close
> rhn, but at least I'll have a heads up as to what's happening.
That's a great little bug you came across. :-) There's no kscd entry in
the RH 8.0 Bugzilla section, and nothing resembling this in the current
rhn-applet-gui bug reports.
Would you like the honor (?) of submitting the Bugzilla report for this?
If not, I can go open a report on this -- seems like something that needs
looking into!
> Thanks again! You were a big help.
Quite welcome! Besides, bug-hunting is fun! (Yeah, I need to get out
more. :-)
Cheers!
--Brett
Brett E. Dufault
> Good idea to have run that test. I didn't think of it.
I just finished a test where I logged in with the network up and running,
let the applet do its initial connection thing, then yanked the cable.
After an hour, the applet was still just sitting there with a happy little
checkmark saying everything was okay. Tried right-clicking the applet and
doing a maual "check for updates", but that just changed the icon to a
question mark, just like the earlier tests where I pulled the cable prior
to logging in. Sigh.
> No proxies. Connects directly through Comcast cable service to the net.
> Well, actually, I'm on a Gateway Solo laptop with an ORiNOCO wireless
> 802.11b card, connected to the cablemodem via an SMC wireless
> barricade/router. No ports open on my firewall (except ssh), so rhnd on
> my box must be doing all the initating for checkin.
Similar firewall setup here at home -- Red Hat's certainly not initiating
anything here either.
Couple of thoughts. First, given the info from Eternally, I've gotta ask:
do you use kscd? :-) Or notice any similar correlation between
running/stopping a particular application and the applet disappearing?
Other thing that comes to mind -- is there anything that gets logged if
your wireless card temporarily loses its connection? I'm wondering if my
cable-yanking tests are too heavy-handed...possibly the applet only keels
over under more subtle conditions, like if it's interrupted right in the
middle of checking in with Red Hat's site or something. If you noticed
some wireless messages getting logged every time the applet goes AWOL, that
might be a good indicator.
Cheers!
--Brett
Eternally
Welp, it's almost a relief knowing that others experience the same problem
with kscd. I assumed it was related to my initial problem somehow, but I
guess not.
We don't have to worry about the other bug with the closing of apps started
by the closing terminal (I think I made that sound more complicated than it
really is). It doesn't interfer with my work much at all. Thanks for the
offer though.
It doesn't matter who submits the bug report. I'm new to Linux on the home
machine, so I'm not sure how this bugzilla thing works exactly, but I'm
sure I can figure it out. Although, if there is some sort of tally of
number of bugs reported by a user, you technically were the one to realize
it was a bug, so by all means submit it...go for it. You also discovered
the moving of the icons in gnome. But if there's no such tally, I'd be
happy to do it so that you don't have to.
Take Care!
Brett E. Dufault
> It doesn't matter who submits the bug report. I'm new to Linux on the
> home machine, so I'm not sure how this bugzilla thing works exactly, but
> I'm sure I can figure it out.
It's actually pretty easy, and if you're willing to do the bug report then
by all means, be my guest! There's no scorecards, prizes, or anything like
that, so I certainly won't be missing out on anything. :-) It only takes
a couple of minutes to get a Bugzilla account set up, and for a bug like
this it should only take a few more minutes to fill out the form, since
it's a really easy-to-reproduce bug.
I just didn't want to end up with the same bug submitted twice -- duplicate
bugs just mean more work for the Red Hat geeks.
She's all yours! :-)
--Brett
Linux Doctor
work, guys!
What's interesting is it's an app (kscd) that takes a spot in the same app
location as my sound, korn, and battery indicator. So, if i remove my
battery indicator, the rhn applet goes away. If I kill and invoke korn,
the rhn applet goes away. So, it's not just kscd, but any app that can be
"docked" in to the app portion of the KDE taskbar.
Eternally
> Yes, I use kscd and yes, it eliminates the rhn applet. Good detective
> work, guys!
>
> What's interesting is it's an app (kscd) that takes a spot in the same app
> location as my sound, korn, and battery indicator. So, if i remove my
> battery indicator, the rhn applet goes away. If I kill and invoke korn,
> the rhn applet goes away. So, it's not just kscd, but any app that can be
> "docked" in to the app portion of the KDE taskbar.
>
> Neall
>
Well, at least this chaotic bug is starting to become predictable. We just
gotta work around is all.
Neo Gigs
I think the root cause of this for me is after I had upgraded KDE
3.0.3 to KDE 3.0.4-1 manually from KDE but not from RHN.
Neo Gigs
"Follow the white rabbit..."
Brett E. Dufault
> I think the root cause of this for me is after I had upgraded KDE
> 3.0.3 to KDE 3.0.4-1 manually from KDE but not from RHN.
Interesting idea, Neo -- I'd also upgraded to a few RawHide 3.0.4 packages,
because of the KDE screensaver glitch.
Just give me a minute here... (clickety clickety click)
Okay, I just went and downgraded one of the boxes to the original 3.0.3
RPMs off the installation CDs, rebooted (just to be safe), but I still see
the same problem with rhn-applet-gui exiting whenever kscd, klaptopdaemon,
etc is closed.
Anyone care to try a quick downgrade on their own box, just to double-check
my results? (rpm -Uvh --oldpackage blahblah-3.0.3-blah)
Cheers!
--Brett
Eternally
Mine was on a fresh install of RH 8.0