I successfully compiled a MUD source code, and it says in the instructions to start up the server using
nohup ./startup &
although when I do this it gives me this error:
$ nohup: ignoring input and appending output to `nohup.out'
nohup: failed to run command `./startup': Permission denied
I have looked all over the internet to find the answer. A few of them said to put my cygwin directory in the root folder (I am using windows 7) and its directory is C:\cygwin
so thats not a problem.. Can anyone help me with this please??
Try chmod +x startup, maybe your startup file is not executable.
From "man nohup":
If the standard output is a terminal, all output written by the named
utility to its standard output shall be appended to the end of the
file nohup.out in the current directory. If nohup.out cannot be
created or opened for appending, the output shall be appended to the
end of the file nohup.out in the directory specified by the HOME
environment variable. If neither file can be created or opened for
appending, utility shall not be invoked. If a file is created, the
file's permission bits shall be set to S_IRUSR | S_IWUSR.
My guess is that since "sh -c" doesn't start a login shell, it is inheriting the environment of the invoking shell, including the HOME environment variable, and is trying to open it there. So I would check the permissions of both your current directory and $HOME. You can try to touch test.txt in current directory or $HOME to see if you can perform that command.
As staticx writes, check the permissions of the directory (and the user) - and the executable.
Instead of using nohup:
check if nohup is needed at all, try ./startup </dev/null >mud.out 2>mud.err &, then close the terminal window and check if it is running
or just run ./startup in a screen session and detach it (<ctrl>+<a>,<d>)
Related
I installed flatpak using guix, but it segfaulted on startup. I wanted to debug it, but guix installs a wrapper script for flatpak, so I get this error when trying to run it under gdb:
"/home/user/.guix-profile/bin/flatpak": not in executable format: file format not recognized
and I tried to edit the wrapper script to call gdb, but this wrapper script is not even editable by root, because it is owned by root and has read-only permissions.
Simply copy the script to your current working directory:
cp /home/user/.guix-profile/bin/flatpak .
Mark it as writable:
chmod +w flatpak
Edit the script with your favourite text editor, to replace the string exec -a with exec gdb --args.
And finally, run it with any arguments you provided before, when it misbehaved:
./flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
In this particular case, this wasn't immediately super-useful, because a debug symbol output hasn't been built for this package. But at least I could get a backtrace out of gdb.
On the docker image debian:stretch-slim, couldn't delete a specific folder on a NFS drive, using rm -rf /folder-name as root (or rm-rf * after entering the folder-name).
Got the following error back:
rm: cannot remove 'test-ikmgfjhv/dev/.nfse47cf31c6b1dd52500000009': Device or resource busy
After a lot of searching, eventually got to the following link:
https://uisapp2.iu.edu/confluence-prd/pages/viewpage.action?pageId=123962105
Which Describes exactly why those files exist in NFS and how to handle them.
As I wasn't using the same machine the process runs on (another container), so in my case, I had to work around that and first make sure the process using the file is being killed on the first machine, then try to delete it on the second one, according to the project's needs.
It is possible that the .nfs file is attached to a process that is busy or running (like an open file, for example, a vim file).
For example, if the hidden file is .nfs000000000189806400000085, run this command to get the pid:
lsof .nfs000000000189806400000085
this will output the PID and other info related to that file
then kill the process:
kill - 9
Be aware that if the file was not saved you will lose the information.
While running any command if you get error like :
/home/mmandi/testcases/.nfs000000e75853 :device or resource busy.
Go to the directory where this file is being shown.
For e.g - In this case : /home/mmandi/testcases/
Do following :
# ls -la : This will display contents of the directory along with files starting with "."
Here it displays the .nfs000000e7585 file.
# lsof .nfs000000e7585
This will list down the PID
# Use Kill -9 PID.
Under some circumstances, the rm command in Git-Bash deletes files that can't be deleted in explorer, cmd prompt, PowerShell, or using C++ standard library calls.
Why?
This is perplexing to me because I know there is no magic here and I assume that they are all using the same Win32 API.
For example, I have database snapshots that remain open and cannot be deleted using the other methods described, but are successfully deleted by Git-Bash rm:
Explorer delete: "The action cannot be completed because the file is open."
cmd: del <path> : "Access is denied"
PS: Remove-Item -Force -Path <path> : "Cannot remove item. Access to the path is denied."
C++ remove() : returns -1
C++ unlink() : returns -1
C++ _unlink() : returns -1
git-bash rm <path> : success
The above can be performed repeatedly on different files.
There are other locked files that git-bash rm deletes successfully as well (I have used it in the past, not recently and I don't have other specific examples).
However it doesn't always work: In a test application I opened a text file using fopen() and none of the methods, including Git-Bash rm, could successfully delete it.
So, how does Git-Bash rm work?
I was able to figure out how this works.
Interestingly, I used Git-Bash's strace utility on it's rm command.
It turns out that Git Bash uses CygWin, and the delete routine is found in the CygWin syscalls.cc file which tries to delete a file in a few different ways.
Eventually it tries to move the file to the Recycle Bin, where it deletes the locked file by opening it with the Windows Driver call NtOpenFile() with a FILE_DELETE_ON_CLOSE flag, then closing it using NtClose().
Not sure if it would be proper to copy CygWin's code into the response here, but details on all of the above can be found in the link provided.
I've tried both launching /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal as a process and using std::system to launch it from sh script (open -a /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal) with different arguments (detsdir as argument, cd destdir etc.). Nothing works. It either opens in ~/, or it says "destdir is a directory` and logs off.
I've also tried launching it as a process with destdir set as working directory (using QProcess::startDetached). No luck either, it opens in ~/.
You can do it like this, with osascript:
osascript -e "tell application \"Terminal\" to do script \"cd ~/Desktop\""
This will create a new terminal window with working directory ~/Desktop.
QProcess has method setWorkingDirectory()
I have an executable, which has a few system commands (basically it does copying and running script files). When I test in standalone (launching the executable myself as with sudo) system() is working fine.
Now I integrate my executable with supervisord. Functionality of my executable is working fine, but the system() command fails with 255 / -1 (8 bit representation).
List of things I checked:
The current working directory of the process is correct
Supervisord and my process are running as root
chown of directory and file are root
Any other suggestions?
system("sudo cp ./Scripts/x.sh /tmp/");
sudo is the command to obtain superuser rights. It normally promts you for password (but under some circumstances, it skips it). Maybe it fails if it has no console to prompt you.
Anyway you should NOT do this. You sould just write system("cp ./Scripts/x.sh /tmp/") and start your program with root access (supervisord probably has a way to do that).