On Tue, Apr 18, 2006 at 11:56:11AM -0400, Daniel Ouellet wrote:
> I am having a problem with a specific user account that I can't shutdown 
> as I would create data corruption now if I do so, but I also need to 
> increase the resources of it as that user account can't login via ssh 
> because it reach the limits.
> 
> I get "Disconnecting: fork failed: Resource temporarily unavailable" and 
> looking at the system running, I see that it use all the possible 
> process available to that account.
> 
> I try to change the login.conf to allow more, but it doesn't take effect 
> now.
> 
> Killing the process on that users, I can't do that now as I would at the 
> same time create data corruptions, so I can't do it as these process are 
> manipulating lots of data now.
> 
> So, I am running out of ideas as to what to try to temporary address 
> this issue now and then later make a permanent fix to it.
> 
> Is it possible to do so as it is in use, or do I need to kill it.
> 
> The process in question will continue to run for may be two more days 
> now and I can't really wait that much as it is create real problem now.
> 
> Any advise on this would be more then welcome.
> 
> I am still doing research on Google to see what I can do, and I am sure 
> some how I would find it eventually, but I am a bit in a crunch if 
> someone would have a good suggestion, I would appreciate it.
> 
> I am really starting the fell the heat on this. my problem is more of a 
> timely fix then a proper solutions at this time

It all depends on what is doing the actual constraining. If it is
kern.maxproc, that is easily increased. If it's ulimit or login.conf,
some smarter stuff might need to be done.

gdb or similar could be used to make running processes do what one wants
them to do - for example, to make a few system calls to raise the soft
limit. Of course, this only helps if the soft limit is lower than the
hard limit.

On a slightly more hackish note, liberal use of cp
(.ssh/authorized_keys) and chmod -R g+rwx might create a more-or-less
equivalent account.

                Joachim

Reply via email to