51–60 of 97 posts
The fix was to undo a seemingly safe performance tweak... From https://github.com/nedbat/coveragepy/commit/e4b8389b27ce4e76... "Put the filename calc back in _connect. Fixes #916 It was moved to __init__ to avoid recalculating, but the directory could have changed, so we need to wait to do the work. Instead, only do the relpath on systems that need it (Windows Py 2)."
This doesn't quite get all the way there, but the failure is being caused by the closure of a _io.FileIO due to GC, which happens to have the same fd as the sqlite database. The closure happens in the middle of a SQLite operation, which causes a subsequent flock() call to fail. strace log from the failure: open("/home/travis/apprise-api/.coverage", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 31 fstat(31, {st_mode=S_IFREG|0644,…
Earlier quoted context omitted.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
It is called process substitution and specific to Bash (not POSIX shell compliant). The output of the commands in parenthesis will become runtime (file) inputs for the diff command. More: https://www.gnu.org/software/bash/manual/html_node/Process-S...
I'm also pretty sure it originated in ksh, not bash.
Can we please have an informative title? Bug #915: Please help tells me nothing.
This doesn't quite get all the way there, but the failure is being caused by the closure of a _io.FileIO due to GC, which happens to have the same fd as the sqlite database. The closure happens in the middle of a SQLite operation, which causes a subsequent flock() call to fail. strace log from the failure: open("/home/travis/apprise-api/.coverage", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 31 fstat(31, {st_mode=S_IFREG|0644,…
We recently upgraded to celery 4 which had a side effect of file descriptors leaking between master and child processes, and database fds were being used for redis. Still no idea how it's happening, but the linked PEP seems to suggest there may be issues that I don't quite understand.
This doesn't quite get all the way there, but the failure is being caused by the closure of a _io.FileIO due to GC, which happens to have the same fd as the sqlite database. The closure happens in the middle of a SQLite operation, which causes a subsequent flock() call to fail. strace log from the failure: open("/home/travis/apprise-api/.coverage", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 31 fstat(31, {st_mode=S_IFREG|0644,…
This doesn't quite get all the way there, but the failure is being caused by the closure of a _io.FileIO due to GC, which happens to have the same fd as the sqlite database. The closure happens in the middle of a SQLite operation, which causes a subsequent flock() call to fail. strace log from the failure: open("/home/travis/apprise-api/.coverage", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 31 fstat(31, {st_mode=S_IFREG|0644,…
I suppose adding f.close() right after the flush might help.
Earlier quoted context omitted.
On linux at least, these two constructions are effectively identical from the view of the "piped" process. # cat /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20519634] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23611/fd/ # ls -l /proc/self/fd/ | cat - total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 J…
Yes, because “cat” can use either STDIN or a file as input: https://github.com/coreutils/coreutils/blob/master/src/cat.c... It’s an intentional design decision.
Can we please have an informative title? Bug #915: Please help tells me nothing.
Earlier quoted context omitted.
I suppose adding f.close() right after the flush might help.
The file is in a with block - it should be automatically closed at the end of the block.