Hi, MAXSRV does NOT set the maximum number of afpd connections! It sets the maximum number of cnid_dbd processes of which one is necessary per volume.
What probably does affect the maximum number of possible afpd connections is the very low default value of fd_table_size (see man cnid_dbd) which is 16. fd_table_size is the maximum number of concurrent open connections possible between the cnid_dbd process for a volume and afpd client processes. Once this table is full, cnid_dbd will drop the oldest connection. The afpd of the dropped connection then will reconnect once it needs to query the cnid_dbd. This connecting/disconnecting concurreny possibly by itself or by further exposing bugs might result in a limit you experienced in the first place. What you should do instead is raise fd_table_size in /path/to/volume/.AppleDB/db_param to some reasonable high value. I'd be very interested if you can test this and provide feedback, because I'm currently reviewing the cnid dbd backend. F'up to netatalk-devel or PM. Regards -Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org