About 10% of the time, when I attempt to save my file in Emacs I get the following error:
Opening output file: resource temporarily unavailable,
I'm currently using Emacs GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) on
Ubuntu 12.04. I've also verified that this issue occurs logged in as a different user and using Emacs 23.3.1.
This issue gets to be a real pain when I make a fix, attempt to save, and then wonder why my fix didn't happen.... only to find out later that the Emacs save was never successful.
If I notice it happen, I'll keep hitting Ctrl-x Ctrl-s until a save actually goes through (takes a few times).
Does anyone have any idea why this happens and how to prevent it?
Update:
(More info per request)
I'm currently on a Ruby on Rails project and have been getting the error while editing a variety of file types *.rb, *js.coffee, *js.erb, *html.erb, etc.
The files I receive the error on are always files local to my machine. I haven't tested remote files.
If I look at the *messages buffer, for every time the error message occurred, the error is prefixed with: save-buffer-2
Update 2:
Issue is encountered in multiple Emacs versions by multiple users.
Update 3:
This doesn't appear to be an Emacs specific issue as I now get the occasional "Unable to save" popup window while attempting to save files in Sublime-text editor.
This can be a bug from emacs (M-x report-emacs-bug), some issue with your filesystem (I assume this is not the case because most likely you checked if problem happens with other editors), or some process in your local setup messing with your files.
For testing if the later is the case, you could try to eval this and then reproduce the problem:
(defadvice save-buffer (around find-shenanigan activate)
(condition-case ()
ad-do-it
(error
(shell-command (format "lsof -V %s" (buffer-file-name)) "*debug-issue*"))))
What this does is every time the save operation fails, it executes a command that takes a picture of the processes that have your file opened. If you see any process, you know who investigate. man lsof will help with the details.
Note: Does the problem happen also with emacs -Q?
EDIT: if you can use sudo without password (NOPASSWD in /etc/sudoers), replace "lsof" with "sudo lsof"
EDIT: I redirected the output of the lsof to a buffer named *debug-issue*; check that buffer if error.
Related
Working with Pure Data, trying to record audio output from a patch I've made, and am 1) unable to create a file within pure data to write to and 2) attempting to use the writesf~ object causes the program to freeze after about two to three seconds. I suspect the two things are related- perhaps the program is attempting to write data somewhere, somehow, but it's going in the wrong place or some such and causing the program to freeze?
I've uninstalled the latest Pure Data release (0.51-1) and installed an earlier stable release (0.5-2) and even tried an alternative called "purr data (latest release)" all with the exact same result on my windows 10 acer laptop: no file created, and program freezes after a few seconds.
I'm testing with this patch:
I first click on the message that reads "open rec.wav" then the start then the stop, and if I take longer than three or so seconds to click on "stop" the program freezes, otherwise nothing at all happens.
I have performed system wide search for the audio file, including the folder that the patch is in, all to no avail.
Any trouble shooting hints will be carefully attempted.
Are you sure you have write-permissions on the target directory?
If your example you use rec.wav which has no explicit target directory (and is just using the "current", so it's hard to tell from outside what this directory would be).
#max-n's answer suggests to use /tmp/foo.wav which is an illegal directory on Windows. Due to a known bug, using an illegal (or otherwise non-writable) path will lock up Pd.
If your "current" directory happens to be your system root (aka C:\), you might well lack the permissions to write there.
You could check by starting the Pd from the cmdline and see whether the terminal spits out any weird errors:
⊞ Win+R
type cmd and hit Enter
in the opening terminal type the full path to your Pd-executable, e.g.:
C:\Program Files\Pd\bin\pd + Enter
(ideally leave out the extension (that is: use .../pd rather than .../pd.exe)
If the problem is indeed a permission problem, you can simply work around it by specifying the full path of the output file (and make sure that it is in a writable directory).
The easiest way to do this is by using a file-selector to choose the output file:
[bang(
|
[savepanel]
|
[open $1(
|
[writesf~]
There might be a reason why the helpfile uses a [delay 1000] to schedule a stop message in a predefined time.
I am using VSCode to remotely connect to a file server via SSH. I have another person who uses it as well and they are logging in under their own account, which is a part of a group that has access to an entire directory structure.
Every once in a blue moon, the permissions get screwed and revert back to root:root (ownership) and I have to change it back to root:groupname so that the other person can have access. However, even when I do this, sometimes the other person isn't able to make changes using VS Code. If I su to that user, I am able to save changes.
One thing that I have noticed is that if I run vim <filename> and try to edit it as that user, it'll say, "-- INSERT -- W10: Warning: Changing a readonly file". However, the minute I try to save the file, it actually saves.
It's almost like the permissions are lagging or something and hasn't been updated.
Any idea how I can go about fixing this?
There is code inside vim that does a pretty good job of deciding when a file has been opened by someone else with another editor for writing, and it stops you from a race condition for file write.
Vim is telling you to wait very patiently for the other person to be done writing that file.
Learn more with :help W10
Reproduce this bug in vim 9.0:
Make a /tmp/file.txt owned by youruser with rw-r--r--
Open two unique terminals to /tmp/
Open file.txt for writing in one using vim.
Vim will mark the file as read only awaiting write, since someone else has it open for writing.
Open file.txt for writing in one using vim in the other terminal.
You get:
"-- INSERT -- W10: Warning: Changing a readonly file"
Solutions:
Find the other instance of vim that has locked your file for writing and close that instance of vim. Done
Or if you don't have access to the other terminal, or the instance of the other editor died without releasing its read only lock, or if it's from another person who's opened the file for writing on a session from a different computer, then the only thing I know that can clear all of those conditions is rebooting the computer.
If you want more control over this, you'll have to uncover how vim is deciding when a file is readonly for writing and find out where this information is being stored and clear it manually.
There's quite a bit of information out there on this topic, but for some reason I just can't get it to work. This is on a raspberry pi running the 'DietPi' flavor over the raspian distro, and is perhaps what separates my question from the others.
So I have a GUI application that I wish to launch at boot, after the LXDE session has begun. So I have utilized the following file here:
/etc/xdg/lxsession/LXDE/autostart
and added the line:
#/myapplication
This works, however, it launches multiple instances of this program, and the first one always crashes. This creates problems because there's some competition for resources (IO, files, etc). So what I did was create script file, /myapplication-autostart.sh instead like so:
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
/myapplication
fi
and then changed /etc/xdg/lxsession/LXDE/autostart to #/myapplication-autostart.sh. Now what I find is the program launches once, but the instance crashes. It crashes when it attempts to create a window (opencv imshow). This is strange because the program will also run headless if an X-session is not available, but for some reason it crashes and I do not know where to check why.
Also, to test it wasn't an issue with the script file, I commented everything out except the /myapplication and I have found the script file runs in a continuous loop and every time I close the application it opens back up. I'm not sure why this is either.
I've tried adding a sleep delay in the script and it does not help. For whatever reason, it seems the LXDE autostart script is ran at least 3 times when booting the pi and the circumstances around the first cause the program to crash. Does anybody understand this sequence and behavior of calling this autostart script?
It is also possible to use the XDG standard Autostart - which is independent of the used desktop environment - by placing desktop files at
$XDG_CONFIG_HOME/autostart (by default ~/.config/autostart)
or for system-wide autostarts at $XDG_CONFIG_DIRS/autostart (by default /etc/xdg/autostart).
Such a .desktop-file could look like:
[Desktop Entry]
Type=Application
Version=1.0
Name=JDownloader
Exec=/usr/local/bin/my-application.sh
Categories=Utilities
The specification of desktop-files can be found at freedesktop.org.
Here was the final solution...
/etc/xdg/lxsession/LXDE/autostart added the line:
/myapplication-autostart.sh
and /myapplication-autostart.sh was changed to:
#!/bin/bash
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
if [[ "$DISPLAY" = ":0" ]]
then
/myapplication
fi
fi
I had to write the display variable to file in combination with the errors to file to discover the issue. At login 2 X sessions were created, display ":1" and display ":0", in that sequence. Display ":1" crashed because, although not headless, it was not initialized to a particular resolution and there was some resizing code in my program. Display ":0" was the actual display on the HDMI out and the one I wanted. Really, the conditional check to see if the application isn't necessary but I left it in there to be safe. I could have also left the # on the LXDE autostart file but it got annoying in the cases I wanted to close the application because it'd keep re-opening. Possibly I'll put it back later.
Thanks for the help!
First, some comments about opening several instances of the program: when you use "#" at the beginning of the line on the startup file (ex.: #/myapplication), this requests your system to try to launch the program, but if the program fails to open correctly, then the system will try to open it multiple times until it opens correctly -- if you remove "#" from the line beginning, then the system will only try to open the program once.
Now, to find out why the program is failing, I advise you to add
2> /file/log
to the end of every command on your script. Doing so would append any error message to a log (/file/log), and analyzing those error messages would be key to find out why the program is misbehaving.
One important note: if your program needs root privileges to run, then it will fail when called via /etc/xdg/lxsession/LXDE/autostart, as this method calls programs without elevated permissions.
This is an old thread but I was having problems getting autostart to start all the tasks listed. After many days I concluded there were one or more "invisible" characters that autostart didn't like. So I deleted the lines for the tasks that didn't start and retyped them. That solved the problem!
I think I corrupted the lines because I was editing some of the lines on my Windows computer. It was likely inserting CR with LF or some other stuff. I WILL NEVER EDIT TEXT FOR LINUX USING WINDOWS!
Maybe someone else will hit this problem and this may help them. I don't know where else to put this information.
This is related to debugging the issue mentioned in: Plugin (vim-latex) crashing gVim on startup
After installing latex-suite, every time I open a .tex file, whether it's from gVim or terminal vim, whether it contains a \begin statement or not, Vim immediately crashes.
After repeatedly making it crash I was able to read a Python Traceback string in the status line, which mentioned line 530 in C:\Python27\lib\site.py (which only contains known_paths = addusersitepackages(known_paths)), but the rest of the traceback is not viewable since the statusline display truncates it and this only appears for a moment anyway before automatically crashing.
Is there a way I could capture this Traceback output in a more permanent and complete way, along with how things go from this plugin to Python, etc.?
(I tried the -V15filename.log option but it's (as usual) useless, containing some partial log upto an ancient point in the vim startup process.)
Edit: Apologies for not mentioning the OS previously (other than indirectly through the C:\ path), this problem is on Windows. And from the other linked question it seems like almost everyone who tries latex-suite on Windows runs into this problem.
Update: Just a FTR - setting verbosefile doesn't help (presumably because the writes are buffered per the doc), and :redir doesn't capture this either, ends with whatever operation happened before this error and crash.
OK, I put here as an answer.
This answer could be kind of work around for solving your latex plugin problem in windows vim. However if your question sticks to "getting error message before crashing" , it may not give you help. I don't have much experience with windows OS.
Latex Suite plugin uses python to generate some formatted text. It could bring better performance. However the plugin provides no-python ways for that as well, to let user without installing python runtime or with very old python version use the plugin too.
Since you mentioned that your problem was in python codes. You can try disabling python in that plugin, and test if the performance was acceptable.
The plugin provided a variable for that, you could add this line in your vimrc
let g:Tex_UsePython=0
Nice to see it helped.
Did you try to run with redirected stderr?
vim file.tex &> errors.log
or
vim file.tex 2> errors.log
1) If you are able to compile Vim from the source (using MinGW as you are on Windows), you could run it with gdb. Then you could set some breakpoints/check the stack trace until you detect a line near the crash. The instructions to run Vim with the gdb and read the stack traces are found in :help debug-gcc.
At the end of that help file (:help get-ms-debuggers) you can find instructions on how to obtain some debug tools for Windows.
These tools can be used on the following alternatives, explained in detail on :help debug-win32:
2) In case you didn't compile Vim, obtain the debug symbols (PDB), which should be available from the same place that you obtained the executable. Attach Visual Studio to the Vim process, reproduce the crash, then read the stack trace through Visual Studio's dialog reporting the crash.
3) Same as 2) but using WinDbg instead of Visual Studio.
4) Inspect the Minidump file, in case your crash generate one. In addition to the referenced help section, you may find useful information on the following links:
Where to find mini dmp files in windows 7
How to read the small memory dump file
In case you are on a computer running linux, did you try saving the strace output in a file?
strace gvim -V9log.txt file.tex > stdout.txt 2> stderr.txt
And then having a closer look at the output files, especially the last 10-100 lines? I am not sure if it will capture the system calls of the plugins though, but it could be a starting point.
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.