Linux - Reddit – Telegram
Linux - Reddit
776 subscribers
4.19K photos
207 videos
39.9K links
Stay up-to-date with everything Linux!
Content directly fetched from the subreddit just for you.

Powered by : @r_channels
Download Telegram
You probably hate systemd because you think it's all about "boot fast no bash" - but it can do so much more you probably had no idea about.

This is a bit of a rant, a bit of an educational post, and really came about because I'm just tired of how much flak systemd got and still gets based on obscure philosophical "issues". That's not to say I fully disagree, I'm just a pragmatist. I think it's better in a lot of ways. But when someone comes in to defend systemd, what do they usually have to offer? What improvements justify that philosophical sacrifice? "Uh, it boots fast. And BASH is annoying." Cool. Clearly that's convinced some people, but it doesn't really give any *compelling* reasons for why it's "better".

The documentation for systemd is utter crap, and finding out everything about what it can do involves slogging through pages and pages of boring documentation with no examples. Even those who have been using systemd for years probably have no idea of half of what it can do.

So I'm here to tell you about a couple *really cool features* that you probably never heard about, that might change your mind about systemd, at least in a practical sense. If they don't, that's fine. But at the very least, if you're stuck with it in every major distro, you can at least know some neat features that might be useful to you!

# #1 - Seriously, `service` units are great.

This one does come up a lot as a defense, but I'd be remiss not to repeat it. Boilerplate BASH SysV initnoscripts are crap. They're fragile, they're annoying to read, they're annoying to write, and half the time they're just calling `start-stop-daemon` anyways, which is a half-assed service manager at best. Systemd units are clean, concise, and powerful. They're worth a look on their own merits if you've ever written an initnoscript and hated every moment of it. You can auto-restart failed units, you can delay the restart, you can do actions... so much power, no BASH knowledge necessary.

# #2 - [Email yourself (or do whatever you want) on a service failure.](https://serverfault.com/a/701100/188250)

This is a cool little feature of units. You can specify an `OnFailure` entry in your unit to execute *another* arbitrary unit if the service fails. For example, a `oneshot` unit that sends you an email. Or perhaps starting a secondary daemon to do something else. Really anything you want.

# #3 - `ExecPreStart`/`ExecPostStart` and similar `Stop` commands

OK, yea, you can do this in BASH initnoscripts too, but Systemd just makes it so... accessible. Want to `git pull` before starting a service? Want to remove a cache directory on exit? Easy peasey. Add `ExecPreStart = /path/to/mynoscript` to execute `mynoscript` before starting the main `ExecStart`. And systemd will fail the whole unit if the `Pre` command fails. If you don't want that, you [can make them optional as well](https://unix.stackexchange.com/questions/404199/documentation-of-equals-minus-in-systemd-unit-files) by adding a `-` before the path.

# #4 - [Mount units](https://oguya.ch/posts/2015-09-01-systemd-mount-partition/)

This is a biggie. You may have heard of them in the context of `fstab`, how Systemd "destroys" it. But this is incredibly short-sighted. First, editing fstab programmatically (looking at you, Ansible) is a pain in the ass and fraught with dragons. Mount units let you create mount definitions atomically. Second, you can depend anything on them! Imagine you have an NFS filesystem and a Free Software Media server (shameless /r/jellyfin plug). You don't want that server to start if your filesystem isn't mounted, because bad things would happen if you do. What can you do? `mount -a` is a hack. No - use a `.mount` unit for your NFS volume, and then `Requires = my-mount.mount` in the service! Now you're safe.

There is one major caveat though: if you have a `-` in your mount directory target, you're going to have a *very bad time*, since the unit is named `path-to-mountpoint.mount` with the `-` replacing the filesystem `/` separator, and escaping the dashes almost never works. Otherwise, though, the
y're incredibly powerful.

# #5 - [Simple overrides with `unit.d` directories](https://unix.stackexchange.com/a/468067)

Have a unit installed by an operating system package, but you want to do some interesting things to it? The first thing everyone thinks is to just edit the `/lib/systemd/system/my-unit.service` file and go wild. But, this will be overwritten on an upgrade. OK, you might read a bit, and then copy it from `/lib` into `/etc`. That won't be overwritten. But now you've duplicated the unit, and won't get nice improvements from your packages. The solution? `/etc/systemd/system/my-unit.service.d/`! Using this directory, you can override small components of the unit file with your own values, for instance adding an `ExecPreStart` or a `Requires`. The above example uses the `systemctl edit` function, which automatically creates these overrides, but you can drop these files in manually too using your configuration management of choice.

# #6 - Targets - group services, mounts, etc. together

Target units are another really cool feature of Systemd. You've probably seen stuff like `Reached multi-user.target` in your boot logs, but you can of course create your own `targets` as well. Simply put, they group other units together. If two services and a mount are part of a target, the target won't be reached until all of them start, and you can, with a few modifications to the units - using `PartOf = mytarget.target` in the `[Unit]` section of the services/mounts - control all the services by stopping or starting the target itself, in the right order. Depend other services on targets as well for maximum control of the startup sequence. There's a ton of power here.

# #7 - `systemctl enable` and `systemctl disable`

This is a really basic one, but want to turn off a service or mount for a bit? Disable it! Want a service that is installed by default (such as `nginx`), but want to start it with `supervisord` instead and are getting a conflict? Disable it!

# #8 - PIDFile

A nice thing about Systemd is that you don't ever have to worry about PID files, including weird stale PIDfiles lying around and messing with your service startup. But still want one? You can still add one with `PIDFile=`.

# #9 - Sockets units can replace [x]inetd

The old style, "run a noscript on a socket connection" tool inetd and its modern successor xinetd can be replaced by [systemd `.socket` units](https://www.linux.com/blog/end-road-systemds-socket-units), bringing the ease of use and control of Systemd to your inetd services!

Those are the first 9 I can think of right now, but if you have any of your own cool systemd tricks, I'd love to hear them too!

https://redd.it/bsqar4
@r_linux
what's the best lightweight Linux distro OS?

my internal storage is only 27.5gb, and has a 4gb ram with 1.6ghz processor.
can anyone suggest the lightest+most function Linux Distro?

https://redd.it/bsqzls
@r_linux
No hope for open chips from lowRISC?

I just found out that lowRISC is [hiring](https://www.lowrisc.org/jobs/). But I aslo found out that lowRISC is not aiming to produce real hardware anymore! Now they are:

> developing and maintaining high quality, verified open source silicon IP

But that was the first hardware project I was so fascinated about! I was ready to gave them some money without return just to see a piece of open-source hardware being manufactured. And they intended to produce it [from the start](https://web.archive.org/web/20140827011745/http://www.lowrisc.org/)!

> lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco-system.

Their noscript was till recently:

> A fully open-sourced, Linux-capable, System-on-a-Chip

and now it is:

> Open to the core Enabling open source silicon through collaborative engineering of tools and designs

I am so disappointed.

https://redd.it/bst5jw
@r_linux
TuxClocker AMD version released for overclocking your AMD GPU

https://github.com/Lurkki14/tuxclocker

Features for this version are:

- GPU monitoring (list and graph)
- Overclocking
- Overvolting
- Change power limit
- Pstate editing
- Fan mode selection
- Custom fan curve (root required)
- Provisional multi-GPU support
- Profiles

The AMD version is currently a separate codebase from the earlier versions, so the AMD version only works with AMD GPUs. I'm working on a new, more flexible version supporting nvidia and AMD.

https://redd.it/bsupzo
@r_linux
Systemd vs init noscripts, an essay



Reading the other post about Systemd made me want to write this.

​

Two things to understand about the below, 1) I am OLD for a Linux admin, almost 60 years old, I have been doing this for a long time, almost 30 years. I learned SunOS at an ATT training center that supported CompuServe, that kind of old. 2) Boring old man ramble: I remember arguing with people that hated anti-lock brakes back before some of you were born. I remember guys telling me, straight faced, that "No machine can brake as well as I can", "I can stop the car better than the software". They were wrong, but having a skill you value obsoleted by a chunk of code is a bitter pill to swallow.

All that being said and understood. Systemd frustrates me because I want it off my damn lawn. I see the benefits, but the having to google how to use it is frustrating for a senior admin (in both senses of the word) to have to do. We are being forced by regulators to update to RHEL 7 and that is forcing me to interact with systemd. I am learning, but lord it reminds me of every overly convoluted noscript a junior coder has ever written, and that’s the rub. It LOOKS like it over complicates what, at its core, is a simple idea. I just want to start f\*\*king NFS, damnit. I am beginning to understand and appreciate the benefits, but God I wish it was simpler.

Init noscripts time is over. They need to go for a lot of reasons, but forgive me for being glad that I will retire before they are completely rolled out.

https://redd.it/bsunzw
@r_linux
Linux resource for noobs (Linux Journey)

While attempting to help someone who was helpless in the end and didn't want to learn anything, I came across this link:

https://linuxjourney.com/

After running through a few parts of this simple website, I thought it would be useful for people who want to go beyond the gui and learn some command-line basics and how to manage simple services such as logging, ssh, file-sharing, and web.

Who ever created this site, nice job.

https://redd.it/bsy6g6
@r_linux
Linux desktop system wide scroll speed setting still missing

I've been a casual Linux desktop user for the last 5 or so years, most of my time is spent on server environments and cli.

Just installed Linux on a laptop and tried two different desktop environments. Both were still lacking system wide mouse scroll speed settings. This was the case also years ago when I first dabbled with Linux desktop.

Why hasn't this (pretty basic) functionality been implemented more commonly yet? Are there functional packages to remediate the problem? Is there something preventing this implementation?

https://redd.it/bsznat
@r_linux