On 5/14/21 6:31 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>>> The 'cannot fork' stuff usually happens when a unix/linux system has run
>>> out of resources to start another process. Lack of memory/swap space,
>>> /tmp, /var - maybe. There are sometimes limits on the number of
>>> processes in place, but this in my experience is not all that common.
>>>
>>> For starters you could try running the 'df' command and look at disk
>>> usage. The command 'free -m' can be useful too.
>
>> - What was your entire command line with flags & ini ?
> 
> Er, for what?

No idea. I'm fishing for cause. :-)

The 'no output at all' you now see makes as little sense to me - as a 
likely problem - as did the unable to fork message.

The cannot create state file is what I got too - with 'povr' - when 
trying reproduce your fork issue last night and not having permissions 
to write to the current directory.

As I expect you know by now, directories installed system wide as 
packages or with 'make install' / 'sudo make install' almost always have 
an owner of root. Further they are read only except for the owner. Those 
permissions should be left as is to prevent accidental corruption. 
Normal users - even those able to play as 'root' should work elsewhere 
in directories and with files they do own.

The povr script ships in the root build directory but must be modified 
and installed somewhere in your PATH. If you type the command:

'which povr'

what do you see?

I see: /home/pokorny/bin/povr because I copied the povr script to my 
/home/pokorny/bin directory - which is part of my PATH environment 
variable by default. Plus, I updated the contents of 'povr' to point to 
the build location directory. You can point the 'povr' script to an 
install directory too, if you configured with 
--prefix=<eventual_install_dir> before building and after a successful 
'make install'.

'echo $PATH'

shows the contents of the search path used for executable commands.

You can execute commands with the full path assuming the permissions are 
set for an executable. For example, no matter the current directory 
permissions, I can type:

'/home/pokorny/bin/povr --version'

and see in the output:
...
POV-Ray (povr) 3.8.0-x.povr_19812865.unofficial
This is an unofficial version compiled by: wfp
...

Further, such a full path command should run in any directory no matter 
permissions so long as the permission bits are set correctly. When I use 
the command:

ls -lt /home/pokorny/bin/povr

I see:

-rwxr-xr-x 1 pokorny pokorny 806 May 14 17:53 /home/pokorny/bin/pov

Let's start the debugging with the commands above.

> 
...
> 

Aside: As a general aim I'm thinking most unix/linux users should 
install packages maintained for their OS distributions.

For those wanting to play with code branches, a goal of the povr branch 
is to NOT use or need 'root' or 'admin' authority at all. Further, to be 
able to run as many versions side by side as they wish in local, 
smallish, directories without cross interactions - something long an 
issue. There are tentative code changes in the povr branch to support 
this aim. For more see, for example:

https://github.com/POV-Ray/povray/issues/374

The povr script as shipped is a template, and for users in the playpen, 
like me, I have many such scripts pointing to different versions. Where 
'povr' as a command is how I execute my most current code and compile.

Bill P.

Post a reply to this message