I disabled the Beagle previously and now I can’t find the settings. I thought they were just undery Yast or Control Panel.
Does anyone know where to enable/disable them?
Thanks,
Wynn
Assuming you disabled Beagle, and didn’t remove it, first start the daemon with the command
beagled
Open the Beagle settings with
beagle-settings
Set your preferences there, e.g., starting the daemon at login.
OK, I ran beagle-settings via the command prompt and it opened a window to the gui fe since I’m tunneling an X session over SSH. That means these settings are in the gui. I just can’t find them when I’m there.
Any ideas on where they are (in case someone logs in through vnc)?
(!!) Also, beagle-settings is set up to launch beagle automatically, yet beagled is not running and there is no entry in the yast run level module to turn in on. Where is this normally launched from?
And if anyone knows the answers to the above questions, maybe you’ll know the following:
Is it possible to reset (purge) the indexes and have it start over from scratch?
Thanks,
WT
> (!!) Also, beagle-settings is set up to launch beagle automatically,
> yet beagled is not running and there is no entry in the yast run level
> module to turn in on. Where is this normally launched from?
you may be the only person on earth who actually WANTS to run it…
but, to answer: you normally launch it from the Menu > System > File
System > Kerry-Beagle
once it is running, go into the configure section and tell it to run
on start-up…i know you say it is set to do that, but it is not…so,
who knows…TRY telling it to NOT run, then tell it TO run…maybe it
will listen THEN!
> And if anyone knows the answers to the above questions, maybe you’ll
> know the following:
>
> Is it possible to reset (purge) the indexes and have it start over from
> scratch?
should be able to just
- turn off beagle
2.delete the hidden named /home/[user]/.beagle
where [user] is the name of the user whose desktop you want indexed,
again…
- turn on beagle again, and watch it SLOW your machine to
UN-usable…maybe SO unusable you can’t mark it to come on with next
boot! (or log out)
–
natural_pilot
If you log in as root. Beagled won’t run (if the “run as root” is not checked). That is why beagled wouldn’t run even when I gave the command.
Are people facing these performance issues indexing a resonable amount of data? (<100 GB)
I really only want one directory and it’s children indexed.
I’m starting to reconsider…
Thanks,
WT
Thanks for the help everyone, it seems to be working now and has not taken up more than 9% of my cpu in bursts. But here’s the thing, I don’t use many desktop apps on this box, mostly file storage and a few key services. I only had the filesystem backend enabled, so maybe that it’s saving grace. That also might be a strategy for those who want to use Beagle, but causing performance hits when initially indexing. (I will assume things will work fine in a steady state.)
- Disable Beagle
- Enable 1 backend
- Enable Beagle and wait for indexing to complete
repeat for all backends
I suppose if you still had problems you disable it’s autostart, have cron start it at night and shut it down in the morning till it is done it’s initial indexing.
Has ANYONE had good luck with Beagle?
WT
> If you log in as root. Beagled won’t run (if the “run as root” is not
> checked). That is why beagled wouldn’t run even when I gave the command.
you should never EVER log into the KDE, Gnome or any other graphical
desktop as root…
never ever…can cause all sorts of problems…and, NO it is not true
that you can be VERY careful and all will be ok…
> Are people facing these performance issues indexing a resonable amount
> of data? (<100 GB)
>
> I really only want one directory and it’s children indexed.
>
> I’m starting to reconsider…
give it a try…see if you like it…most do not.
and, by the way, just in case you missed it: never ever log into a
Linux GUI as root…instead, log in as a normal user and become root
in several ways…to learn the correct way, see:
http://en.opensuse.org/SDB:Login_as_root
–
natural_pilot
OK, this is getting off topic, but let’s go with it.
I read the article. It had some good info in there, but it said that OS disables root login to the GUI by default. That’s not the way mine works, and I’ve changed nothing. Any info on this?
----quoted----
you should never EVER log into the KDE, Gnome or any other graphical
desktop as root…
never ever…can cause all sorts of problems…and, NO it is not true
that you can be VERY careful and all will be ok…
—end quote—
Well, I don’t usually log into the GUI becuase it’s slow over the network. I log into the terminal over SSH. I have logged into the GUI as root in a jam, and want to know if this corrupts something, or is this to limit user error (disaster) 
BESIDES USER ERROR, what are all the problems you mention? Why is being careful (by that I mean not making a user error) not sufficient for all to be OK.
[Just to clarify: I understand that being careful (intent not to screw up) is not enough to save your skin. Many people try and fail. That could cost you your system. It’s the difference between a careful user and a reliable one.]
[Preface: Everything below should be taken in the context of doing admin/disaster recovery/etc type work, not surfing the web]
As far as logging into the terminal as root (over SSH), I don’t see the difference between logging in as root and starting a process with userid=0 and logging in as Joe, SUing to root, and starting a process with userid=0. So, if I don’t plan on doing “user” tasks, I log in directly as root. That machine is very rarely used for personal computing, and when I do I log in as my username.
Is there a difference between the process execution in the scenarios mentioned above?
The example given in the link you referenced doesn’t seem too valid to me. Yes, if he was a nonprivledged user it would have saved him, but SUing to root and issuing the same command would have cost him the same fate. In the end, I would rather have a reliable user login as root, then have an average user (or even a careful user) su to root. Obviously this is taken in the context of when you MUST use root.
To tie this into the thread: I was merely suggesting that if those that are trying to get Beagle working and cannot use their system (under their username) because Beagle is eating their resources, try logging in as root to prevent it, fix the problem (disable it), then logout and login as Joe or whoever.
WT
sorry for the delay, life intervened…
and, sorry for the long post, it is the best i can do:
wjtaylor wrote:
> <many snips>
> I read the article. It had some good info in there, but it said that OS
> disables root login to the GUI by default. That’s not the way mine
> works, and I’ve changed nothing. Any info on this?
it is a wording choice…what actually is going on is that in the
graphical user log-in, there is no user named “root” offered to click on…
i agree that that is not the same as root log in to the GUI is
“disabled”, rather it is “hidden” [who knows, maybe to a long time
Redmond user ‘hidden’ might as well be ‘disabled’…]
i have just made a couple of minor edits to the page to help it to
better reflect reality…are they ok with you?
> I log into the terminal over SSH. I have logged into the GUI as
> root in a jam, and want to know if this corrupts something, or is this
> to limit user error (disaster) BESIDES USER ERROR, what are all the
> problems you mention? Why is being careful (by that I mean not making a
> user error) not sufficient for all to be OK.
yes, there is absolutely a potential for introducing problems without
any user ‘mistakes’ or ‘errors’…but, all the problems i which
can happen i can’t say…maybe others here can, and will…i hope they
do…
i can give you two examples:
in each user’s /home there is a hidden file named .ICEauthority which
MUST be user readable and writable…there are circumstances (which i
can’t describe) when that file or its permissions get accidentally
changed if root signs into the GUI and does something…
i can’t say what ‘something’, because i do not know what i did…but
i know i did it and i know that afterwards i could NOT log in as
myself as a normal user (this was in about 1997 or '98)…
for help i went to a private forum where i knew some old gray haired
folks with Big Blue/Big Iron experience…i told them that ‘suddenly’
i couldn’t log into my Red Hat (i think, at the time)…they laughed a
little and told me how to fix the permissions of /.ICEauthority and
included this explaination: “because the GUI Environment Manager
writes all sorts of hidden files all over the place, and if they’re
owned by ROOT they’ll get in your way when you’re logged in as
yourself. This will be true no matter how careful you think you are,
because it’s all automagical and behind your back.”
here are a couple of actual forum posts, both were fixed by repairing
the root logged in damaged permissions:
“error: user’s $Home/.dmrc file is being ignored…must be owned by
user and not writiable by others…Could not update ICE authority file
/home/[Dave]/.ICEauthority”"
“Hi all can any one help me on booting in to gnome desktop i keep
getting this could not update ICEauthority file /home/tip/.ICEauthority”
> Is there a difference between the process execution in the scenarios
> mentioned above?
i have no idea…and, do not intend to tempt fate…
> The example given in the link you referenced doesn’t seem too valid to
> me. Yes, if he was a nonprivledged user it would have saved him, but
> SUing to root and issuing the same command would have cost him the same
> fate. In the end, I would rather have a reliable user login as root,
> then have an average user (or even a careful user) su to root. Obviously
> this is taken in the context of when you MUST use root.
i can’t speak to that…are you saying other parts of that page need
to be edited…anyone can do so, and you seem to be at least as
qualified as i am…
> To tie this into the thread: I was merely suggesting that if those that
> are trying to get Beagle working and cannot use their system (under
> their username) because Beagle is eating their resources, try logging in
> as root to prevent it, fix the problem (disable it), then logout and
> login as Joe or whoever.
i would not recommend that…instead, i would recommend logging into
“fail safe” mode, as Joe, and turning off (or uninstalling with YaST)
beagle, then log into the desired GUI as ‘Joe’…
i can’t think of a place where it is absolutely required to enter a
*nix GUI as ‘root’…can you?
–
natural_pilot
>sorry for the delay, life intervened…
>and, sorry for the long post, it is the best >i can do:
It’s all good. I appreciate all the replies.
>i have just made a couple of minor edits to >the page to help it to
>better reflect reality…are they ok with you?
It’s good, I was just confused since so many things were buggy with OS 11.
>i can give you two examples:
>
>in each user’s /home there is a hidden file >named .ICEauthority which
>MUST be user readable and writable…there >are circumstances (which i
>can’t describe) when that file or its >permissions get accidentally
>changed if root signs into the GUI and does >something…
>i can’t say what ‘something’, because i do >not know what i did…but
>i know i did it and i know that afterwards i >could NOT log in as
>myself as a normal user (this was in about 1997 or '98)…
>…
>the time)…they laughed a
>little and told me how to fix the permissions >of /.ICEauthority and
>included this explaination: “because the GUI >Environment Manager
>writes all sorts of hidden files all over the >place, and if they’re
>owned by ROOT they’ll get in your way when >you’re logged in as
>yourself. This will be true no matter how >careful you think you are,
>because it’s all automagical and behind your >back.”
Excellent. Thanks for the hard info. I checked my system and it seems like I’m fine, but I was unaware of the issue, as I use the CLI most of the time. I will make sure to avoid this. I’ve always been told to avoid root, strictly due to user error. This is a real issue to be concerned with.
> The example given in the link you referenced doesn’t seem too valid to
> me. Yes, if he was a nonprivledged user it would have saved him, but
> SUing to root and issuing the same command would have cost him the same
> fate. In the end, I would rather have a reliable user login as root,
> then have an average user (or even a careful user) su to root. Obviously
> this is taken in the context of when you MUST use root.
>i can’t speak to that…are you saying other >parts of that page need
>to be edited…anyone can do so, and you >seem to be at least as
>qualified as i am…
I just think it’s a poor example of why you should not log in as root, especially with the real compelling reasons you just listed.
> To tie this into the thread: I was merely suggesting that if those that
> are trying to get Beagle working and cannot use their system (under
> their username) because Beagle is eating their resources, try logging in
> as root to prevent it, fix the problem (disable it), then logout and
> login as Joe or whoever.
>i would not recommend that…instead, i >would recommend logging into
>“fail safe” mode, as Joe, and turning off (or >uninstalling with YaST)
>beagle, then log into the desired GUI >as ‘Joe’…
In light of what you have mentioned, I agree.
>i can’t think of a place where it is >absolutely required to enter a
>*nix GUI as ‘root’…can you?
Well, as I mentioned, I don’t really use the GUI unless I don’t know how to do it via the command line. The machine is at my home and I travel for work. Many hotels have very slow internet and the CLI is very usable in that respect.
To answer you question, I can not think of a situation.
Thanks,
WT