In tmux I only have 2 groups, as opposed to the expected 5:
$ groups
username sudo staff website1 website2
$ tmux
$ groups
username sudo
Why is this and how do I fix it?
Perhaps your tmux server was started before you were added to the additional groups. The server process and any processes which it starts will only have the permissions that were in place when the server was started.
You can fix this by closing all sessions and starting a new server. Once you've quit any programs that you care about which are running inside tmux sessions you can use tmux kill-server to ensure that the old server process is ended. Then when you run tmux again it will automatically start a new server which should have all of your current permissions.
Related
I want to run unshare, mount a few directories, and run a tmux session in the new mount namespace. Here is my setup
$ cat run
#!/bin/bash
mount --bind ~/a ~/b
tmux
$ unshare -r --mount ~/run
When I run this command, I get dropped into the tmux session but without the binding. What is more strange to me is that if I rerun the mount command in the tmux session and exit, the next time I run unshare -r --mount ~/run the binding is there!
I could get consistent behavior by always running the mount command in the tmux session but I would like to understand why the behavior depends on if the binding existed in a previous session.
Replacing tmux with /bin/bash to poke at the mounted directory shows that the binding always happens, as expected. Once running the mount command in tmux, all subsequent runs have the binding until I move ~/a. Then the problem is back.
I am now unable to reproduce my own problem. I suspect the solution was to power cycle. I do not think I had done so between installing tmux and running into this issue, so that may have been the root cause.
I found out that I have quite many Symfony local web server workers registered (around ~35), and the number keeps growing. I usually just start server with symfony serve and then kill it (Ctrl + \) when no longer needed. Apparently killing it leaves a worker behind, as seen in symfony server:status. Running symfony serve again just creates a new worker.
symfony server:status output:
Local Web Server
Not Running
Workers
PID 6327: /usr/bin/php7.2 -S 127.0.0.1:43653 -d variables_order=EGPCS /home/mindaugas/.symfony/php/83247c3521c3ac3990bf3f823ef473db0a9445e1-router.php
PID 24596: /usr/bin/php7.2 -S 127.0.0.1:37789 -d variables_order=EGPCS /home/mindaugas/.symfony/php/83247c3521c3ac3990bf3f823ef473db0a9445e1-router.php
PID 6575: /usr/bin/php7.4 -S 127.0.0.1:42505 -d variables_order=EGPCS /home/mindaugas/.symfony/php/83247c3521c3ac3990bf3f823ef473db0a9445e1-router.php
PID 41550: /usr/bin/php7.4 -S 127.0.0.1:36313 -d variables_order=EGPCS /home/mindaugas/.symfony/php/83247c3521c3ac3990bf3f823ef473db0a9445e1-router.php
...
Environment Variables
None
So my questions regarding this:
#1: is it possible to quickly kill the server? I assume symfony server:stop is more correct way, but that requires additional console window and entering the command.
#2: how to kill those workers that are registered from previous sessions? Trying e.g. kill 6327 says that there's no such process. Also they're not gone after system restart.
Those extra workers are bothering me because for each one of them the server log output in the console is duplicated. So right now on each request to the server I get around 3k lines of log output in the console. Which makes it pretty useless.
I have the same problem after upgrading to Symfony CLI version v4.19.0...
My (very) bad workaround:
rm /home/myusername/.symfony/var/83247c3521c3ac3990bf3f823ef473db0a9445e1/*
Edit: this answer is not accurate, as hinted a by #CrSrr's answer above.
The symfony command adds data to both the ./log and ./var directories. Deleting entries in only one of those does not remove the appearance of non-existent workers in the project directory. I was fooled by checking status in a directory where the server:start had never been run.
A bug report is on file with symfony here.
Just faced with a similar issue. The PIDs were not to be found.
PS G:\workspace\joined> symfony server:status
Local Web Server
Not Running
Workers
PID 7732: C:\php\php-cgi.exe -b 63801 -d error_log=C:\Users\George\.symfony\log\e79ad2f4b30a2f0a35c3b5ab08772770b382a3d6.log
PID 19324: C:\php\php-cgi.exe -b 62927 -d error_log=C:\Users\George\.symfony\log\e79ad2f4b30a2f0a35c3b5ab08772770b382a3d6.log
PID 17968: C:\php\php-cgi.exe -b 50197 -d error_log=C:\Users\George\.symfony\log\e79ad2f4b30a2f0a35c3b5ab08772770b382a3d6.log
PID 14040: C:\php\php-cgi.exe -b 55075 -d error_log=C:\Users\George\.symfony\log\e79ad2f4b30a2f0a35c3b5ab08772770b382a3d6.log
Environment Variables
None
In the Windows OS, the log files are kept in %USERPROFILE%.symfony. There's most likely a similar location in your home directory. Deleting all the contents of that directory allowed a new Windows Terminal app to show:
PS G:\workspace> symfony server:status
Local Web Server
Not Running
Workers
No Workers
Environment Variables
None
do symfony serve:stopto stopped the server and do against symfony serve to run the server good luck
The naive way to do this is not working. Try this:
Start a first tmux session.
$ export ENVIRONMENT="production"
$ tmux
You can then verify that inside the session ENVIRONMENT is production
Then, in a second terminal start another session
$ export ENVIRONMENT="staging"
$ tmux
Surprisingly in this session ENVIRONMENT is also production! This is very unintuitive!
What is going on here?
How can I achive this? I like all windows in a session to "inherit" the ENVIRONMENT variable.
The "simplest" solution is to create a new tmux server with the different environment.
$ ENVIRONMENT=production tmux -L prod-tmux
and
$ ENVIRONMENT=staging tmux -L staging-tmux
You'll always need to specify which socket, prod-tmux or staging-tmux, to use whenever you reconnect to an existing session.
The next solution would be to use one server, but modify the environment of each session in that server. Something like
$ tmux new-session -d -s production
$ tmux new-session -d -s staging
$ tmux set-environment -t production ENVIRONMENT production
$ tmux set-environment -t staging ENVIRONMENT staging
Note that ENVIRONMENT would not be set in the process running in the initial window for each session, but will be for any subsequent window created. (Unless the server inherited ENVIRONMENT when it first started.)
When you run tmux, it first looks for an existing server (either the default server, or the one specified by either the -L or -S options). If there is no server, one is started, and the server's environment is inherited from the current environment.
If there is a server, tmux simply requests the server to execute a tmux command (by default, new-session, or whatever command is specified by an argument to tmux) command, then exits. The environment of the tmux command itself isn't relevant, unless the requested command is documented to read from it (cf. set-environment).
The server manages a group of windows, each of which represents a process created by the server (not the tmux command itself). A session is just a logical group of windows, also managed by the server.
Newer versions of tmux seem to support this natively! I do devops support for multiple clients and wanted to set a separate bash history file for each client. The following works very well for me! It sets the working directory, to the client/project dir, and sets the bash history file path
tmux new -c ~/Documents/code/CLIENT/ -e HISTFILE=~/Documents/code/CLIENT/.bash_history -s CLIENT -d
Based on the excellent answer by #chepner we can solve this issue by adding aliases to define different tmux commands for different servers. For example we could append the following to ~/.bashrc.
# somewhere in ~/.bashrc
alias tmux-s1='tmux -L s1'
alias tmux-s2='tmux -L s2'
alias tmux-s3='tmux -L s3'
alias tmux-s4='tmux -L s4'
alias tmux-s5='tmux -L s5'
Now we can use tmux-s1, tmux-s2, etc... the same way we would normally use the tmux command except each variant will be associated with a different server. When we create a session for a server that has no active sessions then the current environment variables will be used to initialize the server. To reattach to the session we will need the alias for the server that the session was created with.
Example
$ export ENVIRONMENT="production"
$ tmux-s1 ls
no server running on /tmp/tmux-12345/s1
$ tmux-s1
############### now attached to session 0 on server s1 ################
$ echo $ENVIRONMENT
production
################### (ctrl+b,d) detach from session ####################
[detached (from session 0)]
$ tmux-s1 ls
0: 1 windows (created Sun Nov 17 18:13:18 2019) [80x20]
$ export ENVIRONMENT="staging"
$ tmux-s2 ls
no server running on /tmp/tmux-12345/s2
$ tmux-s2
############### now attached to session 0 on server s2 ################
$ echo $ENVIRONMENT
staging
################### (ctrl+b,d) detach from session ####################
[detached (from session 0)]
$ tmux-s2 ls
0: 1 windows (created Sun Nov 17 18:13:22 2019) [80x20]
I´m a happy user of byobu, but recently I noted that I cannot attach anymore to open sessions.
With ps aux | grep tmux I can clearly see many tmux processes, but unfortunatly, when I try to attach with:
tmux attach
byobu attach
I get no results but a no session error. Moreover, with byobu-select-session I got a failed to connect to server instead.
There is a commant to connect tmux to a given socket, which I found using
lsof -U | grep '^tmux'. But still no session attached. My session files are in /tmp/user/tmux-1000/default, but I can see some sockets being used.
From ps aux I can see that byobu launches tmux with: tmux -2 -f /usr/share/byobu/profiles/tmuxrc new-session -n - /usr/bin/byobu-shell
Unfortunately, either with byobu -S path or byobu -L socketname I am not able to attach to previously open session, and byobu simply start a new session.
I run into a similar situation caused by accidentally removing the tmux socket in /tmp. The method described here solved the problem for me (either killall -SIGUSR1 tmux or kill -USR1 $PID_FOR_RUNNING_TMUX).
Is it possible to export/import tmux sessions?
At the university we have identical machines (same binaries and file structure) and sometimes I want to move a tmux session from one machine to another. Is there a way to do this?
As pointed on the comments, it is very unlikely that you would be able to restore all the state of tmux session.
If your purpose is to access the tmux session from a different machine (hostB), while the tmux session is still running on the original machine (hostA), you could simple access it through ssh:
hostB $ ssh hostA
hostA $ tmux attach
The link you mentioned contains a discussion about how to re-create a tmux session. If you are interested in starting a similar tmux session, you should try tmuxinator:
# ~/.tmuxinator/sample.yml
name: sample
root: ~/
windows:
- editor:
layout: main-vertical
panes:
- vim
- guard
- server: ssh serverX
- logs: tail -f log/development.log
By issuing mux start sample you will have a tmux session with three windows:
the first with two panes, the first one running vim
the second with a ssh to a given server
the third displaying the tail of a log file
Using this file you could start similar sessions on different machines.