I just started using fugitive in my workflow... very useful! But I've seem to have run into a weird annoyance that I'm hoping someone might have a solution to:
When I run :Gpush, sometimes control never returns to vi. Vi hangs on the output of git push until I Ctrl+C to kill "it". I've also tried installing vim-dispatch and, within tmux, the result is that the git push pane never closes. This is even more annoying because I've got to switch down to that pane to Ctrl+C it.
Oddly, if I ps, I do not see any git processes running, so I'm not sure what is hanging, exactly... but Ctrl+C does kill "it", whatever "it" is, and control returns to vi.
I've found a closed github issue that mentions similar behavior, but a solution was never posted... it appears the problem eventually just "went away" for the OP, so the issue was closed.
However, a second person replied to the issue some time later saying he was having a similar problem and it seemed to happen when git spawned some kind of "credential cache daemon". I'm not using a credential helper as he is, so that's not my exact issue... but that caused me to notice something else:
I have ssh configured to keep connections open for 5 minutes (ControlPersist 5m in my ~/.ssh/config). If I haven't pushed in a while, git push causes ssh to spawn a process to persist the connection. This triggers the issue. After 5 minutes, ssh exits, which will fix the problem and cause the tmux pane to close. If I do another push while the connection is still open, it works fine.
So, the problem seems to be when git spawns another process. This obviously doesn't cause any issues when I run git on the command-line, so why does it cause an issue here? And what can I do about it? I don't want to disable the ssh persistent connections because that's useful...
For anyone who stumbles upon this in the future, I've come up with a solution for my particular case where the ssh process is hanging vim: I disable the ControlPersist option, but only for git commands run inside vim via fugitive by setting the following option in my .vimrc:
let g:fugitive_git_executable = "env GIT_SSH_COMMAND='ssh -o ControlPersist=no' git"
It's ugly, and I'm sad that I have to disable the persistent connections, but it works.
Related
I use github action to deploy my website to my server. The last ssh cmd is npm run start. It will output ready - started server on http://localhost:4000(Since i use Nextjs) finally but it seems that github doesn't know what did it mean and print :
2021/01/09 14:24:14 Error: command timeout
err: Run Command Timeout!
Although the website is successfully deployed, it shows that the Github action failed to execute.
So how to tell github action that the job had done successfully？
You should find a way to start the application in a daemon process of its own, rather than as a process within the SSH session. Perhaps this tool (pm2) might solve your problem? This question and answer is somewhat related.
There are definitely other ways to start your app in a daemon process, or perhaps as a service, but this might be the most straightforward for you since it's a Node tool.
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
So my code had an invalid syntax, which I was trying out to see if it works and while compiling I got App threw an error during load.
Now in the command-prompt the error is listed in detail with the cursor still blinking but NOT WRITABLE. Closing, re-opening, re-navigating and restarting with electron . only seems to work.
Can't do the same for many errors I might face. So, is there a way to not let that happen? How are you guys dealing with it? Is it in anyway connected to stopping the npm server? If it helps, I'm using a Win 7 64bit OS.
Found a way, which is to terminate the batch job by hitting CTRL + C, which asks Terminate batch job (Y/N)? where choosing Y terminates and makes the command prompt writable.
I was searching for methods to terminate without confirmation and learnt it cannot be terminated without confirmation.
I'm an android developer. I acquired recently a Samsung Galaxy S3 (I9300) and I am having some problems with it.
The error management doesn't work. I mean, when an app crashes, it doesn't show "Force close", the phone just freezes.
I had an HTC before; I use it when I'm developing too, and with the same malfunctioning app, my HTC shows me force close, but the S3 freezes and I have to restart it.
As you can imagine, this is very annoying.
I found a temporary solution, but it affects wifi. Using this app
https://play.google.com/store/apps/details?id=com.issess.fastforceclose&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5pc3Nlc3MuZmFzdGZvcmNlY2xvc2UiXQ..
and enabling "old fast force close" seems to solve the problem, but it has wifi related problems.
Things I have tried
Clean ROM, wiping data and Dalvik cache (it works at the beginning, but suddenly the phone freezes and when I restart, the error management doesn't work any more)
Delete all apps
What am I missing? How can I resolve this?
see http://forum.xda-developers.com/showthread.php?t=1843837 , especially post #8
quoting:
I finally figured out what "Fast Force Close" app is doing to stop the freeze. It does something rather simple: it basically "hides" the /data/log folder, by moving it aside, and replacing it by a symlink. And this then also, causes Wifi to not connect after a reboot (dunno why)
mv /data/log /data/log_backup
ln -s /dev/null /data/log
To "disable" the fix, it just does the reverse.
Anyway, this got me thinking that the solution was somehow related to stuff happening in that folder. And one of the things happening in that folder, on a Force Close, is that it receives the output of the dumpstate command:
dumpstate -k -t -n -z -d -o /data/log/dumpstate_app_error
So, my solution for the "Freeze instead of Force Close dialog" issue is to put some files in the /data/log folder, with such permissions that dumpstate can not do its thing.
I found this to solve the issue, but I don't know if there are side effects.
If you want to implement this, you can do it in many ways (e.g. even through terminal emulator or probably some root file explorer). I'm attaching a flashable zip that will do this for you. (see XDA link)
Apart from some boilerplate code, the essential bit is this (in updater-script in the zip):
ui_print("Apply fix...");
delete("/data/log/dumpstate_app_error");
delete("/data/log/dumpstate_app_error.txt.gz");
delete("/data/log/dumpstate_app_error.txt.gz.tmp");
package_extract_file("placeholder", "/data/log/dumpstate_app_error");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz.tmp");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz.tmp");
The issue was resolved for me by updating the phone to the latest available android version.
I'm trying to restart a custom IRC bot. I tried various commands :
load.php
daemon load.php
daemon load.php &&
But that makes the script execute inside the console (I see all the output) and when I quit the bot quits as well.
The bot author only taught me the IRC commands so I'm a bit lost.
You can install a package called screen. Then, run screen -dm php load.php and resume with screen -dR
This will allow you to run the script in the background, and still be able to use your current SSH terminal. You can also logout and the process will still be running.
Chances are good the shell is sending the HUP signal to all its running children when you log out to indicate that "the line has been hung up" (a plain old telephone system modem reference to a line being "hung up" when disconnected. You know, because you "hang" the handset on the hook...)
The HUP signal will ask all programs to die conveniently.
Try this:
nohup load.php &
The nohup asks for the next program executed to ignore the HUP signal. See signal(7) and the nohup(1) manpages for details. The & asks the shell to execute the program in the background.
Clay's answer of using screen(1) is pretty awesome, definitely look into screen(1) or tmux(1), but I don't think that they are necessary for this problem.
This line might help you
php load.php &