Search code examples
pythonsalt-project

Unable to get lock on /var/lib/dpkg/lock when trying to execute $: salt \* pkg.install vim

I am using salt stack for development of an SCM. I have successfully connected the master to the minion and the following command works successfully. 

$: salt \* test.ping

Now, I am trying to execute the following command.

$: salt \* pkg.install vim

To install vim on the minion using the master, when I execute this command on the master, I am getting the following error

[INFO    ] User sudo_user1 Executing command pkg.install with jid 20140910191537152620
[DEBUG   ] Command details {'tgt_type': 'glob', 'jid': '20140910191537152620', 'tgt': '*', 'ret': '', 'user': 'sudo_user1', 'arg': ['vim'], 'fun': 'pkg.install'}
[INFO    ] Starting a new job with PID 5762
[INFO    ] Executing command "dpkg-query --showformat='${Status} ${Package} ${Version} ${Architecture}\n' -W" in directory '/home/cybage'
[INFO    ] Executing command ['apt-get', '-q', '-y', '-o', 'DPkg::Options::=--force-confold', '-o', 'DPkg::Options::=--force-confdef', 'install', 'vim'] in directory '/home/user1'
[ERROR   ] Command ['apt-get', '-q', '-y', '-o', 'DPkg::Options::=--force-confold', '-o', 'DPkg::Options::=--force-confdef', 'install', 'vim'] failed with return code: 100
[ERROR   ] output: E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
[INFO    ] Executing command "dpkg-query --showformat='${Status} ${Package} ${Version} ${Architecture}\n' -W" in directory '/home/cybage'
[INFO    ] Returning information for job: 20140910191537152620
[DEBUG   ] Decrypting the current master AES key
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem

Both master and minion are Ubuntu 14.04. Please let me know if anyone has faced a similar issue or am I missing something here. Thanks for the help.

Solution

  • Finally I was able to figure out what was wrong.

    I started salt-master using the following command

    shwetabhs@shwetabhs-master:/etc/salt# sudo salt-master -l debug

    Instead, it should be started from root

    root@shwetabhs-master:/etc/salt# salt-master -l debug

    Starting the master from root solved the problem.