When I open a shell, if I want to run midnight commander, when I type
“mc”, the shell hangs for 5-10 seconds before opening midnight commander.
Seeing as how I am running with 16gb of ram and a quad-core processor,
and this has happened even with nothing else running while my system
load viewer shows all resources almost entirely open, I don’t think
there is a limitation on my system. I will, however, note that while it
normally hangs about 6 seconds in a bash shell before opening, in a tty
terminal, it only hangs about 2 seconds before opening.
Earlier, I accidentally closed a shell with the close button
while midnight commander was still open, and the process hung up so bad
I could not kill it in any way. I could not run mc again in any way, and
I had to reboot.
Is there a particular log or something to look at in order to figure out
what is going on? Or should I just go ahead and open up a new bug report…
Running 12.3 with KDE 4.10
George
–
G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.2 | KDE 4.10 | Core i7-2620M | 64 | 8GB
learning openSUSE and loving it
On 04/05/2013 09:41 AM, golson765 wrote:
> Is there a particular log or something to look at in order to figure out
> what is going on? Or should I just go ahead and open up a new bug report…
have used mc for years and generally (even on weak systems) it is
near instantaneous… so, while there may be a corner case there i
kinda think it is instead some corruption somewhere…
i wonder where you got mc, how you installed it and what version you
have?
and, what kinds of customizations have you made to your shell? like,
to bashrc…anything extra added??
was mc always like this or did it suddenly one day cause you to wait
well…from here i can’t imagine what you may have done to your
system, but i can tell you that mc ought to be like lightening…
On 04/05/2013 07:45 PM, dd wrote:
> On 04/05/2013 09:41 AM, golson765 wrote:
>> Is there a particular log or something to look at in order to figure out
>> what is going on? Or should I just go ahead and open up a new bug
>> report…
>
> have used mc for years and generally (even on weak systems) it is near
> instantaneous… so, while there may be a corner case there i kinda
> think it is instead some corruption somewhere…
>
> i wonder where you got mc, how you installed it and what version you
> have?
>
> and, what kinds of customizations have you made to your shell? like,
> to bashrc…anything extra added??
>
> was mc always like this or did it suddenly one day cause you to wait
>
> well…from here i can’t imagine what you may have done to your
> system, but i can tell you that mc ought to be like lightening…
>
I just installed it from the regular repositories - openSUSE-12.3-Oss.
It is version 4.8.1.4-2.1.2. I haven’t made any customizations to my
shell other than adjusting the color and font size.
mc has been like this since I installed 12.3. So I was assuming there
was someissue there.
Should I uninstall it and reinstall it?
–
G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.2 | KDE 4.10 | Core i7-2620M | 64 | 8GB
learning openSUSE and loving it
On 04/05/2013 11:08 PM, dd wrote:
> On 04/05/2013 04:08 PM, golson765 wrote:
>> Should I uninstall it and reinstall it?
>
> i am really stumped…i’d say, yes uninstall it with YaST Software
> Management
>
> then go into your home rename the hidden directory /.mc to something
> else, like .mc_old
>
> you could do that in a user terminal, as yourself…
>
> read the caveat in my sig.
>
> and, in the same terminal become root nd rename the directory /etc/mc
> to mc-old, like
>
>
> su -
> rename /etc/mc /etc/mc_old
>
the purpose of all of that is to not allow the new install to take
over the existing configs–which i guess at least one is corrupted…
then use YaST Software Management to install it again.
(say, did you upgrade from some former linux to openSUSE 12.3?)
then, if mc works better you can delete the mc_old directories, but it
works worse you can reclaim the old six second version . . .
strange!!
Well, I uninstalled mc renamed directories, and then re-installed it as
suggested. However, no change - it still hangs 6-10 sec whenever I want
to start up mc.
One interesting thing to note. When I re-installed it, there were 2
unusual things happening:
george@linux-ip49:~> sudo zypper in mc
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following NEW package is going to be installed:
mc
The following package is recommended, but will not be installed due to
conflicts or dependency issues:
bundle-lang-common-cs
1 new package to install.
Overall download size: 688.0 KiB. After the operation, additional 2.2
MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package
mc-4.8.1.4-2.1.2.x86_64
(1/1), 688.0 KiB ( 2.2 MiB unpacked)
Retrieving: mc-4.8.1.4-2.1.2.x86_64.rpm
..............................................................................................[done
(208.4 KiB/s)]
(1/1) Installing: mc-4.8.1.4-2.1.2
.................................................................................................................[done]
Additional rpm output:
setting /usr/lib/mc/cons.saver to root:root 4755. (wrong permissions 0755)
So there was a language bundle that was not installed, and a file in
/usr/lib/mc that needed the permissions changed. That file (cons.saver)
has permissions that look like this:
george@linux-ip49:/usr/lib/mc> ls -l
total 20
-rwsr-xr-x 1 root root 10624 Feb 2 00:02 cons.saver
drwxr-xr-x 2 root root 4096 Apr 10 08:44 extfs.d
drwxr-xr-x 2 root root 4096 Apr 10 08:44 fish
What is the meaning of “s” in the user permissions for that file?
–
G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.2 | KDE 4.10 | Core i7-2620M | 64 | 8GB
learning openSUSE and loving it
mc - Midnight Commander has always worked well for me. I think you can get it to install during openSUSE installation by checking Console Tools or just search for mc later from the YaST / Software Management application.
–> What is the meaning of “s” in the user permissions for that file?
Chmod and the mysterious first octet
It has been pointed out to me that I should include info on the setuid, setgid and sticky bit settings. S.A.F.P. - SUSE Automated File Permissions, ignores these three bits in this example. For completeness, this is their meaning.
The chmod number actually includes four octal digits, not just three, but generally, the front & fourth digit is zero as in 0777. The weight of this front (first) number is as follows:
4 - setuid (letter-style: s, displayed the added letter s, i.e. -rwsrwxrwx)
2 - setgid (letter-style: s, displayed the added letter s, i.e. -rwxr-s—)
1 - sticky bit (letter-style: t, displayed the added letter s, i.e. drwxrwxrwt)
The meaning of these bits is said to mean:
**Setuid and Setgid Bits **
chmod clears the set-group-ID bit of a regular file if the file’s group ID does not match the user’s effective group ID or one of the user’s supplementary group IDs, unless the user has appropriate privileges. Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.
chmod preserves a directory’s set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like u+s and g-s, and you can set (but not clear) the bits with a numeric mode.
Restricted Deletion Flag or Sticky Bit
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program’s text image on the swap device so it will load more quickly when run; this is called the sticky bit.
> The following package is recommended, but will not be installed due to
> conflicts or dependency issues:
the above tells me that you are probably not following the advice
which usually avoids all conflicts–that excellent advice is in the
paragraph beginning with “IMPORTANT” in the post at http://tinyurl.com/33qc9vu
that advice is given to those who are new to openSUSE…and i still
follow oldcpu’s sage advice, my repos on any normal day won’t allow
conflicts, http://paste.opensuse.org/83273901
when i know i need something from any of those recommended, i enable
them…do what i wanna do and then disable them again…
> george@linux-ip49:/usr/lib/mc> ls -l
> total 20
> -rwsr-xr-x 1 root root 10624 Feb 2 00:02 cons.saver
> drwxr-xr-x 2 root root 4096 Apr 10 08:44 extfs.d
> drwxr-xr-x 2 root root 4096 Apr 10 08:44 fish
my permissions are exactly the same…and, i am completely out of
ideas except:
if you use YaST > Security and Users > User and Group Management to
temporarily add a new TestUser, then log out and log back in as the
TestUser, is the problem resolved?
I get those same errors when doing a new install of mc but it still starts up almost instantly. Maybe something on the wiki would help you out doc/faq – Midnight Commander