What is the cleanest way to exit/kill/logout linux session? - linux

I am using tiling window managers and from time to time I want to go back to a normal desktop environment or switch to another tiling window manager.
Usually I use a rofi script with loginctl terminate-user $USER.
Before this I used pkill -9 -u $USER.
I also found other options such as loginctl kill-user $USER and pkill dwm or pkill i3.
With so many options, I started to wonder which is the best and cleanest way to exit a session?

To kill a window manager, you only need to kill the X server, leaving Linux and your login shell running.
For a general command, you can use:
pkill -x X
In the specific case of i3, from i3's documentation:
To exit i3 properly, you can use the exit command, however you don’t need to (simply killing your X session is fine as well).
Example:
bindsym $mod+Shift+e exit

Related

How to detect if i3-wm is being run or GNOME is being run in bash

I've been using i3-wm for about six months now, and I had to switch to GNOME because Discord was crashing a lot in i3. I had previously used the i3-msg command in my bashrc to make sure the borders of the terminal wouldn't be visible, as to use the entire screen space for the terminal. The specific command I run is:
i3-msg -q border toggle
The problem is, when I use GNOME and I open up a terminal, the i3-msg command runs, and causes an error message evidently caused by the fact that i3 isn't running. The ideal scenario would be to add an if statement that checks if i3 is running, and if it is, then run the i3-msg command.
My question: What is the most convenient way to determine which window manager / Desktop Environment is currently running in my system?
When i3 is active, there should be a proces called "i3". You could check that with pgrep.
if pgrep -x "i3" > /dev/null
then
echo "i3 is running"
fi
-x is short for --exact – without it the if clause would still work, as long as no non-i3 process' name contains i3.
Omitting > /dev/null would print out the pid(s) found by pgrep.
Instead of pgrep you could also use pidof or ps -C. Instead of idiomatic if-then-fi you could also just use && like pidof i3 > /dev/null && echo "i3 is running" || echo "i3 is not running"

linux - running process background

I want to run a process in a remote linux server and keep that process alive after close the putty terminal,
what is the correct command?
You have two options:
Use GNU screen, which will allow you to run the command and detach it from your terminal, and later re-attach it to a different session. I use it for long-running processes whose output I want to be able to monitor at any time. Screen is a truly powerful tool and I would highly recommend spending some time to learn it.
Run the command as nohup some-command &, which will run the command in the background, detach it from the console, and redirect its output into nohup.out. It will swallow SIGHUPs that are sent to the process. (When you close the terminal or log out, SIGHUP is sent to all processes that were started by the login shell, and the default action the kernel will take is to kill the process off. This is why appending & to put the process in the background is not enough for it to survive a logout.)
don't use that nohup junk, i hate seeing that on servers; screen is a wasting pile of bits and rot -- use tmux.
if you want to background a process, double fork like every other daemon since the beginning of time:
# ((exec sleep 30)&)
# grep PPid /proc/`pgrep sleep`/status
PPid: 1
# jobs
# disown
bash: disown: current: no such job
enjoy.
The modern and easy to use approach that allows managing multiple processes and has a nice terminal UI is hapless utility.
Install with pip install hapless (or python3 -m pip install hapless) and just run
$ hap run my-command # e.g. hap run python my_long_running_script.py
$ hap status # check all the launched processes
See docs for more info.
A command launched enclosed in parenthesis
(command &)
will survive the death of the originating shell.

How to start a process that won't end when my ssh session ends?

Somehow this isn't yielded by a google search.
I'm scripting a server in node.js. I start the server by executing its script with the node program:
node myserver.js
But the server staying up is dependent on my ssh session. How can I make this (and all such processes) persistent? Init.d?
Use the nohup command:
From http://en.wikipedia.org/wiki/Nohup
nohup is a POSIX command to ignore the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. The HUP (hangup) signal is by convention the way a terminal warns depending processes of logout.
Try this:
nohup node myserver.js &
Have you tried GNU screen? Using it, a process can continue to run when you end your ssh session. nohup is a standard *nix command that will allow you to do the same, albeit in a more limited way.
Use screen. Type screen from the terminal and then launch your process. If you disconnect you can reconnect to the ssh session, by typing 'screen -ls' (to see active screens) and 'screen -r' to reconnect.
The program needs to run in a daemonized mode. Here's a good post for doing this in Ubuntu.
nohup is good to run the job under. If the job is already running, you can try disown -h (at least in bash)

How to run infinitely script in background on Linux?

I have a PHP script with infinite loop. I need this script running forever. So, I run
php /path/to/script.php > /dev/null &
And it works in background in my current user's security context. But when I close terminal window (log off), of course, CentOS Linux kills my program.
I see two guesses: run from a different user in background or make a daemon. I need help in each situation.
Thanks a lot!
nohup is your friend.
nohup command &
I think the general solution to that is nohup:
nohup is a POSIX command to ignore the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. The HUP (hangup) signal is by convention the way a terminal warns depending processes of logout.
nohup is most often used to run commands in the background as daemons. Output that would normally go to the terminal goes to a file called nohup.out if it has not already been redirected. This command is very helpful when there is a need to run numerous batch jobs which are inter-dependent.
nohup is your friend.
You could:
Install screen and run the command from there. screen is a persistent terminal session that you can leave running.
Write an init/upstart (whatever you use) script so it loads on boot
Use the pear lib system_daemon
Use cron if batch work fits the scenario better (just remember to check for running instances before you launch another, iff concurrency is an issue)
Edit: or as everybody else and their brother has just said, nohup
Using command
nohup your_command &
For example
nohup phantomjs highcharts-convert.js -host 127.0.0.1 -port 3003 &
here "phantomjs highcharts-convert.js -host 127.0.0.1 -port 3003" was my command

Running shell script in detached screen session. Must kill. How?

I am an Ubuntu Linux user. I am running jobs remotely and started a screen session. During this session I sourced a file containing a long list of command lines arguments to be executed. I was forced off of the connection and now the jobs are still running in this screen and I am unable to kill them.
Does anyone know how to kill all running and future commands this script will execute. Thank you in advance.
If you just want to kill everything there is no need to even reattach to screen.
Just list the offending process(es):
pstree -pla
then kill whatever needs killing. Note that if you kill a process higher up the process tree, its children will (usually) go away as well.
Reattach the screen with
screen -D -r
then you can resume your session.
Use ps to identify the pid of the shell process (bash, tcsh, etc), then kill that...
There are a couple of 'screen' ways to kill a specific screen session ...
1) send a 'quit' command:
screen -X -S "sessionname" quit
2) send a Ctrl-C to a screen session running a script:
screen -X -S "sessionname" stuff "^C"
In both cases, you would need to use 'screen -ls' to find the session name of the screen session you want to kill ... if there is only one screen session running, you won't need to specify the -S "sessionname" parameter.

Resources