Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #243186 > unrolled thread

8 -> 9 update changing things

Back to article view | Back to linux.debian.user

Contents

  8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-16 20:40 +0100
    Re: 8 -> 9 update changing things "Andrew M.A. Cater" <amacater@einval.com> - 2021-12-16 20:50 +0100
      Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-16 23:00 +0100
        Re: 8 -> 9 update changing things Dan Ritter <dsr@randomstring.org> - 2021-12-17 00:20 +0100
          Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-17 01:50 +0100
            Re: 8 -> 9 update changing things Charles Curley <charlescurley@charlescurley.com> - 2021-12-17 04:50 +0100
        Re: 8 -> 9 update changing things David Wright <deblis@lionunicorn.co.uk> - 2021-12-17 18:00 +0100
          Re: 8 -> 9 update changing things rhkramer@gmail.com - 2021-12-18 14:50 +0100
            Re: 8 -> 9 update changing things Dan Ritter <dsr@randomstring.org> - 2021-12-18 15:50 +0100
          Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-18 17:30 +0100
            Re: 8 -> 9 update changing things Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-19 09:20 +0100
              Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-19 19:30 +0100
                Re: 8 -> 9 update changing things Dan Ritter <dsr@randomstring.org> - 2021-12-20 00:10 +0100
                  Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-20 16:10 +0100
                    Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-22 17:10 +0100
                      Re: 8 -> 9 update changing things Dan Ritter <dsr@randomstring.org> - 2021-12-22 17:40 +0100
                        Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2021-12-24 18:40 +0100
            Re: 8 -> 9 update changing things David Wright <deblis@lionunicorn.co.uk> - 2022-01-03 04:00 +0100
              Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-01-03 20:10 +0100
                Re: 8 -> 9 update changing things Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-11 13:20 +0100
                  Re: 8 -> 9 update changing things Greg Wooledge <greg@wooledge.org> - 2022-01-11 14:20 +0100
                    Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-01-11 17:10 +0100
                      Re: 8 -> 9 update changing things "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-11 17:30 +0100
                        Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-01-11 18:30 +0100
                          Re: 8 -> 9 update changing things Dan Ritter <dsr@randomstring.org> - 2022-01-11 18:50 +0100
                            Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-01-11 19:10 +0100
                      Re: 8 -> 9 update changing things Greg Wooledge <greg@wooledge.org> - 2022-01-11 17:30 +0100
                        Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-01-11 18:50 +0100
                          Re: 8 -> 9 update changing things Greg Wooledge <greg@wooledge.org> - 2022-01-11 19:40 +0100
                            Re: 8 -> 9 update changing things Kushal Kumaran <kushal@locationd.net> - 2022-01-12 03:30 +0100
                          Re: 8 -> 9 update changing things "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-11 21:10 +0100
                            Re: 8 -> 9 update changing things "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-01-11 22:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#243857

On Tue, Jan 11, 2022 at 01:15:05PM +0100, Andrei POPESCU wrote:
> On Lu, 03 ian 22, 14:02:05, Roy J. Tellason, Sr. wrote:
> > In the one that was running to start with,  the command line shown to 
> > me in system monitor includes "daemonize=no".  I would guess that to 
> > be the problem,  but why is that in there?

You need to rewind quite a few years of history for a full answer to
this.

> In general it's recommended programs rely on systemd for running in 
> background instead of implementing their own code for that (re-inventing 
> the wheel and all that).
> 
> Of course, some programs (including PulseAudio) predate systemd and/or 
> need to run on systems / platforms where systemd (or something 
> compatible) is not even available, so they will continue to support both 
> methods.

Imagine that you're sitting down at a Unix workstation back in the 1980s
or 1990s.  There's no systemd, no dbus, no CORBA, nothing at all like
that.  You probably login via xdm, and you get an X11 session with a
single xterm and twm as your window manager.  That's it.  That's your
whole session.  Nothing else is running -- just the X server, the window
manager, and a single terminal.

Now, you'd like to run a few more things.  So you focus on the terminal
and you start running some commands:

xclock &
xbiff &
xterm -e top &
xterm &
xterm &

Now you've got some additional terminals with interactive shells in them,
and some programs that give you information.

If you'd like all of these programs to start next time you login, there
will be some kind of dot-file that you can edit, probably ~/.xsession.
You just put those commands in there, and then... whoops, you forgot to
put your window manager!  So, you login remotely, fix the ~/.xsession
file so that it ends with "exec twm" or whatever, and you're good to go.

Do you see how all of the commands that you wanted to run end with "&"
so that they will be placed in the background by the shell?  There's
nothing wrong with that at all, but it will become relevant in a moment.

Next, imagine that you're the system administrator of a Unix workstation
back in the 1980s or 1990s.  You'd like to run some programs at boot
time -- maybe one of those fancy Internet mail transport programs like
sendmail!

After reading manuals for a few hours, you manage to get sendmail installed
and configured, and now that it's time to run it, you put some command
like this into /etc/rc.local:

/usr/lib/sendmail &

And... it works, maybe.  You've applied your knowledge of the shell to
a system administration problem.  Only, maybe it doesn't work.  Maybe
your particular flavor of Unix runs /etc/rc.local with a shell where
background jobs are terminated after the shell exits.

So, if you're on one of those systems, you cobble together a workaround:

csh -cf '/usr/lib/sendmail &'

And this works!  But it's so ugly.

But hey, this idea of programs running automatically when the system boots
is starting to gain some traction.  People are doing it everywhere.
Literally hundreds of Unix sites around the country!

So, at some point, the people who write system software like sendmail
all decided to make the system administrator's life "easier", and they
added options to "daemonize" themselves.  Now the system administrator
wouldn't have to do all that crazy shell stuff.  They can simply write:

/usr/lib/sendmail -bd

And voila.  The sendmail daemon will fork a child process, and then the
parent will terminate.  The abandoned child will be re-parented by the
init daemon (process ID 1).  The abandoned child is the real daemon, and
it will continue running in the background, forever.  Or until it crashes.
But that's a next year problem!

For a decade or two, this became the norm across BSD-like systems.  Newly
written daemons all decided that they should either fork and abandon a
child process by default, or offer an option to do this.  It became the
new fad.  All the cool kids were doing it.

And then the problems started.

Maybe you didn't *want* the same instance of sendmail to run forever.  What
if you edited the configuration file, and wanted to reload the daemon with
the new configs?  How do you do that?

Well, obviously, you sit down at the console, login as root, and use commands
like "ps auxw | grep sendmail" to find the daemon.  Then when you've
found it, you can use a command like "kill -1 2345" to send a signal to
the daemon, telling it to reread the configs.

Of course, finding a running process this way is an art, not a science.
A human system administrator can do it.  It's not all that hard, right?
If Susan is sendiing mail right now, her sendmail process is going to
look different from the daemon that you're trying to locate in the haystack.
You'll be able to tell the difference and identify the correct process.
It just takes a few moments of careful attention and effort.

A computer program can't do that.

So, what happens when your operating system introduces this brand new
shiny "init system" that tries to unify the way daemons are started
and controlled?  We're solidly into the 1990s by now, or maybe the 2000s,
and most systems are using a variant of the "System V init" software with
"rc scripts".

Basically, these things are shell scripts that take a mandatory argument
like "start" or "stop".  The idea is that you (the system administrator)
can write one of these shell scripts and have it either start or stop
the daemon.  Then you drop it in a special directory, and the operating
system will run it with the argument "start" at boot time, and again
with the argument "stop" at shutdown time.  Or you can run it yourself
at any time you like, if you want to restart the daemon.

But... all of the daemons are still using that faddish "-bd" style code
from the 1980s.  How do you write a shell script to stop a daemon that is
really an abandoned child process?  You'd have to find its process ID
somehow.  How are you going to do that?  Your script doesn't have the
brain power of a human being, so it can't sift through the output of "ps".

People who write programs like sendmail came up with an answer to that:
they told the daemon to write its PID into a file in a known location
on the disk.  So in an "rc script" for sendmail, you can put code like
this:

case $1 in
  start) /usr/lib/sendmail -bd ;;
  stop)  kill `cat /var/lib/sendmail.pid` ;;
esac

The idea of the "PID file" became the new norm.

But what happens if sendmail crashes on its own?  Maybe it has a bug!
(In real life, sendmail had so many bugs that it's amazing people used
it for so long.)

If the sendmail daemon that was started at boot time (and wrote its PID
into that PID file) crashes, then the PID is freed for reuse by the
adoptive parent process.  You can't have a bunch of zombies walking around!
So, the PID goes back in the pool, and eventually, some other program
will use it.

Now you've got a PID file that contains the PID of some entirely different
program, which has nothing do with sendmail.  Maybe it's your boss's
window manager!  It could be anything!

This is why PID files are terrible.

But they're necessary!  Because all of the daemons put themselves in
the background!  Because that's such a stylish thing to do!

As it turns out, having daemons put themselves into the background was
in fact a *terrible* idea.  It breaks everything else, and creates an
ecosystem of workarounds.

In the late 1990s and early 2000s, when System V init/rc was running
rampant through the increasingly popular Linux communities, some other
folks realized the issue, and started working on alternative init systems.

If you'd like more details on this, I recommend JDEBP's web site.  You
can start at <http://jdebp.info/FGA/system-5-rc-problems.html>.

In a nutshell, the alternatives to sysvinit all start out with the
premise that a daemon should *not* abandon a child in the background.
The daemon should simply run like a normal program, only terminating
when it's told to do so, or when it encounters a fatal condition.  Then,
the init system can manage it like any normal program.  The init system
will immediately know when it terminates, and can restart it if the
system administrator desires.  Or, if the admin wants to restart it,
the init system knows exactly which process ID to send a signal to.
There's no "stale PID file" problem, because PIDs aren't written to files.
Process IDs are held by the parents.  Everything works so much better.

But... we've still got all of these old system programs like sendmail
that have -bd options.  Or worse, some of them may create and abandon
a child process by default!  How do we deal with this mess?

In some cases, you simply stop using the -bd option, or its equivalent.
In other cases, maybe you have to patch the daemon to offer a new
option which says *don't* create a child process -- just run normally.

That's what you're seeing here with Pulse Audio.

> > In the one that was running to start with,  the command line shown to 
> > me in system monitor includes "daemonize=no".  I would guess that to 
> > be the problem,  but why is that in there?

This is a program whose default behavior was to create a child process,
and an option was added to tell it not to do that.  Since systemd is
one of the new alternative init systems that want normal daemons, it's
using that option to force normal behavior.

Maybe in a few more years, or decades, all of the old "daemonize by
default" programs will have gone away, or will have changed their default
behavior to the more sensible "don't daemonize by default" choice.
Until that happens, you're going to continue to see a chaotic mix of
programs that behave in different ways, with different options to
control them.

Welcome to Unix.

[toc] | [prev] | [next] | [standalone]

#243864

On Tuesday 11 January 2022 08:18:27 am Greg Wooledge wrote:
> On Tue, Jan 11, 2022 at 01:15:05PM +0100, Andrei POPESCU wrote:
> > On Lu, 03 ian 22, 14:02:05, Roy J. Tellason, Sr. wrote:
> > > In the one that was running to start with,  the command line shown to 
> > > me in system monitor includes "daemonize=no".  I would guess that to 
> > > be the problem,  but why is that in there?
> 
> You need to rewind quite a few years of history for a full answer to
> this.

(Much interesting reading snipped for brevity...)

> If you'd like more details on this, I recommend JDEBP's web site.  You
> can start at <http://jdebp.info/FGA/system-5-rc-problems.html>.

Much interesting reading there,  too...
 
(snip)

> In some cases, you simply stop using the -bd option, or its equivalent.
> In other cases, maybe you have to patch the daemon to offer a new
> option which says *don't* create a child process -- just run normally.
> 
> That's what you're seeing here with Pulse Audio.

What I'm not clear on at this point is why the instance of it that's started by the system doesn't seem to work, while the one that I start manually at some point later on does.
 
(snip)
 
> Welcome to Unix.

I've run nothing but linux since 1999,  starting with Slackware 4.0,  and upgrading to newer versions from time to time.  Early on I had no sound card in the machine that I was using,  and did not implement a GUI to start with either.  Adding those manually was a real interesting exercise,  one that I'm happy to not have to repeat with newer hardware and software.  Debian came a little later,  only in the past few years,  and in many respects I'm still getting to know it.

I still would like to know why the one instance of pulseaudio works and the other one doesn't.  And why some things seem to be included in what gets started up that I don't see any need for -- things like exim,  bluetooth stuff (there is _no_ bluetooth hardware on this machine),  and some other stuff.  Any recommendations as to where I might poke at this to clean things up would be appreciated also.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#243868

On Tue, Jan 11, 2022 at 11:03:55AM -0500, Roy J. Tellason, Sr. wrote:
> On Tuesday 11 January 2022 08:18:27 am Greg Wooledge wrote:
> > On Tue, Jan 11, 2022 at 01:15:05PM +0100, Andrei POPESCU wrote:
> > > On Lu, 03 ian 22, 14:02:05, Roy J. Tellason, Sr. wrote:
> 
> What I'm not clear on at this point is why the instance of it that's started by the system doesn't seem to work, while the one that I start manually at some point later on does.
>  
> (snip)
>  
> > Welcome to Unix.
> 
> I've run nothing but linux since 1999,  starting with Slackware 4.0,  and upgrading to newer versions from time to time.  Early on I had no sound card in the machine that I was using,  and did not implement a GUI to start with either.  Adding those manually was a real interesting exercise,  one that I'm happy to not have to repeat with newer hardware and software.  Debian came a little later,  only in the past few years,  and in many respects I'm still getting to know it.
> 
> I still would like to know why the one instance of pulseaudio works and the other one doesn't.  And why some things seem to be included in what gets started up that I don't see any need for -- things like exim,  bluetooth stuff (there is _no_ bluetooth hardware on this machine),  and some other stuff.  Any recommendations as to where I might poke at this to clean things up would be appreciated also.
> 

Exim: because "something" needs to deliver mail locally for cron jobs etc. 
Maybe not the best - others remove exim and install another MTA - but its
a start.

"Remove stuff" - start with a bare install of Debian text mode - standard
packages only - then remove the stuff you want to. Don't be surprised if
there may be a metapackage or two which appears to remove more than you
think.

The idea of a distribution is to make it relatively easy to install a 
subset of common packages that people want: that doesn't mean that everybody
gets exactly what they want first time, but Debian's fairly flexible to 
allow you to change elements.

If you think that the distribution is entirely wrong - that's a different
matter, I think. If you started with Slackware 4.0 and that was your first
Linux, then you may well find Debian different enough that it's bothersome
because it "isn't Slackware" - but there's any amount of individual 
customisation you can do.

All the very best, as ever,

Andy Cater

> -- 
> Member of the toughest, meanest, deadliest, most unrelenting -- and
> ablest -- form of life in this section of space,  a critter that can
> be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
> -
> Information is more dangerous than cannon to a society ruled by lies. --James 
> M Dakin
> 

[toc] | [prev] | [next] | [standalone]

#243873

On Tuesday 11 January 2022 11:20:22 am Andrew M.A. Cater wrote:
> > I've run nothing but linux since 1999,  starting with Slackware 4.0,  and upgrading to newer versions from time to time.  Early on I had no sound card in the machine that I was using,  and did not implement a GUI to start with either.  Adding those manually was a real interesting exercise,  one that I'm happy to not have to repeat with newer hardware and software.  Debian came a little later,  only in the past few years,  and in many respects I'm still getting to know it.
> > 
> > I still would like to know why the one instance of pulseaudio works and the other one doesn't.  And why some things seem to be included in what gets started up that I don't see any need for -- things like exim,  bluetooth stuff (there is _no_ bluetooth hardware on this machine),  and some other stuff.  Any recommendations as to where I might poke at this to clean things up would be appreciated also.
> > 
> 
> Exim: because "something" needs to deliver mail locally for cron jobs etc. 
> Maybe not the best - others remove exim and install another MTA - but its
> a start.

I don't see the need for this.  Deliver mail locally where?  And to who?

> "Remove stuff" - start with a bare install of Debian text mode - standard
> packages only - then remove the stuff you want to. Don't be surprised if
> there may be a metapackage or two which appears to remove more than you
> think.

I've been surprised at that more than once already.  I suggest to synaptic that I might want to remove something,  and it comes back with a *huge* list of stuff that's going to be removed,  if I do.  I can't quite make sense out of that.
 
> The idea of a distribution is to make it relatively easy to install a 
> subset of common packages that people want: that doesn't mean that everybody
> gets exactly what they want first time, but Debian's fairly flexible to 
> allow you to change elements.

Still working on that...
 
> If you think that the distribution is entirely wrong - that's a different
> matter, I think. 

Not necessarily wrong,  but definitely different.  I like the management of dependencies,  one of the reasons I chose it.  Some of the other stuff I'm not so sure about,  though.

> If you started with Slackware 4.0 and that was your first 
> Linux, then you may well find Debian different enough that it's bothersome
> because it "isn't Slackware" - but there's any amount of individual 
> customisation you can do.

Oh,  it's different all right.  Bothersome?  Sometimes.  I've been dealing with it for some years now,  and haven't given up on it yet.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#243874

Roy J. Tellason, Sr. wrote: 
> On Tuesday 11 January 2022 11:20:22 am Andrew M.A. Cater wrote:
> > > I still would like to know why the one instance of pulseaudio works and the other one doesn't.  And why some things seem to be included in what gets started up that I don't see any need for -- things like exim,  bluetooth stuff (there is _no_ bluetooth hardware on this machine),  and some other stuff.  Any recommendations as to where I might poke at this to clean things up would be appreciated also.
> > > 
> > 
> > Exim: because "something" needs to deliver mail locally for cron jobs etc. 
> > Maybe not the best - others remove exim and install another MTA - but its
> > a start.
> 
> I don't see the need for this.  Deliver mail locally where?  And to who?

To you.

The primary method of telling you, the systems administrator,
that something went wrong when you weren't looking at it, is
mail. That tells you to go look at the logs.

If you don't want exim, nullmailer or ssmtp will send all email to some
smarter machine. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#243877

On Tuesday 11 January 2022 12:27:39 pm Dan Ritter wrote:
> Roy J. Tellason, Sr. wrote: 
> > On Tuesday 11 January 2022 11:20:22 am Andrew M.A. Cater wrote:
> > > > I still would like to know why the one instance of pulseaudio works and the other one doesn't.  And why some things seem to be included in what gets started up that I don't see any need for -- things like exim,  bluetooth stuff (there is _no_ bluetooth hardware on this machine),  and some other stuff.  Any recommendations as to where I might poke at this to clean things up would be appreciated also.
> > > > 
> > > 
> > > Exim: because "something" needs to deliver mail locally for cron jobs etc. 
> > > Maybe not the best - others remove exim and install another MTA - but its
> > > a start.
> > 
> > I don't see the need for this.  Deliver mail locally where?  And to who?
> 
> To you.
> 
> The primary method of telling you, the systems administrator,
> that something went wrong when you weren't looking at it, is
> mail. That tells you to go look at the logs.

Right.  I don't see any mail that seems to be pointed at root,  though I do see a /var/mail/roy file,  I should probably see if there's some way that I can get kmail in the virtualbox to import this stuff.  Suggestions as to how to do that would be welcomed.
 
> If you don't want exim, nullmailer or ssmtp will send all email to some
> smarter machine. 

It doesn't seem terribly useful.  The latest ones in there are referring to /var/log/exim4/paniclog as having a non-zero length,  and quotes some lines from it.  Which refer to something that didn't go right in September of 2017!

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#243869

On Tue, Jan 11, 2022 at 11:03:55AM -0500, Roy J. Tellason, Sr. wrote:
> What I'm not clear on at this point is why the instance of it that's started by the system doesn't seem to work, while the one that I start manually at some point later on does.

Pulse Audio is still quite mysterious to me as well.  In fact, I have
the exact opposite experience: if I start Pulse Audio from my .xsession
file (the way I expected it should be done), that one always fails to
work.  Consistently.  100%, every time.  Killing it and restarting it
always gave a working instance.  Again, 100%, every time.

But if I let it start itself automatically on demand, then it works
straight out of the gate with no issues.  So far, anyway!

This is with Debian 11 (and, I think, 'twas the same on version 10
as well), starting X with "startx" from a console, with fvwm and no
desktop environment.

The symptom of the non-working Pulse Audio was a complete lack of
response to everything.  Running "pavucontrol" would give me some
message about not being able to contact the daemon, but I could see it
running in "ps".  Kill, restart, pavucontrol again, and it was all
happy.

Sadly, I don't know enough to offer any helpful advice.  All I can give
you are some questions that you might ask yourself to try to gather
more information about the issue:

What version of Debian?
How do you log in?
How do you start your graphical session, if you use one?
Which graphical session, if any, are you using?
How does Pulse Audio get started (if you know)?  What do you see in "ps"?
What are the exact symptoms?
Are there any error messages?  If so, what do they say, and how do you
see them?
What steps do you perform when you restart Pulse Audio?
What does "ps" show after that?

The answers to those might help someone else help you.  We can hope, anyway.

[toc] | [prev] | [next] | [standalone]

#243875

On Tuesday 11 January 2022 11:24:27 am Greg Wooledge wrote:
> On Tue, Jan 11, 2022 at 11:03:55AM -0500, Roy J. Tellason, Sr. wrote:
> > What I'm not clear on at this point is why the instance of it that's started by the system doesn't seem to work, while the one that I start manually at some point later on does.
> 
> Pulse Audio is still quite mysterious to me as well.  In fact, I have
> the exact opposite experience: if I start Pulse Audio from my .xsession
> file (the way I expected it should be done), that one always fails to
> work.  Consistently.  100%, every time.  Killing it and restarting it
> always gave a working instance.  Again, 100%, every time.

What's puzzling to me is why it worked okay before my most recent upgrade,  and doesn't work now,  until I fire up another instance of it.
 
> But if I let it start itself automatically on demand, then it works
> straight out of the gate with no issues.  So far, anyway!

How does that "on demand" thing work?
 
> This is with Debian 11 (and, I think, 'twas the same on version 10
> as well), starting X with "startx" from a console, with fvwm and no
> desktop environment.

This was 8,  moved to 9,  and I will (eventually) progress all the way to 11.  But not just yet.
 
> The symptom of the non-working Pulse Audio was a complete lack of
> response to everything.  Running "pavucontrol" would give me some
> message about not being able to contact the daemon, but I could see it
> running in "ps".  Kill, restart, pavucontrol again, and it was all
> happy.

I don't do anything much under debian that needs to have sound working,  so I hadn't noticed a problem until the virtualboxed Slackware didn't have sound any more,  and there are a few things I do in there where I *do* want sound working.  Firing up another instance of it at somebody's suggestion took care of that problem,  though I did have to reboot the virtualbox in order for it to see it.
 
> Sadly, I don't know enough to offer any helpful advice.  All I can give
> you are some questions that you might ask yourself to try to gather
> more information about the issue:
> 
> What version of Debian?

According to /etc/debian_version 9.3...

> How do you log in?

I often log in as root.

> How do you start your graphical session, if you use one?

The initial login screen is graphical,  from which I can select different desktop environments.  At the moment (and for quite a long time) I'm running Xfce.

> Which graphical session, if any, are you using?

I'm not sure I understand the question here.

> How does Pulse Audio get started (if you know)?  What do you see in "ps"?

Looking at it in System Monitor,  I see two instances of it.  One has the user name "Debian-gdm" and when I mouse over it shows "parent = systemd".  This is the one that the system starts up.  The other one is the one that I started from a command line,  which is otherwise the same.  Right-clicking on either of these and selecting "show detailed memory information" shows very different results for the two of them,  more memory being used for the second instance.

> What are the exact symptoms?

I'm not seeing any symptoms on the debian side of things,  but haven't tried to do much with sound there.  The sound _does_ work when,  ferinstance,  I view a video on youtube or similar.  When booting the virtualbox,  I'd get an error message from Slackware that it wasn't able to connect to the pulseaudio daemon and was going to use the "null" audio device instead,  meaning that sound didn't work in there at all.  After invoking pulseaudio in a terminal on the debian side of things and rebooting the virtual box sound in there works fine.

> Are there any error messages?  If so, what do they say, and how do you
> see them?

See the above paragraph about during the boot process of the virtualbox.

> What steps do you perform when you restart Pulse Audio?

I haven't tried restarting it,  just firing it up as someone suggested,  using pulseaudio --start in a terminal window.

> What does "ps" show after that?

Not using ps here,  for the most part.  I'm looking at stuff in System Monitor.
 
> The answers to those might help someone else help you.  We can hope, anyway.

I'll get a handle on this sooner or later...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#243880

On Tue, Jan 11, 2022 at 12:42:11PM -0500, Roy J. Tellason, Sr. wrote:
> On Tuesday 11 January 2022 11:24:27 am Greg Wooledge wrote:
> > But if I let it start itself automatically on demand, then it works
> > straight out of the gate with no issues.  So far, anyway!
> 
> How does that "on demand" thing work?

I have no idea, really.  I can describe what it looks like, though.

I've commented out everything having to do with pulseaudio from my
.xsession file, so nothing that I do when I login or when I start X
touches audio.

When I open an application that uses audio, I get one of these guys:

unicorn:~$ ps auxw | grep pulse
greg         846  6.5  0.2 1682936 28676 ?       S<sl Jan05 585:10 /usr/bin/pulseaudio --daemonize=no --log-target=journal

unicorn:~$ systemctl --user status pulseaudio
● pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor >
     Active: active (running) since Wed 2022-01-05 08:48:08 EST; 6 days ago
TriggeredBy: ● pulseaudio.socket
   Main PID: 846 (pulseaudio)
      Tasks: 3 (limit: 14199)
     Memory: 25.9M
        CPU: 9h 45min 13.290s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pulseaudio>
             └─846 /usr/bin/pulseaudio --daemonize=no --log-target=journal

Jan 05 08:48:05 unicorn systemd[825]: Starting Sound Service...
Jan 05 08:48:08 unicorn pulseaudio[846]: Failed to open cookie file '/home/greg>
Jan 05 08:48:08 unicorn pulseaudio[846]: Failed to load authentication key '/ho>
Jan 05 08:48:08 unicorn systemd[825]: Started Sound Service.

It just chews up the CPU, doesn't it?  I guess the Pulse guys can afford
to be lazy about keeping the thing reined in, given how powerful current
PCs are.  Hell, even between those two commands, it used up 3 seconds of
CPU, and I'm not even playing any audio right now!

[toc] | [prev] | [next] | [standalone]

#243901

On Tue, Jan 11 2022 at 01:37:22 PM, Greg Wooledge <greg@wooledge.org> wrote:
> On Tue, Jan 11, 2022 at 12:42:11PM -0500, Roy J. Tellason, Sr. wrote:
>> On Tuesday 11 January 2022 11:24:27 am Greg Wooledge wrote:
>> > But if I let it start itself automatically on demand, then it works
>> > straight out of the gate with no issues.  So far, anyway!
>> 
>> How does that "on demand" thing work?
>
> I have no idea, really.  I can describe what it looks like, though.
>
> I've commented out everything having to do with pulseaudio from my
> .xsession file, so nothing that I do when I login or when I start X
> touches audio.
>
> When I open an application that uses audio, I get one of these guys:
>
> unicorn:~$ ps auxw | grep pulse
> greg         846  6.5  0.2 1682936 28676 ?       S<sl Jan05 585:10 /usr/bin/pulseaudio --daemonize=no --log-target=journal
>
> unicorn:~$ systemctl --user status pulseaudio
> ● pulseaudio.service - Sound Service
>      Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor >
>      Active: active (running) since Wed 2022-01-05 08:48:08 EST; 6 days ago
> TriggeredBy: ● pulseaudio.socket

                 ^^^^^^^^^^^^^^^^^

It uses the socket-activation support provided by systemd.  The
pulseaudio.socket unit configures systemd to listen on
/run/user/<uid>/pulse/native for incoming pulseaudio client.  When one
comes along, systemd will start the corresponding pulseaudio.service.


>    Main PID: 846 (pulseaudio)
>       Tasks: 3 (limit: 14199)
>      Memory: 25.9M
>         CPU: 9h 45min 13.290s
>      CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pulseaudio>
>              └─846 /usr/bin/pulseaudio --daemonize=no --log-target=journal
>
> Jan 05 08:48:05 unicorn systemd[825]: Starting Sound Service...
> Jan 05 08:48:08 unicorn pulseaudio[846]: Failed to open cookie file '/home/greg>
> Jan 05 08:48:08 unicorn pulseaudio[846]: Failed to load authentication key '/ho>
> Jan 05 08:48:08 unicorn systemd[825]: Started Sound Service.
>
> It just chews up the CPU, doesn't it?  I guess the Pulse guys can afford
> to be lazy about keeping the thing reined in, given how powerful current
> PCs are.  Hell, even between those two commands, it used up 3 seconds of
> CPU, and I'm not even playing any audio right now!

[toc] | [prev] | [next] | [standalone]

#243887

On Tue, Jan 11, 2022 at 12:42:11PM -0500, Roy J. Tellason, Sr. wrote:
> On Tuesday 11 January 2022 11:24:27 am Greg Wooledge wrote:
> > On Tue, Jan 11, 2022 at 11:03:55AM -0500, Roy J. Tellason, Sr. wrote:
> 
> I don't do anything much under debian that needs to have sound working,  so I hadn't noticed a problem until the virtualboxed Slackware didn't have sound any more,  and there are a few things I do in there where I *do* want sound working.  Firing up another instance of it at somebody's suggestion took care of that problem,  though I did have to reboot the virtualbox in order for it to see it.
>  
> > Sadly, I don't know enough to offer any helpful advice.  All I can give
> > you are some questions that you might ask yourself to try to gather
> > more information about the issue:
> > 
> > What version of Debian?
> 
> According to /etc/debian_version 9.3...
> 

I hope that's 9.13 - so updated as at 2020-07-18. if not - please, before you
do anything else, please apt-get update ; apt-get dist-upgrade (or equivalent)
to bring you to the latest version of 9.

Reboot: then look at apt autoremove to remove old programs.

If you're going to do this, at least do the right thing by bringing yourself
up to the latest correct version of whatever you're moving from.
It is _not_ a good idea to just pick a random point release of Debian and
sue that as the basis for a Debian machine. If you install from old media,
if you are network connected, then the the install process will normally
update you to the latest version of that release.

> > The answers to those might help someone else help you.  We can hope, anyway.
> 
> I'll get a handle on this sooner or later...
> 
> -- 

All the very best, as ever,

Andy Cater

> Member of the toughest, meanest, deadliest, most unrelenting -- and
> ablest -- form of life in this section of space,  a critter that can
> be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
> -
> Information is more dangerous than cannon to a society ruled by lies. --James 
> M Dakin
> 

[toc] | [prev] | [next] | [standalone]

#243891

On Tuesday 11 January 2022 02:52:10 pm Andrew M.A. Cater wrote:
> > > What version of Debian?
> > 
> > According to /etc/debian_version 9.3...
> > 
> 
> I hope that's 9.13 - so updated as at 2020-07-18. 

You're correct.  I have a pair of glasses here that are "for the computer" and in general I am avoiding wearing them unless I really feel like I have to...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web