Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 2 down vote favorite

I tried to use Linux GUI for Fedora but I did not find it intuitive than that of windows.

Whenever I tried installing any software using rpm file by double clicking file, many times it stuck and when I reinvoke that from terminal it says yum is already locked and some other installation process is already running and I always have to force quit that process.

From OS point of view this seems to be Scheduling problem. (How) can we replace scheduling for Linux x window? Is there any better scheduling available for Fedora linux x window?

Update:

Sorry about late response:

=> When I double click rpm package , it does not show up anything even after waiting for two minutes.

=> When I try to invoke that package from command line thinking something wrong with Fedora GUI it throws me a message saying some other process has the lock.

=> When I kill that process using kill command and try to install using command line it starts with no problems.

=> Many times when I don't kill the process after invoking rpm installation package, I start doing some other work, after more than 15 minutes the installation window comes from nowhere asking for root password, after entering which I get window for downloading dependencies ?

Can somebody clarify me how this problem is not related to scheduling ?

share|improve this question
6  
This is unlikely a scheduling issue and more likely related to the fact that most package management systems are designed so that you can't run multiple package management tools at the same time. Perhaps you could edit your question to include a detailed description of what you are doing and the error messages you receive. – Steven D Oct 5 '10 at 3:10
I agree with the this is nonsensical opinion on meta; I have no idea what you're asking. If you edit it to clarify what you mean we can always reopen it – Michael Mrozek♦ Oct 7 '10 at 3:01
Ok, now that you've explained your problem by detailing the behavior you observe, your question makes sense. I still have a few pieces of advice. 1. Don't make assumptions: nothing in your problem suggests a scheduling issue, so don't mention scheduling. 2. Don't insult the people who might help you — starting off a question on a unix forum by saying Windows is better isn't going to motivate answerers. 3. Your revision shows you've followed some of its advice already, but read catb.org/esr/faqs/smart-questions.html . – Gilles Oct 10 '10 at 8:25

1 Answer

up vote 2 down vote accepted

(This is only an answer to your incidental question, not to your main question, but it's too long to put in a comment.)

  • Your problem has nothing to do with processor time scheduling, which is about sharing CPU time between concurrent applications. When you click on a rpm package, the GUI package manager starts, and it continues to run until it's done its job; that's exactly the desired behavior. The fact that the package manager takes more than a couple of seconds to do its first visible subtask (show the password prompt) is a bug or misconfiguration, but it has nothing to do with scheduling.
  • More generally, scheduling can refer to the attribution of a shared resource to concurrent processes over time. Here the interesting shared resource is the package database. Here also, everything is happening normally: when you click on the rpm package, the GUI package installer immediately starts using it, which is exactly what you requested. Since only one package manager can use the package database at the same time (which is why it takes a lock), you can't start the command-line package manager (rpm) while the GUI package manager is running; even looking at it from a highly theoretical perspective, this is a locking issue, not a scheduling issue.
  • Scheduling can also refer to scheduling a program for later running; I think it's the primary meaning of the word in the Windows world (“scheduled tasks”), but it's not used as much in the unix world (where “scheduling” out of context refers to CPU scheduling as in my first bullet point above, and people tend to speak of cron jobs).

Turning to your main question, the long delay in starting the GUI package manager is a bug or misconfiguration in that particular program. I don't know anything about that program, so I'm afraid I can only provide a few generic investigation suggestions. I'll be asking many questions; the more you answer, the better help you're likely to get.

  • Is this happening from Fedora out-of-the-box or did you configure some things that may be relevant? What exact version of Fedora is this anyway? What architecture (e.g. i386 or amd64)? Is there any virtualization involved?
  • Does anything appear in the system logs? (ls -ltr /var/log, and look at any log entry produced when or after you click on the rpm package)
  • What is the package manager doing? Is it taking CPU time (top or htop or any of many GUI system activity monitors)? Is it doing disk I/O (iotop or any of a few GUI system activity monitors or listen to your hard drive if it's near you)? Is it doing network I/O (tcpdump or Wireshark or ntop)? Even better, use ps xww or some other process viewer to find out the process ID and run strace -s9999 -p$PID to observe what it's doing that's taking so long.
  • Do you have the same issue if you start the package manager from your desktop environment's menus?
share|improve this answer
It has happened to me (not lately on Fedora) that some background job futzes around with the repository (locking it), and meanwhile nothing package-related works. – vonbrand Jan 16 at 0:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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