dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Aug 10, 2010 at 11:00:32AM -0000, Chris Richardson wrote:
> Looking at the strace output for the non-privileged user, there are
> these lines:-
>
> [pid 14985] unlink("//vmlinuz.old")     = -1 EACCES (Permission denied)
> [pid 14985] unlink("//initrd.img.old")  = -1 EACCES (Permission denied)
> [pid 14985] unlink("//lib64")           = -1 EACCES (Permission denied)
> [pid 14985] unlink("//initrd.img")      = -1 EACCES (Permission denied)
> [pid 14985] unlink("//vmlinuz")         = -1 EACCES (Permission denied)

!

> Of course, as root, all this is possible: I think the key line is unlink ("//lib64") which then makes everything unusable.
> Also, I didn't manage to cause a system crash on 32-bit machines.
>
> Investigating the damaged filesystem, there is little else wrong, so at least I can restore the machine by recreating the
> /lib64 link.
>
> But why is it trying to delete these files?

I have no idea. It looks like it may be related to OpenMPI (judging by
other things happening near those lines).

I'll try to reproduce it here (the strace thing, not the root
thing...). :-)

--
Anders

-- 
Failed X connection corrupts root filesystem
https://bugs.launchpad.net/bugs/615250
You received this bug notification because you are a member of DOLFIN
Team, which is subscribed to DOLFIN.

Status in DOLFIN: New

Bug description:
I noticed this problem a while ago, and just fell victim to it again this morning.

I was doing a dolfin install from bzr as root on Ubuntu Lucid 10.4 64-bit server.
When running a demo, if the X forwarding is not correctly set, then the code crashes in a plot() call, with a PETSC error. Subsequently, the root file system is severely damaged, and the only option seems to be a complete reinstall of the OS.

I know, this can be avoided by not running the demos as root, but it is an easy mistake to make after doing a system-wide install.
I presume it is a bug in viper.

Any ideas?

Thanks

Chris Richardson