Help with ALSA setup
Hi all, I may have made a mistake in choosing ALSA sound instead of OSS on my woody box... I just installed the first thing that said "sound drivers" in dselect and I heard later that ALSA has a reputation for being, er, non-trivial to get working... But hey: in for a penny, in for a pound... right? So here goes: I installed alsa-base 0.9+0beta12, alsa-modules 0.9+0beta10, and alsa-utils 0.5.10-1... This required me to upgrade to kernel 2.4.16-686. Done (and verified with uname that that is the currently booted kernel). I established that my card (SBLive! 5.1) is called emu10k1, and told ALSA to use that module... lsmod has this to say: snd-card-emu10k11952 0 (unused) snd-emu10k147200 0 [snd-card-emu10k1] snd-pcm46176 0 [snd-emu10k1] snd-timer 9056 0 [snd-pcm] snd-rawmidi11456 0 [snd-emu10k1] snd-hwdep 3456 0 [snd-emu10k1] snd-util-mem1184 0 [snd-emu10k1] snd-ac97-codec 22848 0 [snd-emu10k1] snd-seq-device 3744 0 [snd-card-emu10k1 snd-rawmidi] snd23336 0 [snd-card-emu10k1 snd-emu10k1 snd-pcm snd-timer snd-rawmidi snd-hwdep snd-util-mem snd-ac97-codec snd-seq-device] soundcore 3556 2 [snd] (Including only the results that look (to my untrained eye) relevant.) Now when I run alsaconf, it doesn't detect my card; so I choose SB Live off the list, hit okay, hit enter a few times to accept the identifier CARD_0, the max. dac 128, max. adc 64... Then it says: OK, 1 card(s) configured. will prepare the card for playing now. Now I'll run '/etc/init.d/alsa start', then I'll use 'amixer'... Then we get this response: Loading driver: Starting ALSA sound driver (version 0.9.0beta10): emu10k1. Restoring ALSA mixer settings...done. Setting the PCM volume to 100% and the Master output volume to 50% amixer: Mixer attach default error: No such file or directory Could not initialize the mixer, the card was probably not detected correctly. And every time gdm starts, it gives me a sound-related error, umm... "could not open /dev/pcm" (I *think* that's what it says) And, (obviously?) any sound-related apps don't make any sound. So... can anybody tell me what I missed? or what I should try next? Many thanks, Chris msg29025/pgp0.pgp Description: PGP signature
Re: Mutt Save-Hook Help
On Mon, Feb 10, 2003 at 07:28:09AM -0800, Curtis Spencer wrote: > I am trying to get mutt to save all messages from the debian user list > in a file called debian. I don't fully understand the save-hook functionality. > my muttrc looks like this, yet everything still gets saved to the inbox. Personally, I have Exim deliver the messages for this list directly to a separate mailbox in the first place, using filtering in a .forward file... like so: if $header_X-Mailing-List: contains "[EMAIL PROTECTED]" then seen save $home/Mail/debian_user endif And I don't know whether it's necessary to explicitly define the "else" condition, but I did... like so: if not delivered then seen save "$home/Mail/inbox" endif Note that I'm a complete newbie myself, so I don't know if this is the *right* way to do this, I just know that it seems to be working for me. And, obviously, if you're not using Exim as your MTA, the method will presumably vary. msg29997/pgp0.pgp Description: PGP signature
ALSA sound setup
Hi all. I'm a bit stumped in my efforts to get ALSA sound working... and I've been unable to find much in the way of docs for ALSA (No "man alsa", /usr/doc/alsa* adds up to a couple examples, several copies of the changelog, and some copyright info... and alsa-project.org seems to have little or nothing beyond the "sound-card matrix"). Any help and/or pointers to (helpful) docs would be greatly appreciated... So here's the problem: --The short version-- I've installed alsa v 0.9 to drive my Creative Labs SBLive! 5.1, and it seems to think it's working: miguel# /etc/init.d/alsa start Starting ALSA sound driver (version 0.9.0beta10): emu10k1. Restoring ALSA mixer settings...done. miguel# But I have no sound. When I run alsaconf it exits with an error saying: amixer: Mixer attach default error: No such file or directory Could not initialize the mixer, the card was probably not detected correctly. miguel# --The long version-- Please forgive me if I include irrelevant stuff or leave out key info... I'm still rather a newbie. So here's everthing that I thought might be relevant... I installed alsa-base 0.9+0beta12, alsa-modules 0.9+0beta10, and alsa-utils 0.5.10-1... This required me to upgrade to kernel 2.4.16-686. Done (and verified with uname that that is the currently booted kernel). I established that my card (SBLive! 5.1) is called emu10k1, and told ALSA to use that module... lsmod has this to say: snd-card-emu10k11952 0 (unused) snd-emu10k147200 0 [snd-card-emu10k1] snd-pcm46176 0 [snd-emu10k1] snd-timer 9056 0 [snd-pcm] snd-rawmidi11456 0 [snd-emu10k1] snd-hwdep 3456 0 [snd-emu10k1] snd-util-mem1184 0 [snd-emu10k1] snd-ac97-codec 22848 0 [snd-emu10k1] snd-seq-device 3744 0 [snd-card-emu10k1 snd-rawmidi] snd23336 0 [snd-card-emu10k1 snd-emu10k1 snd-pcm snd-timer snd-rawmidi snd-hwdep snd-util-mem snd-ac97-codec snd-seq-device] soundcore 3556 2 [snd] (Including only the results that look (to my untrained eye) relevant.) lspci says this: 00:12.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) 00:12.1 Input device controller: Creative Labs SB Live! (rev 07) (again showing only the obviously relevant entries) Now when I run alsaconf, it doesn't detect my card; so I choose SB Live off the list, hit okay, hit enter a few times to accept the identifier CARD_0, the max. dac 128, max. adc 64... Then it says: OK, 1 card(s) configured. will prepare the card for playing now. Now I'll run '/etc/init.d/alsa start', then I'll use 'amixer'... Then we get this response: Loading driver: Starting ALSA sound driver (version 0.9.0beta10): emu10k1. Restoring ALSA mixer settings...done. Setting the PCM volume to 100% and the Master output volume to 50% amixer: Mixer attach default error: No such file or directory Could not initialize the mixer, the card was probably not detected correctly. And every time I log in to Gnome, or launch Gnome's mixer applet, I get a popup error saying "couldn't open mixer device /dev/mixer". When I try amixer as root or regular user, I get more of "Mixer attach default error: No such file or directory". Now, I *know* the card is good because it works (beautifully) under WinXP (Dual-boot machine... I haven't made a clean break so far)... So... please somebody give me a nudge in the right direction. Many thanks, Chris msg30604/pgp0.pgp Description: PGP signature
Re: ALSA sound setup
On Thu, Feb 13, 2003 at 04:34:01PM -0600, Jamin W. Collins wrote: > On Thu, Feb 13, 2003 at 04:04:49PM -0500, Chris Mitchell wrote: > > Hi all. > > I'm a bit stumped in my efforts to get ALSA sound working... (snip) > > lsmod has this to say: (snip) > This looks good, but it appears that the OSS compatibility modules are > not loaded. These can be enabled by editing /etc/alsa/alsa-base.conf: >startosslayer=true Odd. That line is already there, and uncommented. (Has been for more than one reboot and some alsa stop/starts, too!) Do I need to select them in modconf too? (I *think* that my instructions said that in modconf I should install only soundcore and ALSA... *not* any sound drivers... what about "sound"? (it's currently *not* installed)). > The following link provides instructions on how to how to configure the > alsa modules for this card and Debian: > > >http://www.alsa-project.org/alsa-doc/doc-php/template.php3?company=Creative+Labs&card=Soundblaster+Live+Value&chip=EMU10K1&module=emu10k1#modp Hmm... *PokePokeRummage* The relevant bit of my modules.conf sez: # --- BEGIN: Generated by ALSACONF, do not edit. --- # --- ALSACONF verion 0.4.3b --- alias char-major-116 snd alias snd-card-0 snd-card-emu10k1 alias char-major-14 soundcore alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss options snd snd_major=116 snd_cards_limit=1 snd_device_mode=0660 snd_device_gid=29 snd_device_uid=0 options snd-card-emu10k1 snd_index=0 snd_id=CARD_0 snd_dac_frame_size=128 snd_adc_frame_size=64 # --- END: Generated by ALSACONF, do not edit. --- which seems to be identical to what's listed on that page... with the addition of the "options" stuff at the end. The rest of what's on that page looks to be "how to install with 'make'" (which, er, appears not to apply to my case) and how to tweak the .asoundrc file, which it says is optional (so I'll worry about that after basic functionality is achieved)... > Are you by chance using DevFS? Does /dev/mixer exist? What are the > permissions on it? DevFS? Not that I'm aware of :) (What's a DevFS?) My system is pretty close to straight-outtta-the-box 3.0r1 (I guess that's 'woody'). And yep, /dev/mixer seems to exist: lrwxrwxrwx1 root root 11 Jan 26 15:48 mixer -> /dev/mixer0 crw-rw1 root audio 14, 0 Jan 26 15:48 mixer0 Still pokin' away at it (albeit with limited understanding). I'm starting to suffer withdrawal from my favourite webcast station... :-/ Thanks, Chris msg30625/pgp0.pgp Description: PGP signature
Re: ALSA sound setup
On Fri, Feb 14, 2003 at 02:11:04PM +0200, Mohammed Sameer wrote: > Once upon a time Chris Mitchell wrote @ Thu, 13 Feb 2003 18:35:24 -0500 > > > And yep, /dev/mixer seems to exist: > > lrwxrwxrwx1 root root 11 Jan 26 15:48 mixer -> /dev/mixer0 > > crw-rw1 root audio 14, 0 Jan 26 15:48 mixer0 > > try running > /usr/share/doc/alsa-base/examples/snddevices > as root ? Okay, tried that... Doesn't appear to have made a difference. I stopped alsa, ran that script, produced a bunch of happy-looking output: miguel# /usr/share/doc/alsa-base/examples/snddevices Creating /dev/mixer?... done Creating /dev/sequencer... done Creating /dev/midi?... done Creating /dev/dsp?... done Creating /dev/audio?... done Creating /dev/sndstat... done Creating /dev/music... done Creating /dev/dmmidi?... done Creating /dev/dmfm?... done Creating /dev/amixer?... done Creating /dev/adsp?... done Creating /dev/amidi?... done Creating /dev/admmidi?... done create symbolic link `/dev/mixer' to `/dev/mixer0' create symbolic link `/dev/midi' to `/dev/midi0' create symbolic link `/dev/dsp' to `/dev/dsp0' create symbolic link `/dev/audio' to `/dev/audio0' create symbolic link `/dev/sequencer2' to `/dev/music' create symbolic link `/dev/adsp' to `/dev/adsp0' create symbolic link `/dev/amidi' to `/dev/amidi0' ALSA dynamic sound device filesystem create symbolic link `/dev/snd' to `/proc/asound/dev' ALSA loader devices Creating /dev/aload?... done Creating /dev/aloadSEQ... done Started alsa back up - which still *looks* like it's happy miguel# /etc/init.d/alsa start Starting ALSA sound driver (version 0.9.0beta10): (card-emu10k1) But then I still have the same problem: miguel# amixer amixer: Mixer attach default error: No such file or directory miguel# (BTW, I keep posting a fairly verbose amount of detail in the hopes that it'll be informative. If I'm just clogging my messages with *unnecessary* detail, please do let me know.) I've also been poking at the sound HOWTO here: http://www.djcj.org/LAU/guide/Sound-HOWTO-4.html#ss4.4 Which I realize dates from '99 and is not ALSA-specific... but I thought it might be of some help. One thing it said is to try "cat /dev/sndstat", so I did. That got me the response "no such device" which, according to the HOWTO, "means that sound driver is not loaded or linked into kernel." Um. Is this true? applicable in my case? any help? Thanks for the suggestions... Keep 'em coming! -Chris msg30737/pgp0.pgp Description: PGP signature
Re: ALSA sound setup
On Fri, Feb 14, 2003 at 10:43:25AM -0600, Larry Holish wrote: > On Thu, Feb 13, 2003 at 06:35:24PM -0500, Chris Mitchell wrote: > > > > I'm a bit stumped in my efforts to get ALSA sound working... > > (snip) > > Hmm... *PokePokeRummage* > > The relevant bit of my modules.conf sez: > > # --- ALSACONF verion 0.4.3b --- > > alias char-major-116 snd > > alias snd-card-0 snd-card-emu10k1 > > options snd-card-emu10k1 snd_index=0 snd_id=CARD_0 > > snd_dac_frame_size=128 snd_adc_frame_size=64 > > # --- END: Generated by ALSACONF, do not edit. --- > > > > which seems to be identical to what's listed on that page... with the > > addition of the "options" stuff at the end. > > I think you should be using 'snd-emu10k1', rather than > 'snd-card-emu10k1' here. See the note at the top of > /usr/share/doc/alsa-base/README.Debian. Hmm... My version of that document doesn't mention that, but it does sound familiar. Anyway, I tried it. Stopped alsa, edited /etc/alsa/modutils/0.9, replaced both occurrences (one alias and one in options), ran update-modules, checked the change had in fact taken effect in modules.conf, started alsa... no change. I wouldn't need to run that snddevices script again or anything before it'll take effect, would I? Thanks -Chris msg30846/pgp0.pgp Description: PGP signature
Re: ALSA sound setup
On Fri, Feb 14, 2003 at 10:09:39PM -0500, Chris Mitchell wrote: > On Fri, Feb 14, 2003 at 10:43:25AM -0600, Larry Holish wrote: > > I think you should be using 'snd-emu10k1', rather than > > 'snd-card-emu10k1' here. See the note at the top of > > /usr/share/doc/alsa-base/README.Debian. > > Hmm... My version of that document doesn't mention that, but it does > sound familiar. Anyway, I tried it. Stopped alsa, edited > /etc/alsa/modutils/0.9, replaced both occurrences (one alias and one in > options), ran update-modules, checked the change had in fact taken effect > in modules.conf, started alsa... no change. I wouldn't need to run that > snddevices script again or anything before it'll take effect, would I? Okay, now this is odd. After your changes, lsmod showed that all of the alsa sound-related modules were *gone*. So I changed it back, updated everything, and got a "no alsa driver installed" error. So I ran alsaconf *again*. And got a new error from it: miguel# /etc/init.d/alsa start Starting ALSA sound driver (version 0.9.0beta10):modprobe: Invalid line 90 in /etc/modules.conf snd_adc_frame_size failed. modprobe: Invalid line 90 in /etc/modules.conf snd_adc_frame_size miguel# Anybody know what an adc frame size is and where I can find out what value goes there for my card? (I googled creativelabs for it and got nothing)... Thanks -Chris msg30853/pgp0.pgp Description: PGP signature
Re: Simple and secure blogging software for nginx
On Thu, 10 Mar 2022 22:39:34 +0100 Christian Britz wrote: > Sure, I think I was not precise in my posting. I am willing to add > something dynamic, and I was not sure if Apache and nginx support the > same toolkits. > > You and others brought in several static content generators, I will > consider that option too. I believe Apache and nginx both have fairly robust support for popular server-side languages like PHP, so many toolkits will work happily on top of either one. That said, you did mention "as secure as possible" in your initial request, and obviously no other option comes anywhere near static html pages in terms of security. Count me as another voice in favour of a static site generator. In particular, I've been playing around with Hugo, which won me over largely by virtue of using Markdown as its input format. With all respect to LaTeX (sorry Russell!), it's a staggeringly complex language with a steep learning curve. If you want a markup language that supports every typographical feature ever invented, you can't beat LaTeX. For basic web content with links, emphasis, and the occasional bulleted list, Markdown is enough tool for the job, and has the advantages of simplicity and vastly greater human-readability. I don't know about you, but I don't need a 747 to get to the corner store. Site generators like Hugo automatically generate nav menus, TOCs, and similar, so you get a lot of the convenience features of a blogging platform... just without the platform. If you use git, you can make a relatively uncomplicated, entirely self-hosted deploy pipeline that updates the site automatically whenever you make a commit to the website's git repo, as shown here: https://www.digitalocean.com/community/tutorials/how-to-deploy-a-hugo-site-to-production-with-git-hooks-on-ubuntu-14-04 And since the content is all plain Markdown files stored in a sensible directory structure on disk, it's very portable in case you want to move to some other platform later. There is definitely a bit of a learning curve with Hugo, though if you start with a pre-built "theme", it's not overly hard to get a site up and running now and delve into all the customizable details later. Cheers! -Chris
Re: recommend music player?
On Wed, 16 Mar 2022 19:41:58 -0400 Dan Ritter wrote: > kaye n wrote: > > Hello Friends! > > > > I am currently using Debian GNU/Linux 11 (bullseye) > > > > Can anyone recommend a good music player with an equalizer where I > > can choose Pop, Rock, etc. > > > I recommend that you separate the two. > > For equalization, look to your sound subsystem. If that's > pulseaudio, install pulseaudio-equalizer and use the qpaeq > interface. > > If that's pipewire, stable doesn't have a good equalizer yet but > pulseaudio-equalizer may work and you can easily compile > https://github.com/Audio4Linux/JDSP4Linux ...with projectm-pulseaudio thrown in for fun! (Or projectm-jack is an option if you're on pipewire.) As for the music player itself, I use Quod Libet. The UI takes a bit of getting used to, but it's remarkably powerful and flexible. If you're the kind of nerd who takes pride in their meticulously tagged music collection, it might be worth a look. Cheers! -Chris
Re: simple talking clock / reminder for when monitor is off and it is dark
On Sun, 20 Mar 2022 23:03:52 -0700 Samuel Wales wrote: > i have to have all lights and monitors off at night. but i have to > know the time so i can take medicine. > > i use slock and turn off monitor with ddccontrol. this might turn off > mouse and keyboard; i wouild have to check. > > i want debian to tell me the time at certain times. for example > tonight i have to take medicine at 2:40 am. > > here are ideas: > > - tell me time when i right click [kb much less accessible] > - tell me at a prespecified time like 2.40 am > - tell me the following hours: midnight, 1 am, 2am > > any would be ok i think. There are a number of ways you could approach this, depending largely on whether you want the simplest way to get a reminder at one specific time vs a flexible talking reminder system. Personally, I would use a custom systemd timer unit for this. Systemd is already running most of your system, and it offers a scheduling syntax that is (AFAIK) more flexible than cron's, and (IMHO) much easier to read. For example "Every day, once an hour, on the hour, but only between midnight and 07:00 (inclusive)" would be: OnCalendar=00..07:00 The timer unit in turn triggers a service unit, which can run a command such as `aplay /home/sam/medicine.wav` like Dan's example, if you want a single-purpose pre-recorded message. Or you could use a command like `espeak-ng "It is now $(date +%R)"` so it'll simply announce the current time whenever it's triggered, thus giving you a general-purpose talking clock. Note that if you make the timer/service unit pair "system" units (in /etc/systemd/system), they'll run (as root) as long as the machine is up and running. If you make them "user" units (in ~/.config/systemd/user/), by default they'll run only when you're logged in. If you want to have user units run when the user is not logged in, the systemd terminology for that is "enable lingering". If you're not familiar with the syntax of systemd unit files, there is a bit of a learning curve, but I'd bet that if you can script in Bash, it won't take you long to get to the point where you can write a minimal timer and service unit pair for a job like this. Cheers! -Chris
Re: Can't create a password successfully.
On Sun, 3 Apr 2022 22:45:27 -0700 David Christensen wrote: > On 4/3/22 21:07, ghe2001 wrote: > > I kinda thought it probably was. It's pretty obvious. The idea is > > to generate a bunch of gibberish that could be easily remembered. > > It's not gibberish; it has meaning. The meaning is what makes the > password both memorable and weak. I concur with David. The fundamental problem with using clever formulas to come up with memorable passwords is that clever formulas are reproducible. The "dictionary" from which a modern password cracker draws its guesses has nothing to do with what is and isn't "a dictionary word". Rather, it's a purpose-built word list, informed by years of statistical analysis of millions of real-world passwords leaked from previous breaches. Actual randomness is the only reasonably effective way to make a password hard to guess. Trying to come up with unique, sufficiently random passwords for every website, service, and so forth — and *remember* all those passwords — is a real problem at any age. I would strongly suggest using a password manager. Make sure the master password to unlock the password manager is really strong. But then you only have one password to remember, and you can have an effectively unlimited number of unique, random, strong passwords. Personally, I use KeepassXC with a self-hosted Syncthing instance to sync the password file to all my devices. If you're not up for self-hosting, there are some cloud-based password managers with decent security too, eg Bitwarden. For the specific challenge of *generating* passwords that are both genuinely random and reasonably memorable, you might want to take a look at the "diceware" approach, which is to start with a list of several tens of thousands of actual English words and use a high-quality random number generator to pick a few words from the list. As a helpful little bonus, most password managers nowadays come with a password generator built-in, which in many cases can be configured to generate a diceware passphrase instead of a gibberish string of characters. Cheers! -Chris
Re: Permanent email address?
On Tue, 17 May 2022 12:22:48 -0400 Edwin Zimmerman wrote: > > If you can't get a static IP address for your home computer, > > consider running your mail server on a cheap VPS (Virtual Private > > Server). This may be cheaper than a static IP address for your > > home, depending on your ISP. > > > > Don't host your email on just any old cheap VPS. Many VPS providers > have bad reputations for not policing spam senders, and as a > consequence large email services like gmail often block whole ip > ranges that belong to these VPS providers. Also note that you very much do *not* need to run your own MTA to achieve the goal of an address you own and can move from provider to provider. Once you own the domain, you can set up your DNS MX records to delegate to an email provider. If you later decide to switch email providers or host your own MTA, you change the MX records to point to the new provider or server. (If you have mail *stored* on your old provider's server when you terminate your account with them, you'd need to download it or lose it, obviously.) Hosting your own MTA makes the problem ten times more complicated, and it's not at all clear that there's any relevant advantage in terms of the stated objectives. In particular, don't expect running your own MTA to gain you any kind of privacy. Email is a store-and-forward protocol that may route through an arbitrary number of intermediate servers on the way from origin to destination. All of those servers at least temporarily store a copy of every email that passes through, and any of them may be permanently saving, reading, data-mining, or selling those messages. Any email that's not encrypted is simply not a private communication, regardless of who runs your MTA. Cheers! -Chris
Re: how to get rid of anacron?
On Mon, 4 Jul 2022 23:39:40 +0300 Roland Mueller wrote: > > On 7/4/22 10:41, Michael wrote: > > > > afaik systemd timer lack the possibility to send the output (if any) > > by email to a designated user, but instead logs the output to its > > journal. > > yes, you are right. If receiving by mail is a requirement - this > works in cron out of the box. > Using systemd scheduler instant check during development is for my > needs sufficiently covered by 'systemctl status' or journalctl. There's a trick using a systemd "template" unit that I use to get an email notification only if something goes wrong. I have a unit file named email-notify@.service with contents: [Unit] Description=%i email notification [Service] Type=oneshot ExecStart=/bin/bash -c '/bin/systemctl status %i | /usr/bin/mail \ -s "%H: %i $(/bin/systemctl show -p ActiveState --value %i)" root' Then, in any unit from which I want email notifications on failure, I add in the [Unit] section the line OnFailure=email-notify@%n Then if the primary unit fails, it triggers an instance of email-notify which has the primary unit's base name as its instance name. Then the ugly one-liner in email-notify@.service populates the Subject header with the hostname and the name and status of the failed unit, and the body with a log summary, and sends it to root. email-notify@.service is agnostic as to the status of the unit it's notifying you about, so this doesn't *have* to be limited to on failure only… That's just how I use it. Cheers! -Chris
Re: how to get rid of anacron?
On Wed, 6 Jul 2022 12:07:59 -0400 Timothy M Butterworth wrote: > On Tue, Jul 5, 2022 at 2:15 PM Chris Mitchell > wrote: > > > I have a unit file named email-notify@.service with contents: > > [Unit] > > Description=%i email notification > > > > [Service] > > Type=oneshot > > > > ExecStart=/bin/bash -c '/bin/systemctl status %i | > > /usr/bin/mail \ -s "%H: %i $(/bin/systemctl show -p ActiveState > > --value %i)" root' > > Are you creating this file in: /usr/lib/systemd/system or > /etc/systemd/system/ > /etc/systemd/system/ As I understand it, files under /usr/lib/systemd/system should only be created or modified by packages. A sysadmin who wants to add new units should always put them under /etc/systemd/system. Bonus tip: overrides to package-provided units should also go under /etc/systemd/system, even if the original unit files are in /usr/lib/systemd/system. The command `systemctl edit ` automatically creates the precisely named path and file for this purpose. The official systemd documentation is not the most readable thing ever, but it's pretty thorough, and does detail the hierarchy of unit file and override locations. https://www.freedesktop.org/software/systemd/man/systemd.unit.html Cheers! -Chris PS: Please keep all replies on-list so others can benefit from follow-up questions and answers.
*Now* what is starting ssh-agent?
Hi all, I have my own systemd "user" .service unit that I like to use to start ssh-agent the way I want it started, which works fine… except for the neverending game of whack-a-mole tracking down and disabling various legacy workarounds that go ahead and start ssh-agent unasked (or emulate it, poorly, like gnome-keyring) and clobber my SSH_AUTH_SOCK env-var. Here's my service file: $ cat /etc/systemd/user/ssh-agent.service [Unit] Description=SSH key agent [Service] Type=exec # %t resolves to XDG_RUNTIME_DIR; see SPECIFIERS section in systemd.unit(5) ExecStart=/usr/bin/ssh-agent -D -a "%t/ssh-agent.socket" [Install] WantedBy=default.target Sure enough, on a current laptop running Bookworm, even though I have that service enabled and running, and I've gone through my list of things to disable, there's a superfluous ssh-agent process running with the default randomized socket location, and SSH_AUTH_SOCK has been clobbered to point at that. Here's what I know so far: $ env | grep -i ssh SSH_AUTH_SOCK=/tmp/ssh-XXZAaNOY/agent.3010 SSH_AGENT_PID=3011 $ ps ax | grep 3011 3011 ?Ss 0:00 /usr/bin/ssh-agent -s $ pstree -ps 3011 systemd(1)───ssh-agent(3011) Here I get confused. The path shown by ps rules out the possibility that it's some other utility pretending to be ssh-agent. Unless I'm mistaken, that pstree result indicates that this ssh-agent process was started by systemd, but: $ grep -rl ssh-agent /usr/lib/systemd/ /usr/lib/systemd/user-environment-generators/90gpg-agent /usr/lib/systemd/user/gpg-agent-ssh.socket /usr/lib/systemd/user/ssh-agent.service Even though gpg-agent is running, I think it can be ignored because: * it wouldn't show up in ps as "/usr/bin/ssh-agent", * that environment generator only sets the SSH_AUTH_SOCK env-var if "enable-ssh-support" is enabled per "gpgconf --list-options gpg-agent", which it is not, and * Those two ssh-related env-vars don't match gpg-agent's PID or ssh-agent-socket path. And /usr/lib/systemd/user/ssh-agent.service is not the culprit, because: * /etc/systemd/user/ssh-agent.service has a higher priority, which causes systemd to ignore the one under /usr/lib/, and * /usr/lib/systemd/user/ssh-agent.service uses the socket location "$XDG_RUNTIME_DIR/openssh_agent" Continuing the search: $ grep -rl ssh-agent /etc/systemd/ Returns one hit, which is my custom service file as shown above $ grep -rl ssh-agent ~/.config/systemd/ Returns nothing, unsurprisingly. Things that are already disabled: * gnome-keyring is not installed * /etc/X11/Xsession.options option use-ssh-agent is commented out * XFCE4's "Application Autostart" config has no entry for ssh-agent * XFCE4's "Launch GNOME services on startup" is disabled (If enabled, this option launches gnome-keyring if available, which by default would emulate ssh-agent and clobber the env-var) * $ grep -rl ssh-agent ~/.config/autostart/ returns nothing, as expected Anyone got any idea where I should look next to identify what's actually starting that rogue ssh-agent process & clobbering my env-var, and prevent it from doing so? Cheers! -Chris PS. Please keep all replies on-list, thanks!
Re: *Now* what is starting ssh-agent?
On Tue, 26 Jul 2022 21:54:18 +0200 Erwan David wrote: > ssh-agent is usually started by your session manager. I do not know > wether all DE use this, but you can find it in > > /etc/X11/Xsession.d/90x11-common_ssh-agent True. The snippet in that file is nested in a conditional, though: if has_option use-ssh-agent; then … If I'm not mistaken, disabling "use_ssh_agent" in /etc/X11/Xsession.options causes that conditional to fail, so /etc/X11/Xsession.d/90x11-common_ssh-agent will do nothing. man Xsession(5) uses the wording "If the line ‘use-ssh-agent’ is present in Xsession.options", but man Xsession.options(5) says "All of the above options are enabled by default" and instructs to disable them by prefixing the option with "no-". Prior experience suggests that commenting the line out *is* sufficient to disable it, but just to be sure I have uncommented the line and changed it to "no-use-ssh-agent". Even after a reboot, this has made no difference to the situation. $ grep -i ssh ~/.xsession-errors returns no results, and that file *does* have entries showing other environment variables being set via dbus-update-activation-environment. I suppose I could try commenting out the whole snippet in /etc/X11/Xsession.d/90x11-common_ssh-agent, or moving the file away, but at this point I'm reasonably confident Xsession is not the culprit. Thanks for the lead, though. I know a bit more about how Xsession works now than I did yesterday. Cheers! -Chris
Re: *Now* what is starting ssh-agent?
Jul. 26, 2022 17:00:46 Greg Wooledge : > On Tue, Jul 26, 2022 at 03:40:48PM -0300, Chris Mitchell wrote: >> Here's my service file: >> >> $ cat /etc/systemd/user/ssh-agent.service > > According to systemd.unit(5) this directory is for "User units created > by the administrator". Yup, that's me! In practice, it means units placed there are user units that are available to all users on the system, so they can start/stop/enable/disable/… their own instances of those units via "systemctl --user" commands (or root can do the same for all users at once with "systemctl --global). A unit in this directory will supersede a same-named unit in /usr/lib/systemd/user, and may in turn be superseded on a user-by-user basis via their respective ~/.config/systemd/user directories. > PID 1 is the system instance of systemd. Not a user instance. > The ssh-agent with PID 3011 is being started by the system instance, > so it is a system unit. It's not your locally defined user unit. Oh, yes. I should have realized that. Weird that the system instance would be configured to start an ssh-agent at all, but I'll definitely look there next. > Things you should look at next, I suppose: > > systemctl status ssh-agent > systemctl --user status ssh-agent The --user one shows that my custom "global" user unit at /etc/systemd/user is up and running as expected, which I can verify by manually changing SSH_AUTH_SOCK to point to the socket specified there and accessing the agent. If the *system* systemd instance is actually launching an ssh-agent and injecting corresponding env-vars into my regular user environment, that is deeply strange, and I'm reasonably sure I haven't done anything that could cause that outcome. # systemctl status ssh-agent.service Unit ssh-agent.service could not be found. # systemctl list-units --all *ssh* UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. > Starting an ssh-agent via systemd is completely outside of my > experience, though, and I don't really understand why you'd attempt > it. It's not clear to me *at all* how you would communicate the > environment variables from the ssh-agent invocation over to the > user's login session. My setup is to have each user's "user" systemd instance manage their ssh-agent (which is also how the Bookworm package handles it, though with some differences in the implementation details). Being a long-running daemon type process that provides a service to other processes, ssh-agent struck me as an ideal candidate for being handled by the service manager. The only environment variable that remains relevant now that systemd handles the process control stuff is SSH_AUTH_SOCK, and because I specify a consistent socket location, I can set that statically for all login sessions, the same way you would go about adding a custom location to PATH or whatever. Advantages include: * hands-on learning experience with systemd, which is clearly here to stay, * make ssh-agent start, and behave consistently, regardless of what DE I use, or no DE, or no X or Wayland or graphical anything, * any user who has a non-zero number of active login sessions gets exactly one ssh-agent process, regardless of what "type" of session(s) For example: if I log in to XFCE4, load a few ssh keys into my ssh-agent, and something causes X to hang, I swap to VT1 and log in there. Systemd no-ops my ssh-agent.service because it's already running, and access to ssh-agent works right there in VT1, including the already-loaded keys. Now I restart lightdm, which kills the session that started my ssh-agent.service, but because I still have a non-zero number of active login sessions (VT1), systemd keeps that service running. Then I can swap back to the lightdm greeter and log in to XFCE4, or KDE, or Enlightenment, or whatever, and my ssh-agent is already up and ready with the keys I loaded earlier. Just for fun, if I want to make ssh-agent socket-activated for every user on the system instead of auto-started at login, I can drop a ~5 line ssh-agent.socket file in /etc/systemd/user/ alongside the ssh-agent.service file, systemctl --global disable the .service unit and enable the .socket unit instead, and that's it. I've been using this "global" systemd user unit to manage ssh-agent for a couple of years now, and it's just about perfect… except when some legacy workaround comes along and clobbers things. Cheers! -Chris
Re: *Now* what is starting ssh-agent?
On Wed, 27 Jul 2022 11:04:49 +0200 Michael Biebl wrote: > Can you post the output of > systemd-cgls First, for context: $ systemd-cgls --user-unit ssh-agent.service Unit ssh-agent.service (/user.slice/user-1000.slice/user@1000.service/app.slice> └─3166 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket That is my custom "global" user ssh-agent.service, not the rogue ssh-agent. The rogue ssh-agent is also started: $ env | grep -i ssh SSH_AUTH_SOCK=/tmp/ssh-XX3Q3EAs/agent.3302 SSH_AGENT_PID=3303 The full output of # systemd-cgls is over 200 lines, and paste.debian.net rejected it with the message "do not spam", so here we go: https://pastebin.com/68wWRnyb Cheers! -Chris
Re: Twice load - rndc.key ?
On Mon, 11 Jul 2022 13:40:32 -0600 Charles Curley wrote: > On Mon, 11 Jul 2022 21:01:48 +0200 > Maurizio Caloro wrote: > > > > # cat /lib/systemd/system/named.service > > First mistake: you should not be editing files in /lib/systemd/. > Instead copy the file to edit into /etc/systemd/, and edit it there. I > believe there is a systemd command that will do that for you if > necessary. The reason is that when an upgrade comes along, it will > stomp on any changes you have made in /lib/systemd/. If you want to supersede the entire unit file from /lib/systemd/ so that no future package updates to that file will have any effect at all, then yes. Copy the unit file to /etc/systemd/[system|user]/ as appropriate and edit it. If you want to selectively override only specific directives rather than supersede the unit completely, the easy way is "systemctl edit ". That command automatically creates for you an appropriately named ".d" drop-in directory below /etc/systemd, creates a .conf file in the drop-in directory, and launches an editor where you can define the directives you want. Caveat: when using drop-in overrides, values you set are generally *added* to whatever was set before. If you want to *replace* the value of a particular directive, you have to explicitly set it to null first, on a line by itself, like: ExecStartPre= ...and *then* add a line setting it to whatever you want. I got some very confusing results when overriding .timer files before I learned that detail. Cheers! -Chris
Re: *Now* what is starting ssh-agent?
Still picking away at this… The PIDs are, of course, a moving target, as every time I log out and back in to test a change, ssh-agent instances are getting shut down and new ones started. As of right now: * my systemd-managed ssh-agent is PID 3017 * the rogue ssh-agent is PID 7687 $ systemctl --user status ssh-agent.service ● ssh-agent.service - SSH key agent Loaded: loaded (/etc/xdg/systemd/user/ssh-agent.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-07-28 08:02:14 ADT; 1h 21min ago Main PID: 3017 (ssh-agent) Tasks: 1 (limit: 9302) Memory: 560.0K CPU: 5ms CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service └─3017 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket From the output of systemd-cgls I see that the rogue ssh-agent process is part of the .scope CGroup corresponding to my X login session. # systemctl status session-8.scope ● session-8.scope - Session 8 of User chris Loaded: loaded (/run/systemd/transient/session-8.scope; transient) Transient: yes Active: active (running) since Thu 2022-07-28 08:59:48 ADT; 25min ago Tasks: 254 Memory: 957.6M CPU: 2min 5.903s CGroup: /user.slice/user-1000.slice/session-8.scope ├─ 7588 lightdm --session-child 14 23 ├─ 7625 xfce4-session ├─ 7687 /usr/bin/ssh-agent -s etc. man systemd.scope(5) says: Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. […] Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. By my reading, that seems to indicate that the rogue ssh-agent (PID 7687) is a direct child of systemd's system instance (PID 1) only because my XFCE4 session and all of its associated processes are running contained in a "scope" (to take advantage of systemd's resource management capabilities?), and this does not indicate that said ssh-agent is in any direct or relevant sense being managed by systemd. Can anyone confirm or correct my understanding here? Also, in the absence of more promising leads, I followed Tomas' advice and inserted "echo" statements at every decision point in 90x11-common_ssh-agent, which confirmed that the initial "if has_option" check is returning False and none of the code in that if block is being run. I'm convinced that Xsession is not the culprit. Any ideas where I might look next? Anyone know if it's possible to ask systemd what process "externally created" a process in a .scope? Cheers! -Chris
Re: *Now* what is starting ssh-agent?
On Thu, 28 Jul 2022 10:08:22 -0500 David Wright wrote: > On Thu 28 Jul 2022 at 10:35:07 (-0400), Greg Wooledge wrote: > I did much the same … > > > My .xsession file contains only this line concerning ssh-agent: > > > > hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)" I don't appear to have a .xsession file at all: (Right after a "sudo updatedb") $ locate .xsession /home/chris/.xsession-errors /home/chris/.xsession-errors.old /home/chris/.xsession-startup-dump > > Looking for related stuff: > > … > > /etc/X11/Xsession.options:use-ssh-agent > > > > So, I suppose Debian is starting this ssh-agent via its Xsession > > even though I have my own .xsession file which is starting my own > > instance of ssh-agent. > > > > I guess you've already disabled that one...? $ grep ssh-agent /etc/X11/Xsession.options no-use-ssh-agent > > Anyway, your login is completely different from mine (you're using > > lightdm, while I'm using a console login and startx), so you'll > > have to pursue your own investigation from here. > > > > Given the order of the processes shown in your session-8, it looks > > like it might be an XFCE thing. Maybe start there? I can't help > > you with that, though. Fair enough. Thanks for your insight up to this point! > I assume that some process above ssh-agent has died, unintentionally > or otherwise. > > > > Any ideas where I might look next? Anyone know if it's possible > > > to ask systemd what process "externally created" a process in a > > > .scope? > > I'm not sure what you mean by this, unless it's the (wrong) idea that > systemd "injected" the ssh-agent into your scope, evidenced by its > parent being PID 1. My scope is clearly generated merely by logging > in. Everything in it is mine, all mine … … > All the parent/child relationships are as you would expect, except > that each xterm was started by a deceased instance of xtoolwait > (for correct placement) and so are all adoptees of PID 1. Hm. Okay, so now that those xterms are adoptees of PID 1, is there some way you could discover that the now-deceased parents from which PID 1 adopted them were instances of xtoolwait, if you didn't already know that? I'm thinking that if I could get the name of the now-dead process that started the unwanted ssh-agent process and then died and left ssh-agent to be adopted by PID 1, that would likely be a helpful clue. But I'm teetering on the very edge of my comprehension of the system here, and I have no idea whether that piece of information still exists once said parent process has died, or how to retrieve it if so. > I'd like to see the contents of $STARTUP before it's exec'd by > /etc/X11/Xsession.d/99x11-common_start, because that's what > actually does the business. Right before the exec statement in that file, I've added the line: echo "$STARTUP" >> ~/.xsession-startup-dump After logging out and back in, that .xsession-startup-dump file contains one line: x-session-manager /usr/bin/x-session-manager is a link (via /etc/alternatives) to /usr/bin/startxfce4 Cheers! -Chris
Re: *Now* what is starting ssh-agent? — SOLVED
On Thu, 28 Jul 2022 14:51:04 -0300 Chris Mitchell wrote: > > On Thu 28 Jul 2022 at 10:35:07 (-0400), Greg Wooledge wrote: > > > Given the order of the processes shown in your session-8, it looks > > > like it might be an XFCE thing. Maybe start there? I can't help > > > you with that, though. > > Fair enough. Thanks for your insight up to this point! Found it! It was indeed very much "an XFCE thing". It's even a documented behaviour, if you know where to look: https://docs.xfce.org/xfce/xfce4-session/advanced#ssh_and_gpg_agents After creating the two xfconf entries per that page: xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled \ -n -t bool -s false xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled \ -n -t bool -s false …and logging out and in again, no more rogue ssh-agent: $ pgrep -a ssh-agent 2903 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket $ systemctl --user status ssh-agent.service ● ssh-agent.service - SSH key agent Loaded: loaded (/etc/xdg/systemd/user/ssh-agent.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-07-28 15:15:13 ADT; 14min ago Main PID: 2903 (ssh-agent) Tasks: 1 (limit: 9302) Memory: 560.0K CPU: 5ms CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service └─2903 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket Victory! Thanks again to everybody who offered pointers. And I've added another entry in the list of "helpful" automatic stuff to disable when configuring a new desktop system. I'm starting to seriously consider that I might be happier with just a decent window manager after all. Cheers! -Chris
Re: LibreOffice - any way to recover not saved changes to the file?
On Wed, 14 Sep 2022 09:37:14 +0200 (CEST) local10 wrote: > I actually have it disabled on purpose. The reason is I don't always > want changes to be autosaved because sometimes the changes make the > document worse. I wonder if there's some change tracking option in LO > that would allow to see how the document developed over time. If you check the checkbox found at: Edit → Track Changes → Record it will do exactly that. Note that it records a *lot* of detail, and can bloat the file size if the edit history gets long. Personally, I store most of my documents in a Syncthing share and have the server-side Syncthing instance set to retain the last 'n' versions of the file. Each autosave is a new 'version', so there's a balance between autosave frequency and number of retained versions. Eg autosave every 30 minutes, retain last 10 versions, that allows 5 hours of continuous working before the state of the file before I sat down to start the day gets pushed off the stack. If you want to go all in on "how the document developed over time" and are comfortable with git, I gather it's possible to set up git hooks that will unpack the compressed odt file on the fly and commit the version-able, diff-able contents to a git repo, and vice versa. This would enable true version control, including branching, tagged release versions, and so forth. I've never tried this, and can't vouch for how smoothly it works in practice. Cheers! -Chris
