Re: Multitasking, through Multiple Text Windows
On Sat, Jan 05, 2019 at 09:33:27AM -0500, Kenneth Parker wrote:
I first need to Date Myself
You don't, really: all it serves is to worsen the signal:noise ratio of
your email pertinent to the problem you are experiencing.
One "Special Function", which pointed out the "Fly in the Ointment" to my
above description, is Background Music. I LOVE Classical Music, so I would
have a Symphony Movement (mp3 file) playing in the Background, through the
play command (sox package) on one of these Virtual Text Terminals.
The reason I am bringing this up now, is that I tried this on Stretch, with
no Graphical Environment, only to have the Music (playing, through the play
command /dev/tty3) *STOP* *COLD* when I used alt-F4 to switch
perspective (say, to /dev/tty4!)
Don't worry, the notion of multitasking, or using multiple text VTs, or
operating your machine without a graphical stack, hasn't gone away: you
are just experiencing a bug or unintended side-effect of something, that
can be figured out.
I would research systemd (and/or PAM) "sessions, and "multi seat
support", which is my best guess as to what's happening. I don't think
the process is being stopped, but you are prevented from hearing it's
audio because that VT is no longer marked as an active local session.
If you experiment with a different program to "play"/sox on the first
VT, such as running a program that you can externally test is still
running (for example "while true; do touch /tmp/$(date +%s); sleep 1" -
you can see it is still executing if a new file appears in /tmp every
second), I suspect you will see that it is still running unfettered,
this problem you are experiencing is specific to audio.
There's some details here
https://www.freedesktop.org/wiki/Software/systemd/multiseat/
I'd wager your sound card is bound to a "seat"; and each of your VT
logins are separate "sessions", that are in turn bound to that same
"seat" and thus have permission to play sound. When you switch VT,
the former session is unplugged from the seat, and the new one plugged
in, therefore stopping the audio from the detached session.
The purpose of this whole scheme, fwiw, is to arrange for e.g. remote
sessions (such as those over SSH) to not have permission to blast audio
out of your local speakers, and similar things.
As a first test, try (as root) "loginctl enable-linger <your username>",
log out your VT3, and back in, launch play,then switch VT and see if the
problem is fixed. If not, you could revert the change with "loginctl
disable-linger <your username>", again as root.
Looks like SystemD may *NOT* be spawning the 6 Text Login Screens, like
the SysV Init Package did?
By default, systemd does not pre-load the getty processes on to the VTs
prior to you switching to those VTs. The rationale is to avoid the small
system overhead of running 6+ getty instances that the vast majority of
people never use. Instead, it spawns them on demand when you switch to a
VT (and clears them up once you've logged out and switched away again,
later).
This behaviour is optional and can be reverted to the way sysvinit
worked (see Felix's post in this thread). However I think it's
orthogonal to your sound issue.
You could also switch to sysvinit on Debian if you want, it's still a
fully supported option.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
Reply to: