[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] Systemd daemon take overs

On Tue, 19 May 2020 20:50:34 -0400
Solomon Peachy <pizza at shaftnet.org> wrote:

> On Tue, May 19, 2020 at 07:42:26PM -0400, DJ-Pfulio via Ale wrote:
> > * mount (the fstab!)  
> There's not much point in trying to mount network filesystems before
> the network is up.  And there are daemons that shouldn't be started
> before all filesystems are mounted -- and stuff that needs to be
> stopped cleanly should a given filesystem go away.

Already addressed: _netdev handled that already, assuming the mount
subsystem didn't understand that cifs and nfs and 9p and webdav and
sshfs file systems would require networking. 

> So there are some legitimate arguments for systemd keeping on top of 
> filesytems.  Personally I've found that quite handy over the years, 
> especially in the light of networked or external storage that
> randomly flakes out.

I've only had USB storage with loose connections flake out.  NFS is
always there, always stable. Perhaps I'm just lucky?

> (Incidentally, I think Fedora's been using systemd to
> handle /etc/fstab since their first systemd-based release, something
> like 8 years ago!)

systemd was added to Ubuntu sometime in 2015, which I avoided. I only
use LTS releases. 16.04 came with some minimal systemd stuff, but over
time, it has been expanded to include the screwed resolvd (resolvconf
was already piss poor) and systemd.mount crapola.

> > * automount / autofs  
> Only for mount points in fstab that are explicitly marked as 
> automountable by systemd.  (Anectdotally I've found systemd's
> automount handling to be far more robust than autofs.  But that's not
> saying much..)

Been using Autofs for a very long time and amd/automounter before that
going back to the 1990s.  It has been well-behaved for 20 yrs, at least
for us.

> > * ntpd --->  .conf  
> Blame your distro for changing its defaults.

timesyncd is less than a second off 12 hrs after I modified the config,
which is good enough for my needs.  Chrony is included in the main
ubuntu release, just not the flavor I run.  My mistake.

"But still for simple time-sync needs the base system already comes with
systemd-timesyncd. Chrony is only needed to act as a time server or if
you want the advertised more accurate and efficient syncing."  

My distro choice is current being re-evaluated. The systemd stuff isn't
even a big item on the list.

> (Fedora doesn't do this; it defaults to chronyd and ntpd remains
> available)

I'd rather not run a test/dev OS.

> > * resolvconf --> resolved.conf  
> Blame your distro for changing how it does things.

Point taken.  They've been screwing this resolving to long. The last 5
yrs, I usually just remove/mask those services and edit
the /etc/resolv.conf directly to point at the DNS servers. This always
works just like is has since the early 1990s, probably longer.  Only
with portable devices is that an issue.

> (Fedora doesn't do this as of F32, but intends to default to using it
>  in the F33 workstation spin only)

Dev/test releases don't interest me.

> > Modifying the fstab and running mount -a isn't enough anymore.  We
> > have to run  ....   
> Um, if this doesn't work, there's something broken with your distro
> or the fstab entries themselves)

No doubt. Should have realized the issues when they started swapping in
more and more systemd modules on an existing LTS.  LTS releases are
supposed to retain the same code and only get security and bug fixes.
No change in functionality.

> (Just tested it now, in fact... Fedora 31 and 32 both work fine with
> mount -a)

What do you mean "fine."  You added a mount or changed mount options
and those changes were seen?

> > But the automount for USB storage is a little flaky, IME.  Plus
> > the  
> automounting USB sticks isn't something systemd typically handles; 
> instead the hotplug events go through udev+udisks rules customized by 
> the distro and/or desktop environment.  (And I might add udev+udisks
> has been handling things this way well before sytstemd came along..)

autofs has handled this flawlessly for 15 yrs.  I've never used udisks.
I don't use GUIs for admin stuff. I'm happier avoiding the Gnome team
bloat when possible. Haven't dealt with udev since the
project was turned over to the systemd team. Call me grumpy. 

I disable any automatic mounts that aren't handled by autofs. The power
to mount is the power to destroy. Learned that long ago.

> > Let's not forget PulseAudio.  Every week, seems I'm fighting with
> > pulse over something.  
> Since we're talking anectdotes, it's been literally years since I
> last had a pulseaudio-related problem, not that I had many to begin
> with. 

Today, Firefox won't play a video, but audio works for every other
program on the system.  Firefox doesn't show up in pavucontrol at all.
I suppose it could be a firefox issue, but I've had issues with
chromium and cmus and clementine ever since Pulse was forced onto us.
At this point, Pulse is better than Alsa for the interface, but the
massive capabilities seem to overly complicate what normal people need
who have just a few audio devices.  Could easily be a distro issue.
Plus, alsa is still there, below PulseA.

> Indeed, thanks to this working from home thing, on a daily basis I
> take advantage of features that simply aren't available in the
> absense of PulseAudio -- switching audio devices on the fly for both
> output (desktop speakers, headphones, bluetooth) and input (webcam,
> headset).

Pulse likes to find and enable whatever was most recently plugged in.
That is often what the end-user wants, but not always.

Why does the DISPLAY environment variable control audio at all?  cmus
doesn't work correctly until I set the DISPLAY to the machine I'm
logged into. cmus is a TUI audio player.  Great to have a rpi connected
to an audio system in another room, but control it from anywhere.  Some
people use mpd.

> > What other things has systemd taken over that I've missed?  
> These changes, and other system-level things, tend to be documented
> in your distro's release notes.  You may want to pay more attention
> to them before upgrading or installing newer versions..

I always read the Release Notes prior to installing.
https://wiki.ubuntu.com/FocalFossa/ReleaseNotes I think we've found the
lack of communication problem with my distro. They to mention changes
to Apache and Samba versions, but barely mention their intent to break
all network storage access as they force/deploy snap packages.  

"Snap Store
The Snap Store (snap-store) replaces ubuntu-software as the default
tool for finding and installing packages and snaps."

That's the release note about a package system that breaks all sorts of

Sorry for the rant.  I must need a nap and some hot cocoa.

They have done so much excellent work too, but I haven't gotten passed
the problems to appreciate the greatness.  For example, ssh supports
U2F keys now.  That's pretty great.  If only KeePassXC supported
multiple U2F keys and other authentication methods for the same DB.
That's one dream.

Workflows that only work for 1 device and 1 authentication method
aren't ideal.  I'd love to use U2F everywhere, but not when only 1
token can be used.  Need a primary and backup token, plus a way to use
a pre-generated response table for devices that don't work with u2f