My render keeps failing and offering only this one-word explanation: 
'killed', which, when written over 'rendered n of m pixels', looks like 
'killeded'.

Anybody want to take a wild @ss guess? Maybe a compilation issue. 
Auto-complete in a shell fails as well. That's all the information I can 
offer.

Any help appreciated.

Post a reply to this message

Am 30.07.2013 20:21, schrieb Shay:
> My render keeps failing and offering only this one-word explanation:
> 'killed', which, when written over 'rendered n of m pixels', looks like
> 'killeded'.
>
> Anybody want to take a wild @ss guess? Maybe a compilation issue.
> Auto-complete in a shell fails as well. That's all the information I can
> offer.
>
> Any help appreciated.

Is that your very own private computer?

If not, maybe there is a tool running on the machine that automatically 
kills processes that are eating a lot of CPU power.

Post a reply to this message

My very own private computer, but this is worth investigating. I'm going to 
ask on the Mepis group.

Thank you.

"clipka"  wrote in message news:51f805df$1@news.povray.org...

Am 30.07.2013 20:21, schrieb Shay:
> My render keeps failing and offering only this one-word explanation:
> 'killed', which, when written over 'rendered n of m pixels', looks like
> 'killeded'.
>
> Anybody want to take a wild @ss guess? Maybe a compilation issue.
> Auto-complete in a shell fails as well. That's all the information I can
> offer.
>
> Any help appreciated.

Is that your very own private computer?

If not, maybe there is a tool running on the machine that automatically
kills processes that are eating a lot of CPU power.

Post a reply to this message

"clipka"  wrote in message news:51f805df$1@news.povray.org...
> If not, maybe there is a tool running on the machine that automatically 
> kills processes that are eating a lot of CPU power.

Looks like that's it. Linux-guru diagnosis points to the "OOM killer," a 
process that kills other processes when Linux runs out of RAM. I can buy 
more RAM, increase my swap partition, or remove some hidden objects from my 
scene.

I'd go straight for the RAM if I KNEW it would solve the problem, but 
that'll require travel, time, and head scratching with no guarantee of 
results. I'll try to "fix" the scene tonight. Thanks for pointing me in the 
right direction.

-Shay

Post a reply to this message

Am 31.07.2013 19:49, schrieb Shay:
>
> "clipka"  wrote in message news:51f805df$1@news.povray.org...
>> If not, maybe there is a tool running on the machine that
>> automatically kills processes that are eating a lot of CPU power.
>
> Looks like that's it. Linux-guru diagnosis points to the "OOM killer," a
> process that kills other processes when Linux runs out of RAM.

Is that physical RAM or swap space?

Either way, this indeed sounds like a smart thing to do. Because if 
POV-Ray starts swapping you can kiss your render performance goodbye 
anyway, and it does seriously endanger overall system performance.

> I can buy
> more RAM, increase my swap partition, or remove some hidden objects from
> my scene.

Never mind increasing the swap partition - you absolutely positively do 
want POV-Ray to render out of genuine physical RAM.

(Then again, if you buy more RAM, you might still need to increase the 
swap partition anyway; AFAIK Linux insists on each page of physical RAM 
being backed by a page of swap space, so swap space = physical memory is 
the absolute minimum.)

Post a reply to this message

>"clipka"  wrote in message news:51fa0312@news.povray.org...

>> Looks like that's it. Linux-guru diagnosis points to the "OOM killer," a
>> process that kills other processes when Linux runs out of RAM.

> Is that physical RAM or swap space?

This is from user timkb4cq on the mepiscommunity.org forum:

"There's an old debian bug report about Pov-Ray running out of memory & when 
the user increased the size of his swap file to try to get around that it 
would fail with "killed" instead of "out of memory". I haven't found any 
solution given other than decreasing resolution or installing more ram in 
the box..."

Further replies directed me toward the OOM Killer.

> (Then again, if you buy more RAM, you might still need to increase the 
> swap partition anyway; AFAIK Linux insists on each page of physical RAM 
> being backed by a page of swap space, so swap space = physical memory is 
> the absolute minimum.)

I learn something new every day. No time to fool with it at the moment. I 
allow myself about 20 minutes a day to mess with anything computer related 
at home.

-Shay

Post a reply to this message

On 08/01/2013 08:36 AM, Shay wrote:
>
>
>> "clipka"  wrote in message news:51fa0312@news.povray.org...
>
>>> Looks like that's it. Linux-guru diagnosis points to the "OOM killer," a
>>> process that kills other processes when Linux runs out of RAM.
>
>> Is that physical RAM or swap space?
>
> This is from user timkb4cq on the mepiscommunity.org forum:
>
> "There's an old debian bug report about Pov-Ray running out of memory &
> when the user increased the size of his swap file to try to get around
> that it would fail with "killed" instead of "out of memory". I haven't
> found any solution given other than decreasing resolution or installing
> more ram in the box..."
>
> Further replies directed me toward the OOM Killer.
>
>> (Then again, if you buy more RAM, you might still need to increase the
>> swap partition anyway; AFAIK Linux insists on each page of physical
>> RAM being backed by a page of swap space, so swap space = physical
>> memory is the absolute minimum.)
>
> I learn something new every day. No time to fool with it at the moment.
> I allow myself about 20 minutes a day to mess with anything computer
> related at home.
>
> -Shay
If this system /isn't/ your primary, perhaps there are other services 
that can be turned off to regain some overhead ... X11, mysql, file 
system indexing service(s)

Post a reply to this message

"James Holsenback"  wrote in message news:51fa6eb5$1@news.povray.org...

> If this system /isn't/ your primary, perhaps there are other services that 
> can be turned off to regain some overhead ... X11, mysql, file system 
> indexing service(s)

Pretty much just for rendering. Has 4G RAM with iirc room for 4 more.

I could figure out what you describe--until recently, Linux exclusively at 
home for 10 years or so.

But I can’t just sit down and do it.

The plan now is to remove a few hidden objects, boot to runlevel 2, and 
render with
povray scene.pov && povray +C scene.pov  && povray +C scene.pov

Post a reply to this message

On 08/01/2013 10:56 AM, Shay wrote:
> The plan now is to remove a few hidden objects, boot to runlevel 2, and
> render with
> povray scene.pov && povray +C scene.pov  && povray +C scene.pov

yep ... that ought to get rid of the "fluff" (so to speak)

wondering if "nice" could be helpful

Post a reply to this message