running memcached in daemon mode vs locking down memory

[dormando]

I got a copy of the original mail just fine. A lot of folks have been
reporting sending mails and not getting them... or getting many many
copies of a mail. Brad; will our schedules overlap soon? :)

Anyway, from the man page:

Memory locks are not inherited by a child created via fork(2)  and  are
automatically  removed  (unlocked)  during  an  execve(2)  or  when the
process terminates.
---

And eyeballing the code, that's totally right. -k was fixed once already
by Tomash, but I guess we now know he runs memcached in the foreground :)

Fix tested and pushed to stable svn and stable git:
http://consoleninja.net/gitweb/gitweb.cgi?p=memcached.git;a=commit;h=7391190f7ff652e662a490d4ca0409dc33fba283

-Dormando

Brad Fitzpatrick wrote:
> Alan, somebody,
> 
> Want to look into this?  (I'm told it was sent to the list, but was
> eaten....)
> 
> 
> On Tue, Jun 10, 2008 at 2:36 PM, Gary Zhu <Gzhu at ironplanet.com
> <mailto:Gzhu at ironplanet.com>> wrote:
> 
>     Is there any reason to NOT lock down paged memory, when running
>     memcached as daemon ? 
> 
>      
> 
>     With current code, -d will effectively ignore –k.
> 
>      
> 
>     I re-arranged the current code as following:
> 
>     From:
> 
>        mlockall
> 
>      setuid
> 
>      daemon
> 
>       …child process…
> 
>      init
> 
>      
> 
>     To :
> 
>     daemon
> 
>      …child process …
> 
>     mlockall
> 
>     setuid
> 
>     init
> 
>      
> 
>     This made –d to work with –k.  
> 
>      
> 
>     The reason is that forked child process does not inherit mlock.  The
>     modified code worked as expected on Solaris 10 and Linux 2.6.x .
> 
>      
> 
>     Let me know any downside of the change.
> 
>      
> 
>     -  Gary
> 
>      
> 
>