# fcntl.flock error after ansible installation under Solaris10 x86 **URL:** \ **Category:** Ansible Project\ **Tags:** ansible-project\ **Created:** [May 15, 2013, 2:50pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809 "2013-05-15T14:50:31Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [May 15, 2013, 2:50pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/1 "2013-05-15T14:50:31Z")
Can you check if you have TMPDIR, TEMP or TMP env variables set? Code assumes it successfully creates file in tmp dir (but this can fail), this uses python's tempfile.gettempdir. ---
**Author:** ![Karl\_Behler](https://avatars.discourse-cdn.com/v4/letter/k/977dab/32.png) [@Karl\_Behler](https://forum.ansible.com/u/Karl_Behler)\ **Post date:** [May 15, 2013, 4:44pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/2 "2013-05-15T16:44:50Z")
Hi Brian, setting any of these variables did not help. I’m a newbie to python so I’m not familiar digging into the python descriptions. However, as far as [docs.python.org](http://docs.python.org) says about tempfile.gettempdir those variables are 1.-3. in a search hierarchy for a temp space which on “other systems” (which Solaris is probably) is follwed by searching for /tmp, /var/tmp, and /usr/tmp. I checked if a normal user can create a file in /tmp: YES. So I expect there is no problem with tempfile.gettempdir. Having found [docs.python.org](http://docs.python.org) I also looked into fcntl.flock which says: “See the Unix manual _flock(2)_ for details. (On some systems, this function is emulated using `fcntl()`.)” Solaris man page for flock(3ucb) (There is no flock(2).) can be found at [http://docs.oracle.com/cd/E19683-01/816-0213/6m6ne37v5/index.html](http://docs.oracle.com/cd/E19683-01/816-0213/6m6ne37v5/index.html) fcntl(2) is described here: [http://docs.oracle.com/cd/E19683-01/816-0212/6m6nd4n9c/index.html](http://docs.oracle.com/cd/E19683-01/816-0212/6m6nd4n9c/index.html) Both man pages describe EBADF as a possible error code. Further I searched google with “solaris flock python” and found a couple of locking issue descriptions. But as far as I saw none describing the error “Bad file number”. This all does not give me a clue whether ansible is using fcntl.flock in a Solaris incompatible way of if already the python implementation for fcntl.flock is incompatible with Solaris. Any idea? Regards, Karl ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [May 15, 2013, 5:11pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/3 "2013-05-15T17:11:45Z")
So the initial error made me think the file wasn't accessible or being created, but looking closer at the code, you would have had a traceback earlier with 'IOError' or similar. Just to make sure this isn't a python flock incompatibility error, can you run (adjust shebang and file string as needed): this should run w/o output on success. --- locktest.py --- #!/usr/bin/python import fcntl lfile = "/var/tmp/mylock" lfile\_c = open(lfile,"w") lfile\_c.close() LOCKFILE = open(lfile,"r") fcntl.flock(LOCKFILE, fcntl.LOCK\_EX) ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [May 15, 2013, 6:03pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/4 "2013-05-15T18:03:11Z")
It sounds like it’s just unable to get a lock on your tempdir and we need to make it tolerate not being able to get that lock, which is simple enough. Please make sure there isa github ticket filed and I’ll take care of it. The locking here is only to make sure that output does not get interlaced, which can happen _occassionally_. ---
**Author:** ![Karl\_Behler](https://avatars.discourse-cdn.com/v4/letter/k/977dab/32.png) [@Karl\_Behler](https://forum.ansible.com/u/Karl_Behler)\ **Post date:** [May 15, 2013, 7:59pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/5 "2013-05-15T19:59:10Z")
Hi Brian, running locktest.py yields following: ~ 64) python locktest.py Traceback (most recent call last): File “locktest.py”, line 10, in fcntl.flock(LOCKFILE, fcntl. **LOCK\_EX** ) IOError: [Errno 9] Bad file number ### just to check if the file was properly created by locktest: YES ~ 65) ls -al /var/tmp/mylock -rw-r–r-- 1 kcb e2dv 0 15. Mai 21:20 /var/tmp/mylock After reading again the error descriptions in the Solaris man pages I found it likely, that the descriptions of fcntl apply to our problem. (If the flock.fcntl function for Solaris actually is emulated using fcntl.) For fcntl the EBADF error may be returned in a number of combinations of arguments and does not simply mean it’s not a valid file descriptor. Especially the man file says: EADF is set when … “the type of lock, `l_type`, is a **shared** lock (`F_RDLCK`), and is not a valid file descriptor open for **reading** ; or the type of lock `l_type` is an **exclusive** lock (`F_WRLCK`) and is not a valid file descriptor open for **writing**.” In your example you are opening the file for write, closing the file, opening the file for read and requesting an exclusive lock on the file. In a second test I changed the type of lock to shared (LOCK\_SH). Now locktest.py runs through without any message. ~ 71) rm /var/tmp/mylock ~ 72) ll /var/tmp/mylock /usr/gnu/bin/ls: cannot access /var/tmp/mylock: No such file or directory ~ 73) python locktest.py ~ 74) ll /var/tmp/mylock -rw-r–r-- 1 kcb e2dv 0 15. Mai 21:51 /var/tmp/mylock So changing the requested locktype to **shared** for **reading** a file could be a solution. Double checking the other way round (requesting a **shared** lock for a file open for **writing** ) yields the error again: ~ 76) python locktest.py Traceback (most recent call last): File “locktest.py”, line 10, in fcntl.flock(LOCKFILE, fcntl. **LOCK\_SH** ) IOError: [Errno 9] Bad file number And checking the fourth combination (requesting an **exclusive** lock for a file open for **writing** ) yields no error again. Regards, Karl ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [May 15, 2013, 8:05pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/6 "2013-05-15T20:05:05Z")
A shared lock seems to defeat the purpose in this case. I think we just want exception handling so it doesn’t break on Solaris. ---
**Author:** ![Karl\_Behler](https://avatars.discourse-cdn.com/v4/letter/k/977dab/32.png) [@Karl\_Behler](https://forum.ansible.com/u/Karl_Behler)\ **Post date:** [May 15, 2013, 8:19pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/7 "2013-05-15T20:19:24Z")
Hi Michael, I just filed an issue in ansible github: [https://github.com/ansible/ansible/issues/2925](https://github.com/ansible/ansible/issues/2925) It seems well possible to get a lock under Solaris, but the type of lock seems to have to conform to the r/w mode the file has been opened with. It’s described above and in the issue. Hope this solves the problem. I’ll standby to pull any new code for trial. Regards, Karl ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [May 15, 2013, 8:25pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/8 "2013-05-15T20:25:06Z")
Will take a look at this shortly. FYI, this lock is only acquired on the management machine, so if you were managing from say, Scientific Linux or Fedora or Ubuntu, etc, you won’t run into this, even if managing Solaris guests. Should be an easy fix. ---
**Author:** ![Karl\_Behler](https://avatars.discourse-cdn.com/v4/letter/k/977dab/32.png) [@Karl\_Behler](https://forum.ansible.com/u/Karl_Behler)\ **Post date:** [May 15, 2013, 8:38pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/9 "2013-05-15T20:38:00Z")
At the moment we are a more or less pure Solaris shop. And this will not change soon. 🙂 ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [May 15, 2013, 8:47pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/10 "2013-05-15T20:47:41Z")
For this to work on all platforms, we could just open the lockfile in write mode. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [May 15, 2013, 8:49pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/11 "2013-05-15T20:49:42Z")
Yep, I believe that will do! ---
**Author:** ![Karl\_Behler](https://avatars.discourse-cdn.com/v4/letter/k/977dab/32.png) [@Karl\_Behler](https://forum.ansible.com/u/Karl_Behler)\ **Post date:** [May 16, 2013, 10:54am UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/12 "2013-05-16T10:54:16Z")
> For this to work on all platforms, we could just open the lockfile in write mode. Yes, opening the LOG\_LOCK file in write mode makes it work on Solaris. Thanks, Karl ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [May 16, 2013, 12:11pm UTC](https://forum.ansible.com/t/fcntl-flock-error-after-ansible-installation-under-solaris10-x86/12809/13 "2013-05-16T12:11:46Z")
Yep, this change is now merged in to the 1.2 branch. Should be good to go!