winsup/cygserver/cygserver.conf

   1 # cygserver.conf
   2 #
   3 # Contains configurable parameters for the cygserver.
   4 #
   5 # The format of this file is easy.  Lines beginning with a hash `#' are
   6 # comments and ignored.  Lines consisting of only whitespaces are ignored.
   7 # Any other line is a setting for cygserver.
   8 # A setting consists of a name/value pair, separated by whitespace.
   9 # Each line must only consist of one name/value pair.
  10 # Lines must not be longer than 1023 characters.
  11 #
  12 # Some settings can be overridden by a command line switch.  If so, it's
  13 # mentioned below.
  14 #
  15 # Settings which are commented out will use the default values.  These are
  16 # mentioned below, too.
  17
  18 # kern.srv.cleanup_threads: No. of cygserver threads used for cleanup tasks.
  19 # Default: 2, Min: 1, Max: 16, command line option -c, --cleanup-threads
  20 #kern.srv.cleanup_threads 2
  21
  22 # kern.srv.request_threads: No. of cygserver threads used to serve
  23 #                           application requests.
  24 # Default: 10, Min: 1, Max: 310, command line option -r, --request-threads
  25 #kern.srv.request_threads 10
  26
  27 # kern.srv.process_cache_size: No. of concurrent processes which can be handled
  28 #                              by Cygserver concurrently.
  29 # Default: 62, Min: 1, Max: 310, command line option -p, --process-cache
  30 #kern.srv.process_cache_size 62
  31
  32 # kern.srv.msgqueues: Determines whether XSI Message Queue support should be
  33 # started, "yes" (or "true", "y", "t", "1") or "no" (or "false", "n", "f", "0").
  34 # These values are valid for all binary type options.
  35 # Default is "yes".  Command line option -q, --no-msgqueues
  36 #kern.srv.msgqueues yes
  37
  38 # kern.srv.semaphores: Determines whether XSI Semaphore support should be
  39 # started.  Default is "yes".  Command line option -s, --no-semaphores
  40 #kern.srv.semaphores yes
  41
  42 # kern.srv.sharedmem: Determines whether XSI Shared Memory support should be
  43 # started.  Default is "yes".  Command line option -m, --no-sharedmem
  44 #kern.srv.sharedmem yes
  45
  46 # LOGGING
  47
  48 # kern.log.syslog: Determines whether logging should go to the syslog,
  49 # Default is "yes", if stderr is no tty, "no" otherwise.
  50 # Command line option -y, --syslog or -Y, --no-syslog.
  51 #kern.log.syslog no
  52
  53 # kern.log.stderr: Determines whether logging should go to stderr,
  54 # Default is "yes", if stderr is a tty, "no" otherwise.
  55 # Command line option -e, --stderr or -E, --no-stderr.
  56 #kern.log.stderr no
  57
  58 # kern.log.level: Logging level.  Valid values are 1 to 7 with a bigger
  59 # value emitting more logging output.  Default level is 6.
  60 # Command line option -l, --log-level.
  61 #kern.log.level 6
  62
  63 # kern.log.debug: Determines whether debug output should be printed to stderr.
  64 # Default is "no".  Command line option -d, --debug
  65 #kern.log.debug no
  66
  67 # XSI message queue parameters.
  68 #
  69 # Each message is broken up and stored in segments that are msgssz bytes
  70 # long.  For efficiency reasons, this should be a power of two.  Also,
  71 # it doesn't make sense if it is less than 8 or greater than about 256.
  72
  73 # kern.ipc.msgseg: Maximum no. of message queue segments hold concurrently.
  74 # Default: 2048, Min: 256, Max: 65535
  75 #kern.ipc.msgseg 2048
  76
  77 # kern.ipc.msgssz: Size of segment in bytes.  Must be a power of 2 value.
  78 # Default: 8, Min: 8, Max: 1024
  79 #kern.ipc.msgssz 8
  80
  81 # kern.ipc.msgmnb: Maximum no. of bytes in a single message queue.
  82 # Default: 2048, Min: 1, Max: 65535
  83 #kern.ipc.msgmnb 2048
  84
  85 # kern.ipc.msgmni: Maximum no. of message queue identifiers hold concurrently.
  86 # Default: 40, Min: 1, Max: 1024
  87 #kern.ipc.msgmni 40
  88
  89 # kern.ipc.msgtql: Maximum no. of messages hold concurrently.
  90 # Default: 40, Min: 1, Max: 1024
  91 #kern.ipc.msgtql 40
  92
  93 # XSI semaphore parameters
  94
  95 # kern.ipc.semmni: Maximum no. of semaphore identifiers hold concurrently.
  96 # Default: 10, Min: 1, Max: 1024
  97 #kern.ipc.semmni 10
  98
  99 # kern.ipc.semmns: Maximum no. of semaphores hold concurrently.
 100 # Default: 60, Min: 1, Max: 1024
 101 #kern.ipc.semmns 60
 102
 103 # kern.ipc.semmnu: Total no. of undo structures hold by server.
 104 # Default: 30, Min: 1, Max: 1024
 105 #kern.ipc.semmnu 30
 106
 107 # kern.ipc.semmsl: Maximum no. of semaphores per semaphore id.
 108 # Default: 60, Min: 1, Max: 1024
 109 #kern.ipc.semmsl 60
 110
 111 # kern.ipc.semopm: Maximum no. of operations per semop call.
 112 # Default: 100, Min: 1, Max: 1024
 113 #kern.ipc.semopm 100
 114
 115 # kern.ipc.semume: Maximum no. of undo entries per process.
 116 # Default: 10, Min: 1, Max: 1024
 117 #kern.ipc.semume 10
 118
 119 # kern.ipc.semvmx: Maximum value of a semaphore.
 120 # Default: 32767, Min: 1, Max: 32767
 121 #kern.ipc.semvmx 32767
 122
 123 # kern.ipc.semaem: Maximum value to adjust on process exit.
 124 # Default: 16384, Min: 1, Max: 32767
 125 #kern.ipc.semaem 16384
 126
 127 # XSI shared memory parameters
 128
 129 # kern.ipc.shmmaxpgs: Maximum pages available for XSI shared memory.
 130 # Changing shmmaxpgs immediately affects setting SHMMAX.  The relation
 131 # between shmmaxpgs and SHMMAX is:  SHMMAX = shmmaxpgs * getpagesize().
 132 # Default: 8192, Min: 1, Max: 32767
 133 #kern.ipc.shmmaxpgs 8192
 134
 135 # kern.ipc.shmmni: Maximum number of shared memory segments, system wide.
 136 # Default: 192, Min: 1, Max: 32767
 137 #kern.ipc.shmmni 192
 138
 139 # kern.ipc.shmseg: Maximum number of shared memory segments per process.
 140 # Default: 128, Min: 1, Max: 32767
 141 #kern.ipc.shmseg 128
 142
 143 # kern.ipc.shm_allow_removed: Determines whether a process is allowed to
 144 # attach to a shared memory segment (using the shmat call) after a successful
 145 # call to shmctl(IPC_RMID).  This is a Linux-specific, and therefore
 146 # non-portable feature.  Use with care.  Default is "no".
 147 #kern.ipc.shm_allow_removed no