I wish to debug a process which is already running using screen command.
Is there a way by which i can attach my running process with (some PID) to an existing screen (screen_name) ?
No, you can not use screen to debug a process running as daemon. If you would want to debug a process, shut off the daemon mode and run it in screen. and use
screen -rd {screen_ID}
Related
I am very new to linux, so I can't quite understand the difference between daemon, foreground process and background process.
As I understand that:
Daemon is simply a background process that runs in the background and has init as its parent process.
Foreground process is a process that we simply invoke from the console.
Then if I run for example nginx inside a docker container with "daemon off" flag that means that nginx will be the foreground process running in the container's console?
What is the problem exactly?
Read this.
To start a container in detached mode, you use -d=true or just -d option.
In foreground mode (the default when -d is not specified), docker run can start the process in the container and attach the console to the process’s standard input, output, and standard error.
I'm currently running a python script as a systemd service. Is there any way to "switch" into the service and take control of the script? The script has a menu but runs calculations in the background in another thread. Most likely not, so is there a way to run a python script 24/7, start on boot, restart on crash etc (just like systemd service) but be able to take control of it after I connect to the server via SSH, so I can manipulate the app?
One solution you could try would be to edit the systemd configuration to launch the process in screen or tmux, then attach that when logging in via SSH.
For instance, in the systemd unit, you might have:
[Service]
Type=single
ExecStart=tmux new "command"
Using Type=single will treat the tmux command as the main process, which would be killed if you stop it with systemctl stop systemprocess
The ExecStart=tmux new "command" creates a new tmux session with the command inside of it.
You can then attach to it using tmux attach as the same user the systemd unit is running as (I believe this is root by default).
I have packaged a Debian file of our software. Now there is a .sh script that needs to be started to run the program/software. This .sh script actually runs a Django server and few more services.
To actually start this application, we need to run the .desktop file in the menu. This .desktop file in the menu is associated with the .sh script mentioned above. This prompts the terminal and asks for the password. Once the password is given, this will start the services and the terminal stays active.
To close this service completely, we need to kill the process by finding the PID of the process and killing it from the terminal. But now I want to kill this process when I close the terminal.
How can I do that?
If you are trying to create a service (some program that runs in the background), you should create use your system's mechanism for this.
The traditional one, would be a scrip in /etc/init.d/, a more modern approach is to use systemd.
E.g. a file /etc/systemd/system/myservice.system
[Unit]
Description=My Service
[Service]
Type=simple
# you could run the service as a special user
#User=specialuser
WorkingDirectory=/var/lib/myservice/
# execute this before starting the actual script
#ExecStartPre=/usr/lib/myservice/bin/prestart.sh
ExecStart=/usr/bin/myservice
Restart=on-failure
[Install]
WantedBy=multi-user.target
You can then start/stop the service (as root) using:
systemctl start myservice
resp.
systemctl stop myservice
You can have dependency chains of services, so starting myservice will automatically start myhelper1 and myhelper2.
Checkout the manpage systemd.unit.5
When the controlling terminal is closed, the foreground process group should receive a SIGHUP signal. If your target process is already expected to be in the foreground, then it may be that it is catching or ignoring SIGHUP (the default behavior for a process receiving that signal is to terminate).
When I run dsc cassandra on CoreOS(tarball) using telnet everything comes up fine. But when i close the telnet session, it kills the process. How do i keep the cassandra server running?
I tried sudo bin/cassandra and sudo bin/cassandra -f
both didnt help.
I have no issues in other OS.
Option Description
-f Start the cassandra process in foreground. The default is to start as background process.
-h Help.
-p filename Log the process ID in the named file. Useful for stopping Cassandra by killing its PID.
-v Print the version and exit.
When you are starting cassandra using -f it runs in foreground, hence it will stop as soon as terminal is closed. Same is true for background process.
This will happen with any application you run in telnet session.
You can try
sudo service cassandra start OR nohup bin/cassandra this will keep your application running even when terminal is closed
You need to run Cassandra as a systemd service, as described here: https://coreos.com/os/docs/latest/getting-started-with-systemd.html
Running in the foreground with cassandra -f as your ExecStart= command will allow systemd to manage the state of the process (ideally inside a container).
While this is a bit different than what you're used to, it will lead to an overall more stable mechanism since you'll be using an init system that understands dependency chains, restart and reboot behavior, logging, etc.
Run the process in a screen or tmux session. Detaching from the screen session should allow the process to keep running.
Having an issue with Docker at the moment; I'm using it to run an image that launches an ipython notebook on startup. I'm looking to make some edits to ipython notebook itself, so I need to close it after launch.
However, hitting CTRL+C in the terminal just inputs "^C" as a string. There seems to be no real way of using CTRL+C to actually close the ipython notebook instance.
Would anyone have any clues as to what can cause this, or know of any solutions for it?
Most likely the container image you use is not handling process signals properly.
If you are authoring the image then change it as Roland Webers' answer suggests.
Otherwise try to run it with --init.
docker run -it --init ....
This fixes Ctrl+C for me.
Source: https://docs.docker.com/v17.09/engine/reference/run/#specify-an-init-process
The problem is that Ctrl-C sends a signal to the top-level process inside the container, but that process doesn't necessarily react as you would expect. The top-level process has ID 1 inside the container, which means that it doesn't get the default signal handlers that processes usually have. If the top-level process is a shell, then it can receive the signal through its own handler, but doesn't forward it to the command that is executed within the shell. Details are explained here. In both cases, the docker container acts as if it simply ignores Ctrl-C.
If you're building your own images, the solution is to run a minimal init process, such as tini or dumb-init, as the top-level process inside the container.
This post proposes CTRL-Z as a workaround for sending the process to background and then killing the process by its process id:
Cannot kill Python script with Ctrl-C
Possible problems:
The program catches ctrl-c and does nothing, very unlikely.
There are background processes that are not managed correctly. Only the main process receives the signal and sub-processes hang. Very likely what's happening.
Proposed Solution:
Check the programs documentation on how it's properly started and stopped. ctrl-c seems not to be the proper way.
Wrap the program with a docker-entrypoint.sh bash script that blocks the container process and is able to catch ctrl-c. This bash example should help: https://rimuhosting.com/knowledgebase/linux/misc/trapping-ctrl-c-in-bash
After catching ctrl-c invoke the proper shutdown method for ipython notebook.
From this post on the Docker message boards:
Open a new shell and execute
$ docker ps # get the id of the running container
$ docker stop <container> # kill it (gracefully)
This worked well for me. CTRL-Z, CTRL-\, etc. only came up as strings, but this killed the Docker container and returned the tab to terminal input.
#maybeg's answer already explains very well why this might be happening.
Regarding stopping the unresponsive container, another solution is to simply issue a docker stop <container-id> in another terminal. As opposed to CTRL-C, docker stop does not send a SIGINT but a SIGTERM signal, to which the process might react differently.
Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop a running container by sending SIGTERM and then SIGKILL after a grace period
If that fails, use docker kill <container-id> which sends a SIGKILL immediately.