Memcached listens on port when -m is not given a argument even when started with -s

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start memcached with: memcached -d-m -s  ~/new.sock

What is the expected output? What do you see instead?
I expect:
memcached -d -m -s  ~/new.sock to fail since
-m is not given an argument and
"netstat -anp|grep 11211" 's output to be blank, instead I get:

# netstat -anp|grep 11211
tcp        0      0 0.0.0.0:11211               0.0.0.0:*                   
LISTEN      13861/memcached     
tcp        0      0 :::11211                    :::*                        
LISTEN      13861/memcached     
udp        0      0 0.0.0.0:11211               0.0.0.0:*                       
        13861/memcached     
udp        0      0 :::11211                    :::*                            
        13861/memcached  

What version of the product are you using? On what operating system?
1.4.15 on CentOS 6.3 x86_64

Please provide any additional information below.
This does not happen when -m is given a proper argument like "-m 20"

Original issue reported on code.google.com by m...@nero.im on 17 Jan 2013 at 8:04

[GoogleCodeExporter]

-m defaults to 64, so if you don't give it an argument it uses the default?

Actually apparently it sets limit_maxbytes to 0 if you do that. Guess we'll fix.

memcached will still work if you set limit_maxbytes to 0, as it'll put one slab 
page into each slab class.

Original comment by dorma...@rydia.net on 18 Jan 2013 at 6:27

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The focus of my bug report wasn't limit_maxbytes, but that when -m is passed 
without an argument, memcached is binding to 0.0.0.0:11211. It shouldn't be; it 
should behave exactly as if it was passed '-m 64', which means listening only 
on the socket file.

Original comment by m...@nero.im on 18 Jan 2013 at 6:39

[GoogleCodeExporter]

ok, we'll look into that too.

Original comment by dorma...@rydia.net on 22 Jan 2013 at 5:45

[GoogleCodeExporter]

This is an incorrect assumption om hos argument and options work. What happens 
here is that it believes that the next ting you passer will be the value for -m 
and you're out of sync with options and their arguments.

Original comment by trond.no...@gmail.com on 22 Jan 2013 at 7:24

• Changed state: Invalid

[GoogleCodeExporter]

I understand that we are executing it incorrectly but still it should at least 
warn that the arguments have not been specified and it is resorting to the 
default and why does not specifying an argument have a side effect of it 
listening on port?

Original comment by m...@nero.im on 22 Jan 2013 at 10:31