From: unruh@invalid.ca
On 2013-02-05, Jim Beard wrote:
> On 02/05/2013 12:38 PM, unruh wrote:
>> On 2013-02-05, Aragorn wrote:
>>> On Tuesday 05 February 2013 08:28, unruh conveyed the following to
>>> alt.os.linux.mandriva...
>>>
>>>> I am running Madriva 2010.0 on one of my machines (and no I do not
>>>> have the time to upgrade it). I made the mistake of updating it to the
>>>> install all of the updates.
>>>> Now firefox returns with an error message of something like
>>>> .... libx...: unsatisfied reference to
>>>> "cairo_surface_get_reference_count" (the dots are what I cannot
>>>> remember) It however works if I su to root and run firefox from the
>>>> command line. So it really sounds like a permission problem, but I
>>>> have no idea where-- all the files in /usr/lib are rx permission for
>>>> all.
>>>>
>>>> If I run firefox on that machine with X11 forwarding from another
>>>> machine
>>>> everything works fine.
>>>> (Ie, I do
>>>> ssh florid
>>>> (florid is the name of the problematic machine)
>>>> firefox
>>>> so it is running on florid, but displaying on my local machine's X.)
>>>>
>>>> It is really really annoying when stuff like this happens.
>>>>
>>>> texmakerx worked before I did the update but now it says it cannot get
>>>> a lock
>>>> QtLockedFile::lock(): fcntl: No locks available
>>>>
>>>> Again I have no idea what the problem is. Again, it runs fine as root.
>>>> (But in this case I get the same error from a remote machine)
>>>
>>> Bill, I may be out on a limb here - okay, I /am/ - but here's a couple
>>> of questions for you...:
>>>
>>> 1) Did the update also pull in a newer kernel?
>>>
>>> 2) If so, have you rebooted the machine?
>>
>> Yes, I did reboot the machine. I am not sure if it pulled in a new
>> kernel. After batting my head a while, I finally rebooting hoping that
>> might shake something out. It made no change.
>>
>>>
>>> The reason I am asking is because as it turned out in the Gentoo mailing
>>> lists the other day, some device special files may not have been created
>>> in the newest release of udev when the kernel is built without support
>>> for (and automatic kernel-level mounting of) devtmpfs, leading to
>>> similar problems - I can't really recall what they were, but they were
>>> also suspect of permissions issues.
>>>
>>> The problem could of course also be related to dbus. As I understand
>>> it, dbus too has changed quite a lot in the meantime.
>>
>> This upgrade was purely a 2010.0 update, not an upgrade to a later
>> version. Which is what makes it so weird.
>>
>> What in the world is that qtlock? How can it run out of locks, and where
>> are they hidden? And why does firefox and texmakerx work for root but
>> not for user? The user's home is nfs mounted, root is of course on the
>> local machine. Does it make a difference?
>>
>> Just tried it on texmakerx, and yes, on a test account, if I moved the
>> home directory off the nfs mounted partition to a locally mounted one,
>> texmakerx worked. But why would that lock suddenly not work on an nfs
>> mounted partition? It did work before the upgrade.
>>
>> When I get to the machine, I will try to see if firefox behaves the same
>> way.
>
> You may need to restart nfs-common and nfs-server on the
> respective machines, and possibly umount and mount the nfs
> exported partitions (if the file handles have gone stale).
>
> Many locks are kept under /var/lock, but some may be in /tmp or
> $HOME/tmp or in $HOME, perhaps as hidden .files .
>
I restarted the machine, so that should have solved the nfs problems.
I could not find anything in /var/lock, but for something in $HOME it
should not work when I copied the home directory to the local machine,
since it would still be there. But copying the home directory and puttin
in a link at the nfs mounted directory worked. As did changing the home
directory in /etc/passwd and re logging in.
The other weirdness is the firefox problem. This was not cured by moving
the home directory.
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
