We have developed Installer for CentOS 7.5, we are running Installer on CentOS when Installation action is started where we copy files and folder and then actual shell scripts of Installation, during this if we close terminal window then sh process is getting killed but no rollback is imitated which is configured by Install4j failed/failure event.
We want to perform rollback when such process kill/terminal close scenario is observed.
Please help.
It may not be possible to perform a rollback if the process is killed. Rollbacks are performed when the user enters CTRL-C on the command line or cancels the GUI wizard.
Related
I am currently starting to work with SNNs on a GPU server. I am working with VS Code Remote-SSH package. Thereby, I'd like to use the tmux package to be able to start multiple processes which don't terminate when I disconnect the terminal from the server.
So far I used the https://cppdev.medium.com/vs-code-and-tmux-intergation-for-reliable-remote-development-e26594e6757a Tutorial. It already helps me that the process, I run doesn't shut down when I close the terminal but I didn't manage to start a second process on the server because each time, I open a new terminal, the already running process appears. What are your thoughts on that?
Thanks
Hi we are working on GUI+CLI based installer for CentOS 7 platform.
If we hit ctrl+c on terminal while execution of installer in CLI mode the cancelled event is fired and we have called custom rollback script which gets executed properly.
If we hit ctrl+c on terminal while execution of installer in GUI mode the cancelled event is not fired and it fails to execute the rollback script.
Why there is difference in behavior for GUI and CLI mode?
Is there is any way where we can disable ctrl+z ctrl+c ctrl+d while execution?
As of install4j 9.0.1, the CTRL-C is indeed not caught and processed by the GUI installer. I have added this feature request to the issue tracker.
I'm developing on a VM and I'd like to automate booting and shutting down the VM whenever I launch VSCode into this project (over ssh).
I got around having to boot the VM by creating a script that launched the VM then VSCode. I use that to launch VSCode instead of the start menu whenever I want to work on this project. However, this solution doesn't work for shutting down the VM when I'm done.
Is there any way to accomplish this? Maybe some project setting that would execute a shutdown script on the VM when I disconnect, or some way I could hook up a script to run on my machine when VSCode closes that would shut down the VM?
Is there any way to avoid the janky startup script? Can I run a script when VSCode launches as well?
According to Visual Studio Code issue #10044 https://github.com/Microsoft/vscode/issues/10044, there is no way to run a script automatically from inside VSCode at startup unless you are willing to write an extension. Even if you are going to write an extension according to the API documentation https://code.visualstudio.com/api/references/activation-events for VSCode, There is no event for when shutdown occurs.
EDIT: Although it is not possible to do this within VScode alone, you could write a wrapper script when starting and exiting to to run the command.
I have been running jEdit 5.3 for about 1.5 years with no significant problem. On 2017-07-03 I used it and it worked fine. On 2017-07-04, it would not start. jedit and javaw exe's were created, but the jEdit window did not display. I uninstalled version 5.3 and tried to install version 5.4 and got this error:
"The installer will now try to quit a running instance of jEdit.
Please save your work and exit jEdit for the installation to continue."
When I continue, the installer freezes. The same happens if I try to install version 5.3. I did not have a running instance, but the installer thought that I had one. I am guessing that something went wrong with jEdit when I shutdown on the 3rd. (I always intend to close all apps before I shut down, it is possible that I forgot to shutdown jEdit.)
Does anyone know how to tell windows 7 to get rid of this phantom instance of jEdit. I am using a backup version of jEdit 4.5.2 for the time being. So, I can continue with my work. I am guessing that this phantom instance also caused the jEdit 5.3 startup problem that I had before the uninstall.
2017-07-15 Update: I tried installing jEdit 5.4 on Saturday and it worked! On my previous try, when I got the 'running instance' warning I stopped, because every other time I continued at the point the installation froze. On Saturday, I tried continuing after the warning, and it worked! My thanks to Ross Rogers and Mr. Vampire for taking the time to give me expert advice. Renaming the roaming jedit file apparently was effective. I am guessing that deleting the server file would have helped also.
The most likely cause is a stale server file that points to some other process. jEdit and the installer talks to running instances via the network (TCP) on a port that is opened randomly and written to the server file in your settings directory. If you do not quit jEdit cleanly (e. g. only close the window without using the file menu or the shortcut to completely quit jEdit when the jEdit server is running), then jEdit on next start (or the installer) finds the server file and tried to talk to the process listening on the port written in the file. If there is no process listening, it is assumed that the server file is stale and a new instance of jEdit is started. Unfortunately jEdit is not as grateful if there is some process listening on that port but is not answering, jEdit just waits forever currently. This definitely needs to be improved and I think there is also a ticket for this. Try to delete the server file in your settings directory, by default it is %APPDATA%/jEdit/server on Windows and then try to start jEdit or the installer again.
I had to add /SUPPRESSMSGBOXES. /VERYSILENT wasn't silent enough. /? doesn't tell you what the options are.
https://www.itninja.com/software/contributors/jedit-1/4-2570
I recently started developing for Node.js/Express with Nodeclipse. I added a run configuration for package.json with goal start. This works as expected, the start command from package.json is executed (node ./bin/www). I can see this command in Eclipse's console view and I can see two node.exe processes appear in Windows Task-Manager. HTTP requests to http://localhost:3000/ are logged in the console.
However, klicking the red "Terminate"-Button in Eclipse's console view leaves the node.exe processes running. Subsequent attempts to start the app fail because the port is already in use.
I do not have this problem when I start the app with npm start in Windows cmd. Stopping the execution with Ctrl+C will also exit the node.exe processes.
This is my IDE-Setup:
Eclipse Luna SR2 (4.4.2) under Windows 7 x64 with jre1.8.0_45
Eclipse was setup this way: extracted eclipse-platform-4.4.2-win32-x86_64.zip (from here), installed Eclipse Marketplace Client, then installed Nodeclipse via Drag&Drop from nodeclipse.org
Node.js version v0.12.2 (for Windows x64)
express-generator (version 4.12.1) is installed globally
How can I make the Terminate button in the console view actually terminating the node.exe processes?
It seems that Eclipse only kills the npm script that is used to start up node. The thing is that Eclipse forcibly kills that script, giving it no chance to send any signals to the node.exe process.
This bug explains why this works this way.
Step 1:
Run command-line as an Administrator. Then run the below mention command. type your port number in yourPortNumber
netstat -ano | findstr :yourPortNumber
Red coloured circled area shows the PID (process identifier)
Step 2 :
Then you execute this command after identify the PID.
taskkill /PID typeyourPIDhere /F
P.S. Run the first command again to check if process is still available or not. You'll get empty line if process is successfully ended.