Joachim Schipper wrote:
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.
Couldn't login with a specific user that gets:
Server sent disconnect message
type 2 (SSH_DISCONNECT_PROTOCOL_ERROR):
"fork failed: Resource temporarily unavailable"
Looks like all process were in used and couldn't be kill because it was
going to corrupt data and create a lots more work.
I searched google more this morning and spend a few hours trying to find
a solutions. I thought that increasing the limits inside login.conf
would be pickup right away at the next login, but look like it didn't,
or may be it doesn't do it as long as the users account is in use, I
don't know.
In any case, the problem got so critical that I had to make the choice
between giving myself a few days more work at cleaning up the mess of
data corruptions or not allowing access to changed critical informations
needed to be changed.
It wasn't the best choice obviously, but time was the issue at hand and
I add to kill many process to free resources to allow this.
So, I wish I got something working sooner, or find how to do this
properly, but didn't! So, I fix the issue with some damage to my free
time, but all users and process are doing their thing normally without
anything affecting them.
Anyway, thanks for your feedback, but I had to make a choice and did it
at the expense of a few white night coming up for me! Like I can sleep
already! (:<
Thanks
Daniel
