Unable to bind socket, error: [Errno 98] Address already in use The ports are not available to bind

[Soundappan Shanmugam]

I'm new to SALTSTACK and trying to install the saltstack server and minion on the same server 

Linux ubuntu 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I installed salt server and minion on the same server using the below commands

apt-get install salt-master

apt-get install salt-minion

apt-get install salt-syndic

I tried configuring the configuration files aswell.

##### Primary configuration settings #####

##########################################

# This configuration file is used to manage the behavior of the Salt Master

# Values that are commented out but have no space after the comment are

# defaults that need not be set in the config. If there is a space after the

# comment that the value is presented as an example and is not the default.

# Per default, the master will automatically include all config files

# from master.d/*.conf (master.d is a directory in the same directory

# as the main master config file)

#default_include: master.d/*.conf

# The address of the interface to bind to

#interface: 0.0.0.0

interface 192.168.2.11

# Whether the master should listen for IPv6 connections. If this is set to True,

# the interface option must be adjusted too (for example: "interface: '::'")

#ipv6: False

# The tcp port used by the publisher

#publish_port: 4505

publish_port:4505 

# The user to run the salt-master as. Salt will update all permissions to

# allow the specified user to run the master. If the modified files cause

# conflicts set verify_env to False.

user: root

# Max open files

# Each minion connecting to the master uses AT LEAST one file descriptor, the

# master subscription connection. If enough minions connect you might start

# seeing on the console(and then salt-master crashes):

#   Too many open files (tcp_listener.cpp:335)

#   Aborted (core dumped)

#

# By default this value will be the one of `ulimit -Hn`, ie, the hard limit for

# max open files.

#

# If you wish to set a different value than the default one, uncomment and

# configure this setting. Remember that this value CANNOT be higher than the

# hard limit. Raising the hard limit depends on your OS and/or distribution,

# a good way to find the limit is to search the internet for(for example):

#   raise max open files hard limit debian

#

#max_open_files: 100000

# The number of worker threads to start, these threads are used to manage

# return calls made from minions to the master, if the master seems to be

# running slowly, increase the number of threads

#worker_threads: 5

# The port used by the communication interface. The ret (return) port is the

# interface used for the file server, authentication, job returnes, etc.

ret_port: 4506

# Specify the location of the daemon process ID file

#pidfile: /var/run/salt-master.pid

# The root directory prepended to these options: pki_dir, cachedir,

# sock_dir, log_file, autosign_file, extension_modules, key_logfile, pidfile.

#root_dir: /

# Directory used to store public key data

#pki_dir: /etc/salt/pki/master

# Directory to store job and cache data

#cachedir: /var/cache/salt/master

# Verify and set permissions on configuration directories at startup

#verify_env: True

# Set the number of hours to keep old job information in the job cache

#keep_jobs: 24

# Set the default timeout for the salt command and api, the default is 5

# seconds

#timeout: 5

# The loop_interval option controls the seconds for the master's maintinance

# process check cycle. This process updates file server backends, cleans the

# job cache and executes the scheduler.

#loop_interval: 60

# Set the default outputter used by the salt command. The default is "nested"

#output: nested

# By default output is colored, to disable colored output set the color value

# to False

#color: True

# Set the directory used to hold unix sockets

#sock_dir: /var/run/salt/master

# The master can take a while to start up when lspci and/or dmidecode is used

# to populate the grains for the master. Enable if you want to see GPU hardware

# data for your master.

#

# enable_gpu_grains: False

# The master maintains a job cache, while this is a great addition it can be

# a burden on the master for larger deployments (over 5000 minions).

# Disabling the job cache will make previously executed jobs unavailable to

# the jobs system and is not generally recommended.

#

#job_cache: True

# Cache minion grains and pillar data in the cachedir.

#minion_data_cache: True

# The master can include configuration from other files. To enable this,

# pass a list of paths to this option. The paths can be either relative or

# absolute; if relative, they are considered to be relative to the directory

# the main master configuration file lives in (this file). Paths can make use

# of shell-style globbing. If no files are matched by a path passed to this

# option then the master will log a warning message.

#

#

# Include a config file from some other path:

#include: /etc/salt/extra_config

#

# Include config from several files and directories:

#include:

#  - /etc/salt/extra_config

#####        Security settings       #####

##########################################

# Enable "open mode", this mode still maintains encryption, but turns off

# authentication, this is only intended for highly secure environments or for

# the situation where your keys end up in a bad state. If you run in open mode

# you do so at your own risk!

#open_mode: False

# Enable auto_accept, this setting will automatically accept all incoming

# public keys from the minions. Note that this is insecure.

#auto_accept: False

# If the autosign_file is specified only incoming keys specified in

# the autosign_file will be automatically accepted. This is insecure.

# Regular expressions as well as globing lines are supported.

#autosign_file: /etc/salt/autosign.conf

# Enable permissive access to the salt keys.  This allows you to run the

# master or minion as root, but have a non-root group be given access to

# your pki_dir.  To make the access explicit, root must belong to the group

# you've given access to.  This is potentially quite insecure.

# If an autosign_file is specified, enabling permissive_pki_access will allow group access

# to that specific file.

#permissive_pki_access: False

# Allow users on the master access to execute specific commands on minions.

# This setting should be treated with care since it opens up execution

# capabilities to non root users. By default this capability is completely

# disabled.

#

#client_acl:

#  larry:

#    - test.ping

#    - network.*

#

# Blacklist any of the following users or modules

#

# This example would blacklist all non sudo users, including root from

# running any commands. It would also blacklist any use of the "cmd"

# module.

# This is completely disabled by default.

#

#client_acl_blacklist:

#  users:

#    - root

#    - '^(?!sudo_).*$'   #  all non sudo users

#  modules:

#    - cmd

# The external auth system uses the Salt auth modules to authenticate and

# validate users to access areas of the Salt system.

#

#external_auth:

#  pam:

#    fred:

#      - test.*

#

# Time (in seconds) for a newly generated token to live. Default: 12 hours

#token_expire: 43200

# Allow minions to push files to the master. This is disabled by default, for

# security purposes.

#file_recv: False 

#####    Master Module Management    #####

##########################################

# Manage how master side modules are loaded

# Add any additional locations to look for master runners

#runner_dirs: []

# Enable Cython for master side modules

#cython_enable: False

#####      State System settings     #####

##########################################

# The state system uses a "top" file to tell the minions what environment to

# use and what modules to use. The state_top file is defined relative to the

# root of the base environment as defined in "File Server settings" below.

#state_top: top.sls

# The master_tops option replaces the external_nodes option by creating

# a plugable system for the generation of external top data. The external_nodes

# option is deprecated by the master_tops option.

# To gain the capabilities of the classic external_nodes system, use the

# following configuration:

# master_tops:

#   ext_nodes: <Shell command which returns yaml>

#

#master_tops: {}

# The external_nodes option allows Salt to gather data that would normally be

# placed in a top file. The external_nodes option is the executable that will

# return the ENC data. Remember that Salt will look for external nodes AND top

# files and combine the results if both are enabled!

#external_nodes: None

# The renderer to use on the minions to render the state data

#renderer: yaml_jinja

# The failhard option tells the minions to stop immediately after the first

# failure detected in the state execution, defaults to False

#failhard: False

# The state_verbose and state_output settings can be used to change the way

# state system data is printed to the display. By default all data is printed.

# The state_verbose setting can be set to True or False, when set to False

# all data that has a result of True and no changes will be suppressed.

#state_verbose: True

# The state_output setting changes if the output is the full multi line

# output for each changed state if set to 'full', but if set to 'terse'

# the output will be shortened to a single line.  If set to 'mixed', the output

# will be terse unless a state failed, in which case that output will be full.

#state_output: full

#####      File Server settings      #####

##########################################

# Salt runs a lightweight file server written in zeromq to deliver files to

# minions. This file server is built into the master daemon and does not

# require a dedicated port.

# The file server works on environments passed to the master, each environment

# can have multiple root directories, the subdirectories in the multiple file

# roots cannot match, otherwise the downloaded files will not be able to be

# reliably ensured. A base environment is required to house the top file.

# Example:

# file_roots:

#   base:

#     - /srv/salt/

#   dev:

#     - /srv/salt/dev/services

#     - /srv/salt/dev/states

#   prod:

#     - /srv/salt/prod/services

#     - /srv/salt/prod/states

#file_roots:

#  base:

#    - /srv/salt

# The hash_type is the hash to use when discovering the hash of a file on

# the master server. The default is md5, but sha1, sha224, sha256, sha384

# and sha512 are also supported.

#hash_type: md5

# The buffer size in the file server can be adjusted here:

#file_buffer_size: 1048576

# A regular expression (or a list of expressions) that will be matched

# against the file path before syncing the modules and states to the minions.

# This includes files affected by the file.recurse state.

# For example, if you manage your custom modules and states in subversion

# and don't want all the '.svn' folders and content synced to your minions,

# you could set this to '/\.svn($|/)'. By default nothing is ignored.

#

#file_ignore_regex:

#  - '/\.svn($|/)'

#  - '/\.git($|/)'

# A file glob (or list of file globs) that will be matched against the file

# path before syncing the modules and states to the minions. This is similar

# to file_ignore_regex above, but works on globs instead of regex. By default

# nothing is ignored.

#

# file_ignore_glob:

#  - '*.pyc'

#  - '*/somefolder/*.bak'

#  - '*.swp'

# File Server Backend

# Salt supports a modular fileserver backend system, this system allows

# the salt master to link directly to third party systems to gather and

# manage the files available to minions. Multiple backends can be

# configured and will be searched for the requested file in the order in which

# they are defined here. The default setting only enables the standard backend

# "roots" which uses the "file_roots" option.

#

#fileserver_backend:

#  - roots

#

# To use multiple backends list them in the order they are searched:

#

#fileserver_backend:

#  - git

#  - roots

#

# By default, the Salt fileserver recurses fully into all defined environments

# to attempt to find files. To limit this behavior so that the fileserver only

# traverses directories with SLS files and special Salt directories like _modules,

# enable the option below. This might be useful for installations where a file root

# has a very large number of files and performance is impacted. Default is False.

#

# fileserver_limit_traversal: False

#

# Git fileserver backend configuration

# When using the git fileserver backend at least one git remote needs to be

# defined. The user running the salt master will need read access to the repo.

#

#gitfs_remotes:

#  - git://github.com/saltstack/salt-states.git

#  - file:///var/git/saltmaster

#

# The repos will be searched in order to find the file requested by a client

# and the first repo to have the file will return it.

# When using the git backend branches and tags are translated into salt

# environments.

# Note:  file:// repos will be treated as a remote, so refs you want used must

# exist in that repo as *local* refs.

#     

# The gitfs_root option gives the ability to serve files from a subdirectory

# within the repository. The path is defined relative to the root of the

# repository and defaults to the repository root.

#gitfs_root: somefolder/otherfolder

#####         Pillar settings        #####

##########################################

# Salt Pillars allow for the building of global data that can be made selectively

# available to different minions based on minion grain filtering. The Salt

# Pillar is laid out in the same fashion as the file server, with environments,

# a top file and sls files. However, pillar data does not need to be in the

# highstate format, and is generally just key/value pairs.

#pillar_roots:

#  base:

#    - /srv/pillar

#ext_pillar:

#  - hiera: /etc/hiera.yaml

#  - cmd_yaml: cat /etc/salt/yaml

# The pillar_opts option adds the master configuration file data to a dict in

# the pillar called "master". This is used to set simple configurations in the

# master config file that can then be used on minions.

#pillar_opts: True

#####          Syndic settings       #####

##########################################

# The Salt syndic is used to pass commands through a master from a higher

# master. Using the syndic is simple, if this is a master that will have

# syndic servers(s) below it set the "order_masters" setting to True, if this

# is a master that will be running a syndic daemon for passthrough the

# "syndic_master" setting needs to be set to the location of the master server

# to receive commands from.

# Set the order_masters setting to True if this master will command lower

# masters' syndic interfaces.

#order_masters: False

# If this master will be running a salt syndic daemon, syndic_master tells

# this master where to receive commands from.

#syndic_master: masterofmaster

# This is the 'ret_port' of the MasterOfMaster

#syndic_master_port: 4506

# PID file of the syndic daemon

#syndic_pidfile: /var/run/salt-syndic.pid

# LOG file of the syndic daemon

#syndic_log_file: syndic.log

#####      Peer Publish settings     #####

##########################################

# Salt minions can send commands to other minions, but only if the minion is

# allowed to. By default "Peer Publication" is disabled, and when enabled it

# is enabled for specific minions and specific commands. This allows secure

# compartmentalization of commands based on individual minions.

# The configuration uses regular expressions to match minions and then a list

# of regular expressions to match functions. The following will allow the

# minion authenticated as foo.example.com to execute functions from the test

# and pkg modules.

#

#peer:

#  foo.example.com:

#    - test.*

#    - pkg.*

#

# This will allow all minions to execute all commands:

#

#peer:

#  .*:

#    - .*

#

# This is not recommended, since it would allow anyone who gets root on any

# single minion to instantly have root on all of the minions!

# Minions can also be allowed to execute runners from the salt master.

# Since executing a runner from the minion could be considered a security risk,

# it needs to be enabled. This setting functions just like the peer setting

# except that it opens up runners instead of module functions.

#

# All peer runner support is turned off by default and must be enabled before

# using. This will enable all peer runners for all minions:

#

#peer_run:

#  .*:

#    - .*

#

# To enable just the manage.up runner for the minion foo.example.com:

#

#peer_run:

#  foo.example.com:

#    - manage.up

#####         Logging settings       #####

##########################################

# The location of the master log file

# The master log can be sent to a regular file, local path name, or network

# location. Remote logging works best when configured to use rsyslogd(8) (e.g.:

# ``file:///dev/log``), with rsyslogd(8) configured for network logging. The URI

# format is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>

#log_file: /var/log/salt/master

#log_file: file:///dev/log

#log_file: udp://loghost:10514

#log_file: /var/log/salt/master

#key_logfile: /var/log/salt/key

# The level of messages to send to the console.

# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.

#log_level: warning

# The level of messages to send to the log file.

# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.

#log_level_logfile: warning

# The date and time format used in log messages. Allowed date/time formating

# can be seen here: http://docs.python.org/library/time.html#time.strftime

#log_datefmt: '%H:%M:%S'

#log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

# The format of the console logging messages. Allowed formatting options can

# be seen here: http://docs.python.org/library/logging.html#logrecord-attributes

#log_fmt_console: '[%(levelname)-8s] %(message)s'

#log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s'

# This can be used to control logging levels more specificically.  This

# example sets the main salt library at the 'warning' level, but sets

# 'salt.modules' to log at the 'debug' level:

#   log_granular_levels:

#     'salt': 'warning',

#     'salt.modules': 'debug'

#

#log_granular_levels: {}

#####         Node Groups           #####

##########################################

# Node groups allow for logical groupings of minion nodes.

# A group consists of a group name and a compound target.

#

#nodegroups:

#  group1: 'L...@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com'

#  group2: 'G@os:Debian and foo.domain.com'

#####     Range Cluster settings     #####

##########################################

# The range server (and optional port) that serves your cluster information

# https://github.com/grierj/range/wiki/Introduction-to-Range-with-YAML-files

#

#range_server: range:80

#####     Windows Software Repo settings #####

##############################################

# Location of the repo on the master

#win_repo: '/srv/salt/win/repo'

# Location of the master's repo cache file

#win_repo_mastercachefile: '/srv/salt/win/repo/winrepo.p'

# List of git repositories to include with the local repo

#win_gitrepos:

#  - 'https://github.com/saltstack/salt-winrepo.git'

The port is also open 

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6041/sshd

tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      713/cupsd

tcp        0      0 0.0.0.0:4505            0.0.0.0:*               LISTEN      7306/python

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      1296/master

tcp        0      0 0.0.0.0:4506            0.0.0.0:*               LISTEN      7295/python

tcp6       0      0 :::22                   :::*                    LISTEN      6041/sshd

tcp6       0      0 ::1:631                 :::*                    LISTEN      713/cupsd

tcp6       0      0 :::25                   :::*                    LISTEN      1296/master

Please suggest me what is wrong in the settings?

The below is the error

root@ubuntu:/etc/salt# salt-master

[ERROR   ] Error parsing configuration file: /etc/salt/master - expected '<docum  ent start>', but found '<scalar>'

  in "<string>", line 23, column 1:

    publish_port:4505

    ^

[WARNING ] Unable to bind socket, error: [Errno 98] Address already in use

The ports are not available to bind

[Mike Place]

You are missing a space after the colon in your config file on line 23. Should be like:

publish_port: 4505

^^ Note space between colon and 4505.

-mp

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Soundappan Shanmugam]

Hi Mike

its the same error

root@ubuntu:/etc/salt# salt-master

[ERROR   ] Error parsing configuration file: /etc/salt/master - expected '<document start>', but found '<block mapping start>'

  in "<string>", line 23, column 1:

    publish_port: 4505

    ^

[WARNING ] Unable to bind socket, error: [Errno 98] Address already in use

The ports are not available to bind

[Mike Place]

Then you likely have a syntax error of a similar variety elsewhere in the configuration file, most likely in the first uncommented line preceding ‘publish_port’.

-mp

-- 
Mike Place
Sent with Airmail

[Akilesh K]

I do not think you are supposed to use saltstack like that. saltstack is for remote execution. you can not use both master and minion on same machine. If you wish to learn/test saltstack i suggest you run the minion on a virtual machine or lxc.

[Corey Quinn]

On Dec 22, 2013, at 10:24 PM, Akilesh K <akile...@gmail.com> wrote:

I do not think you are supposed to use saltstack like that. saltstack is for remote execution. you can not use both master and minion on same machine.

This is incorrect. Most of us have our masters as a minion as well.

— 

Corey Quinn

[SoundShanmug]

So if you need to maintain the master server you should do it manually??  I don't think it should be that way.. Anyway lemme do what in early email and then I'll update

On Dec 23, 2013 11:55 AM, "Akilesh K" <akile...@gmail.com> wrote:

I do not think you are supposed to use saltstack like that. saltstack is for remote execution. you can not use both master and minion on same machine. If you wish to learn/test saltstack i suggest you run the minion on a virtual machine or lxc.

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/tmJXm-jVCw4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Akilesh K]

Ya i was never aware that minion and master can be same machine.

[Corey Quinn]

Salt is many things, key among them is flexible. As a direct result, there aren't a whole lot of things that you're "supposed" to do; this is making my best practices presentation for SaltConf all the more relevant!

--Corey

You received this message because you are subscribed to the Google Groups "Salt-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

[C. R. Oldham]

Actually, you most definitely can run master and minion on the same machine. It's the easiest way to manage the machine running the master. 

-- 

C. R. Oldham, Engineer, SaltStack

c...@saltstack.com

On Dec 22, 2013, at 11:24 PM, Akilesh K <akile...@gmail.com> wrote:

I do not think you are supposed to use saltstack like that. saltstack is for remote execution. you can not use both master and minion on same machine. If you wish to learn/test saltstack i suggest you run the minion on a virtual machine or lxc.

--

[Dan Linder]

On Sun, Dec 22, 2013 at 11:12 AM, Soundappan Shanmugam <senthi...@gmail.com> wrote:

# The address of the interface to bind to

#interface: 0.0.0.0

interface 192.168.2.11

Shouldn't there be a colon after "interface"?

Dan

--
***************** ************* *********** ******* ***** *** **
"Quis custodiet ipsos custodes?"
    (Who can watch the watchmen?)
    -- from the Satires of Juvenal
"I do not fear computers, I fear the lack of them."
    -- Isaac Asimov (Author)
** *** ***** ******* *********** ************* *****************

[Soundappan Shanmugam]

Hey

Error:

root@ubuntu:/etc/salt# salt-master

[WARNING ] Unable to bind socket, error: [Errno 98] Address already in use

The ports are not available to bind

still i have the same issue with the port but it seems to be open. as suggested i have even modified the interface settings 

# The address of the interface to bind to

#interface: 0.0.0.0

interface: 192.168.2.11

# Whether the master should listen for IPv6 connections. If this is set to True,

# the interface option must be adjusted too (for example: "interface: '::'")

#ipv6: False

# The tcp port used by the publisher

publish_port: 4505

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:4505            0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:4506            0.0.0.0:*               LISTEN

tcp6       0      0 :::22                   :::*                    LISTEN

tcp6       0      0 ::1:631                 :::*                    LISTEN

tcp6       0      0 :::25                   :::*                    LISTEN

udp        0      0 0.0.0.0:63370           0.0.0.0:*

[Mike Place]

Are you totally positive that 192.168.2.11 is bound to the machine in question? Salt will throw that error if you’re trying to bind to an unrecognized address.

-mp

--

[David Anderson]

As the error says, the port is already in use. This means salt-master is already running. 

You can have netstat list the PID already bound with 'netstat -nlp | grep 450' also you can probably just look for salt-master with ps:  'ps -fC salt-master'

--

Dave

[Tim O'Guin]

Yep, it looks like you're trying to run the salt-master via the CLI. Make sure the service isn't already running, or you'll get that error.

[SoundShanmug]

Thanks Dave.. My bad .. Never looked into it.. But if thr exception of saying it is already running will make good sense than looking into services and then concluding it.

You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/tmJXm-jVCw4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Daniel Dehennin]

Corey Quinn <co...@sequestered.net> writes:


[...]

> this is making my best practices presentation for SaltConf all the
> more relevant!

Hello,

Do you have any link of your presentation?

Regards.
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF

[Tim O'Guin]

Pretty sure he means "Implementing SaltStack Best Practices" on the Session Topics Page:

http://www.cvent.com/events/saltconf-2014/custom-21-3aef0eba23dd49a1bd9ffcaaf83d657e.aspx