A common task people want to perform is running a set of given programs during every Wayland session.

GNOME and KDE have their own approaches and graphical utilities for down this. For those of us who don't use a desktop environment, how about in Sway?

A bit of experimentation appears to show that this syntax is a pretty reasonable way to do this:

# Power notification support
exec_always flock -n $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY-poweralertd poweralertd -s

# Make clipboard persist after application termination                                                                                                                                          
exec_always flock -n $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY-wl-paste wl-paste --watch clipman store                                                                                                  

Thought I'd share for anyone else running into this.

For some Sway users, that may be enough. But if anyone wants to read more history, here goes!

Background and rationale:

Once upon a time, it was conventional to have a shell script, ~/.xinitrc, that was invoked whenever someone started up an X server with startx after logging in on an (initially) text terminal. Any per-session commands could be invoked here.

Later, when display managers showed up, it became common for a Linux machine to go straight to a graphical display at boot and show a login prompt from there. xdm showed up; if it was started, it'd run another shell script, ~/.xsession. A lot of people, including myself, just symlinked ~/.xsession to ~/.xinitrc.

Still later, some desktop environments, like GNOME or KDE or some less-popular ones, introduced their own schemes for storing a list of programs to start when the graphical environment came up.

Wayland+sway -- to my initial surprise and annoyance -- isn't really geared up for that. In theory, you can use whatever login manager you want. I use a non-standard login manager -- greetd to launch agreety (and I'd use emptty if it were in Debian bookworm) which lets me log in on a terminal. But these don't provide functionality to run a startup script. This kind of makes sense -- on X11, once the display manager starts things up, X11 can run programs, whereas Wayland really requires a functioning compositor to be going, which means that Sway really needs to be up and running. So maybe it makes sense for the compositor, Sway, to handle launching startup programs in the graphical environment, rather than the login manager. but Wayland compositors don't have even a semi-convention for a "login script" like ~/.xinitrc or ~/.xsessionor~/.xprofile` or an equivalent, which surprised me. That might be because Wayland compositors are heavier than their X11 window manager analogs, and perhaps its less-expected for people to be switching among them.

What Sway does is to, in its config file, ~/.config/sway/config, have two directives, exec and exec_always. One can make them invoke a script. These can be handy. But they don't quite what I'd ideally like them to do.

You see, Sway -- like some X11 window managers -- has the ability to permit a "reload", where it re-reads its config files. That's handy! If an X11 window manager couldn't do that, when you changed its config file, you'd have to close all your graphical programs, log out, and log in again to confirm that it did what you wanted. You don't have that problem with Sway. You can just change its config file, ask Sway to do a reload, and it'll be "re-applied". And then exec and exec_always come into play -- the former will run a program only when Sway initially starts, but not when it does a "reload". The latter will run a command each time, both at Sway start and each time Sway reloads its config file.

For some programs, exec and exec_always are sufficient. Maybe you just want to make sure that a program has been run and then terminated at least once in your current session.

But that isn't normally what I want to do. By far my overwhelming need -- and I suspect this is true of others -- is that I want to have some kind of daemon running and persisting in the background of my session.

Some daemons try to be clever. If you try to run multiple instances at once, the new instance will just bail out. blueman-applet is like this. And if your daemon works like this, then running exec_always is fine. If you run a new instance and there's an already-running instance, the new one will just bail out.

But some daemons don't -- they just start up another instance. So every time you reload your Sway config, exec_always will start another instance of that daemon. I have a couple of daemons like that. poweralertd notifies me when my laptop battery is getting low, for example. If I just let poweralertd do its own thing and start it via exec_always, then when my battery gets low, if I've reloaded my Sway config 5 times, I'll have 5 instances running, and get 5 warnings when my battery gets low.

But running exec isn't ideal either, because then you have to give up on Sway "reapplying" your config when you reload it. If I want to have a new daemon running in the background of my Wayland session, I don't want to have to log out to ensure that my config is working correctly.

Now, at this point, I suspect that a number of people think "Aha! What about systemd?"

So, not everyone is a huge fan of systemd. It is a very large software package that provides a lot of useful functionality to most present-day Linux systems. So you might not want to tie yourself to systemd.

But more-problematic -- while systemd does have the ability to manage both "system" daemons that run one instance per system, typically come up when the system does, and "user" daemons, one instance per user...that isn't quite correct for Wayland. It's reasonable for a user to have multiple concurrent Wayland sessions on a Linux machine. Maybe it might make sense to selectively share some functionality among those, like one mpd instance to play music -- dunno about that. But you definitely don't want to have random Wayland programs run in each session running one-instance-per-user, because otherwise, any additional Wayland session will have the programs just not come up in that new session.

It looks like some people out there have recognized that this is an issue. uwsm looks to my quick glance at being a stab in the direction of "per-Wayland-session systemd-based management". But whether-or-not it could be used, it's not in Debian bookworm, and I want to use stock software for basic stuff like getting my desktop up on a new system.

Hence, we get to the above flock-based approach. So, let's say that one wants to have a program like wl-paste running persistently, but only one per-session. How?

We want to have only one instance running at once. Traditionally, the way to achieve that on a Unix system is to create a file, then establish a "file lock" on it via the flock(2) function; this is guaranteed by the OS to be an atomic operation, only one can occur. There's a command, flock(1), which does all this at one go -- it creates a file if it doesn't exist, establishes a file lock on it, and then, while continuing to run, runs a specified command. When a process goes away, the OS releases the file lock, so when the invoked command (here, wl-paste) exits, the flock process exits, and the file lock goes away. By default, flock will block if there's a lockfile with a held lock, which is what you want if you just want to make sure that two commands wait to avoid interfering with each other but with -n, it'll just fail; this is the behavior you want if you want to make sure that you have one, but only one, daemon active.

And we want to have one instance per session, not per user. The $XDG_RUNTIME_DIR environment variable provides a temporary directory per-user...but not per session. $WAYLAND_DISPLAY is guaranteed to be unique per session for a given user. So any path containing both $XDG_RUNTIME_DIR AND $WAYLAND_DISPLAY is going to be unique per-session; we just need an extra bit of text ("-poweralertd") to make it unique to a given daemon per session.

Given how this wasn't an immediately-obvious approach to me, thought that I'd point it out to anyone else who might be using Sway and want per-session daemons running.

Curious as to what people think has the most replay potential.

Rules:

1. The "desert island" aspect here is just to create an isolated environment. You don't have to worry about survival or anything along those lines, where playing the game would be problematic. This isn't about min-maxing your situation on the island outside of the game, or the time after leaving.

2. No live service games unless the live service aspect is complete and it can be played offline -- that is, you can't just rely on the developer churning out new material during your time on the island. The game you get has to be in its complete form when you go to the island.

3. No multiplayer games -- can't rely on the outside world in the form of people out there being a source of new material. The island is isolated from the rest of the world.

4. You get existing DLC/mods/etc for a game. You don't get multiple games in a series, though.

5. Cost isn't a factor. If you want The Sims 4 and all its DLC (currently looks like it's $1,300 on Steam, and I would guess that there's probably a lot more stuff on EA's store or whatever), DCS World and all DLC ($3,900), or something like that, you can have it as readily as a free game.

6. No platform restrictions (within reason; you're limited to something that would be fairly mainstream). PC, console, phone, etc games are all fine. No "I want a game that can only run on a 10,000 node parallel compute cluster", though, even if you can find something like that.

7. Accessories that would be reasonably within the mainstream are provided. If you're playing a light gun game, you can have a light gun. You can have a game controller, a VR headset and controllers, something like that. No "I want a $20 million 4DOF suspended flight sim cockpit to play my flight sim properly".

8. You have available to you the tools to extend the game that an ordinary member of the public would have access to. If there are modding tools that exist, you have access to those, can spend time learning them. If it's an open-source game and you want to learn how to modify the game at a source level, you can do that. You don't have access to a video game studio's internal-only tools, though.

9. You have available to you existing documentation and material related to the game that is generally publicly-available. Fandom wikis, howtos and guides, etc.

10. You get the game in its present-day form. No updates to the game or new DLC being made available to you while you're on the island.

What three games do you choose to take with you?

Quick background for anyone who doesn't use tmux or screen: both are utilities that run in terminal that provide a bunch of nifty functionality. The big ones are:

• The ability to disconnect from a remote host and reconnect via software like ssh or mosh, leaving the remote programs running. This also ensures that connection loss doesn't kill off remote programs, making it -- in my opinion, at any rate -- pretty essential for ssh, though mosh has more-limited built-in functionality.

• The ability to have multiple virtual terminals in one. There are a bunch of ways to do this (the Linux kernel has multiple ttys, X11 window managers or Wayland compositors can provide virtual desktops with different graphical virtual terminal programs running on each, and some virtual terminal programs provide a way to run multiple virtual terminals, usually in a tab or something). I prefer this route, though, because among other reasons, it works everywhere.

But they also provide a lot of other handy functionality, including things like file transfer via the terminal (well, screen does), logging of what the current terminal is receiving, copy-pasting using vi or emacs keybindings, a terminal-level "status bar", and such.

But I was doing work on my tmux config, and thought that I'd go over my ~/.tmux.conf, since it addressed a few things that annoyed me, and I figure that other people might have crashed into. Maybe others could share some of their neat tmux or screen stuff, if they're in the moon:

unbind-key C-b
set-option -g prefix C-o
bind-key C-o send-prefix

This sets tmux to use "Control-o" as the "prefix key", which it uses before all other keybindings. Out-of-box, both screen and tmux grab keybindings which conflict with very-common emacs keybindings, C-a (beginning of line) and C-b (previous character), respectively. Control-o is only used by (what I'd call) a fairly-obscure emacs feature, which you can still access by hitting Control-o twice. If you use vi keybindings (including in bash and other programs that use readline, which default to using emacs-style keybindings), probably not necessary. Been using this for many years, ever since screen; it's apparently a very common problem for new tmux and screen users.

set-option -g status-bg black
set-option -g status-fg cyan

By default, tmux uses black text on a bright green background for the status bar; while this shows up well, for me, at least, this is kind of overwhelming. I prefer light text on a black background, or "dark mode", as it's popularly called these days. On some terminals, blue is hard to read out-of-box, and while I generally try to tweak my terminals to get it readable, cyan (bright blue) avoids this.

set-option -g status-left '#I|#H #(cut -d " " -f 1-4 /proc/loadavg)'
set-option -g status-right ""
set-option -g window-status-format ""
set-option -g window-status-current-format ""

The default tmux configuration follows a convention where, for each "window" one opens, there's a visual indicator showing a per-window entry. This is a common convention that many GUI programs use (opening a tab per window). Emacs traditionally has not done this, the idea being that you should be able to have many buffers open, that screen space is a limited resource and that if you want to switch the content that you're looking at, you're better-off bringing up a full-screen, scrollable list. tmux can do this with prefix-key w out-of-box. If you have, say, ten open, there isn't gonna be space to show 'em all. So I pull that out.

I do want to see the host, to ensure that I don't confuse a tmux instance running on Host A running ssh in a window with sshing to Host B and running tmux there.

Tmux defaults to showing a clock, which I get rid of with the above. I already have a clock on my desktop, and I don't see much sense in throwing them elsewhere in each terminal. Tmux even defaults to showing a large one if you hit prefix-key t, though I can't imagine that many people use that.

The current loadavg isn't essential, but it's a useful bit of status that tells one immediately whether some program is either still doing work or running away.

I don't use window names: just numbers; so I hide names. It's normally obvious from looking at a virtual termainal what something is, and switching by number is faster by keystroke.

set-option -g update-environment "DISPLAY WAYLAND_DISPLAY SWAYSOCK SSH_AUTH_SOCK"

This updates the environment variables in a tmux session when re-attaching. Various programs don't do well if you detach from one session, log out of a graphical session, and then log in again; this fixes those. DISPLAY is for X11, WAYLAND_DISPLAY for Wayland, SWAYSOCK for the Wayland Sway compositor (if you use that), and SSH_AUTH_SOCK for ssh-agent, which remembers a password to unlock an ssh key for a while.

bind-key H pipe-pane -o "exec cat >>$HOME/'tmux-#I.log'" \; display-message "Toggled logging to $HOME/tmux-#I.log"

This sets up tmux to provide functionality that screen has out-of-box -- if you trigger it, it will start logging the output of the current console to a logfile in your home directory. Useful when you've already started a program and it's spitting out information that you need a copy of, or if you want it to not disable color output (something that many programs do when they detect that their output is connected to a pipe rather than a tty); with my settings, Control-o H will toggle logging for a given window.

# emacs-style keys
bind-key C-n next-window
bind-key C-p previous-window
set -g mode-keys emacs
set -g status-keys emacs

I like emacs-style keys rather than vi-style.

bind-key C-c new-window -c "#{pane_current_path}"

While tmux has a default keybinding (prefix-key c) to create a new window at the current working directory that tmux was started at, it has no binding to start a new window at the current working directory being viewed in a window at the moment, something I frequently want to do -- this makes prefix-key Control-c open a new shell at that point.

set -g visual-bell on

Beeping is obnoxious and in an open environment, can be disruptive to other people; many people switched to having their terminal flash rather than beep years back; many programs supported "visual bell", which is just flashing rather than playing a sound. It's not so bad these days, as Linux machines aren't typically playing irritating beeps out of on-motherboard speakers, but in general, I don't like having things beep.

Anyone else got useful snippets that they'd like to share that they use with tmux or screen?