What is Reddit's opinion of
systemd?
From 3.5 billion Reddit comments
50 reviews of this app found across Reddit:
What you're referring to as SystemD, is in fact systemd, not SystemD, systemD, SyStEmD, or any other variation. It is stated on https://systemd.io that the only official names are "systemd" (all lowercase even on the beginning of a sentence), or "systém D" on high holidays (whatever that means)
> What exactly is Systemd?
According to https://systemd.io/, "systemd is a suite of basic building blocks for a Linux system."
> I know it is an init system but what that means?
One part of systemd is an init system. There are other parts as well. For historical reasons, the init system of systemd is also called systemd. An init system is the first process the kernel starts on boot. It is responsible for starting everything else (in the correct order) and for shutting everything down on shutdown.
> Also how many resources does it gets from my system (ram, cpu etc.)?
As many as it needs (as long as they are available). Just like any other process that isn't limited in some way.
> Also, do I need Systemd? Are there an alternatives or stuff like that?
You do need an init system. It doesn't have to be the one from systemd. But unless you really know what you are doing, you should use the one that is supported by your distro. (Most distros support only one init system.)
> I'm just thinking to learn about Systemd and see if that causes that high RAM usage!
IMHO that is pretty unlikely.
What you're referring to as SystemD, is in fact systemd, not SystemD, systemD, SyStEmD, or any other variation. It is stated on https://systemd.io that the only official names are "systemd" (all lowercase even on the beginning of a sentence), or "systém D" on high holidays (whatever that means)
Tmpfs is for ram and swap. Why are you trying to format a disk partition with tmpfs? Do you not use a regular filesystem like ext4 for LVM?
Systemd automatically creates a tmpfs formatted folder /tmp by default. /tmp is a volatile folder that is basically stored in ram/swap. Systemd automatically creates systemd mounts for entries in fstab as well and controls the disk mounting process during boot.
https://systemd.io/TEMPORARY_DIRECTORIES/
If you want to configure /tmp manually, you will have to mask that systemd unit as stated in that Arch wiki page.
Interesting, it appears that it's something called Discoverable Partitions which allows systemd to automatically figure out your partition layout without an /etc/fstab. I never knew about that, TIL.
I'm not sure why genfstab failed though, since my first hunch is that this should work.
What you're referring to as SystemD, is in fact systemd, not SystemD, systemD, SyStEmD, or any other variation. It is stated on https://systemd.io that the only official names are "systemd" (all lowercase even on the beginning of a sentence), or "systém D" on high holidays (whatever that means)
I'm not the most knowledgeable about this topic, but I'd say look into the systemd Boot Loader Specification.
Not the exact answer, but hopefully a good jumping off point!
rc.d is the folder where the sysv init stored its scripts. For example check NetBSD's rc.d(8).
As for systemd, you can find more info in other comments on this thread, but it is both the name of a project who develops a common base for GNU/Linux systems and the name of the init of that project.
Not sure if you're okay with it, but systemd-homed offers a pretty slick experience for encryption. It only encrypts your home directory however, its not full disk encryption. I use it using fscrypt, and its awesome. You can also use it using LUKS, but IMO its much more messy that way, with many more loopback disks etc. But there are advantages to that too.
I followed this guide to transfer my user to homed: https://systemd.io/CONVERTING_TO_HOMED/
Regardless it would be good to back up your home directory first.
Split into parts: https://gitlab.com/xPMo/dotfiles.cli/-/tree/dots/.config/sway/conf.d
I have a couple unique takes:
- System control is on
$mod+F1-F4, instead of$mod+Shift+c/r/e - No split h/v bindings,
$mod+nbeing split toggle is almost always what I want anyway. - Lots of assign/for_window rules. Dedicated workspaces for web, mail, games, audio, doc. These all have numbers above 10, so they are sorted after workspaces 1:1 - 9:9, 10:X.
$mod+xenters Focus/Launch mode. In this mode, I have<key>bound to first attempt to focus a program, then launch it if no matching app_id/class is found. Then I bindShift+<key>to launch a program without trying to find an existing window first.- Example:
$mod+x, wwill focus a Firefox window (Web browser) if it exists. Otherwise, it launches Firefox. - Exception:
$mod+x, xwill runwofi -Sdrunas a program launcher. I have$mod+x, $mod+xbound for convenience as well.
- Example:
I am also trying to implement something like this when launching applications. I think using systemd-run --user --slice=app --scope may be sufficient.
It very likely won't matter, but "Linux root (x86-64)" (assuming you are actually using x64 and not installing on ARM or something) is more correct and better.
"Linux root" follows the autodiscoverable partitions specification (https://systemd.io/DISCOVERABLE_PARTITIONS/), and some programs (such as initramfs images by https://github.com/anatol/booster) can use it to automatically find your root partition.
Well, I think in such cases there's a lot of benefit from considering why some decisions were made.
Take the binary format. It wasn't some sort of accident or laziness, but designed that way completely intentionally. It makes it much faster to search, able to store binary data, and able to contain arbitrary metadata: https://systemd.io/JOURNAL_FILE_FORMAT/
Doesn't it seem kind of odd that say, Apache knows perfectly well what user accessed a thing, but then stuffs a bunch of information into a single string, which then needs to be parsed with a regex, and stuffed into a database for more comfortable analysis? Why are we doing that, rather than having a log system that can keep track of what username is associated with a log entry and query it directly?
And since we can store an arbitrary number of items per log entry, how about storing things like PIDs, the name of the binary that logged the message, and the line of code that produced it if that data is available? Why not even go further? You can configure it to write crash dumps into the log. Then they'll get shipped to your remote logging server.
Isn't it kind of silly that if we came up with a new thing for Apache to log, doing so could break our log analysis system?
Or why should it be of my concern that an interesting log entry may be found in messages, messages.1, or messages.2.gz and have to handle each of those cases?
Or here's another neat thing you can do: if you ship logs, then journald allows you to do things like interleaving the logs of the mysql server with the logs of the http server, even if they came from different machines, with one command.
- Predictable Network Interface Names
- Assuming you want to go back to the original simple naming scheme this is How to get it back
OK, I tried it. It works and the image generation is very quick!
I have some questions /u/anatol-pomozov :
- Any chance to support mounting root by fs LABEL? I copied my old bootloader entry but it failed to boot at first because I had root=LABEL=.
- I'd like to compare the boot time to my mkinitcpio image, but it's hard because systemd-analyze does not report the initrd time. I think the systemd initrd interface may be what is required for that, but I don't know. mkinitcpio seems to follow it by including an /etc/initrd-release and the switch-root binary in the image. Do you know anything more about this interface and its purpose? Does it have a place in booster now or in the future?
- The booster image is much smaller than my mkinitcpio image, but it includes more modules, mostly encryption related ones. My root fs is not encrypted, so can I turn that off?
Here are the compilation-time options. There's -Ddns-servers=<URL> where you set the fallback DNS servers.
This is indeed done at compiler-time, as every actual distro (not counting Ubuntu-based ones, at least not the ones that use literal Ubuntu repos, here) compiles and mantains their init system.
> systemd is a suite of basic building blocks for a Linux system.
One of those building blocks (the first one that was written) is an init system, and unfortunately it is also called systemd. This can lead to some confusion if some people mean the one systemd and other people mean the other systemd.
> Random ports will become eth0 etc but that's fine, as long as one of each shows up (or at least eth0)
If you don't care about which device gets which name, then the easiest way to achieve that is to disable the predictable network interface names system, see here.
I'm assuming you're talking about GPT partition types.
The partition type doesn't matter in most cases. Systemd has a solution for automatically detecting which partitions should be mounted where (see here), and it uses partition types. That's the only thing I know of in Linux that uses them. And if you manually specify which partitions should be used (e.g. in your /etc/fstab and the configuration of your boot loader), then no autodetection of partitions is necessary.
Using "Linux root (x86_64)" for your root partition is slightly more "correct" (if your system is x86_64). But it really doesn't matter.
I also used to use GRUB and now prefer systemd-boot.
One thing I found pretty cool about systemd-boot is that it can discover common partitions and auto mount them if you assign the appropriate partition UUIDs. In simple partition schemes you don't even need an /etc/fstab file. I still wish the discoverable partition spec would have support for lvm, but then I realized I didn't use lvm too often to justify the added partitioning layout complexity, so I transferred my data to plain old partitions.
I don't know of any read made tool to rebuild your .identity file. But https://systemd.io/USER_RECORD/ and https://systemd.io/HOME_DIRECTORY/ contain all the info you need to rebuild it.
The details depend on the encyption you used, if any. If you were using LUKS then there is another copy in your LUKS records you could use without needing to generate a new file.
> 1) has huge code base You do know that systemd is actually comprised of a lot (69, if I am not mistaken) different binaries with different separated tasks. Sure when you add the together 69 binaries, like 69 packages random packages on a Linux system their joined lines of code is big.
> 2) is deeply integrated within the OS
Yet, there are distributions that don't use it.
> 3) is poorly documented
> 4) is poorly audited
Source?
By the way, the 4 reasons you listed against systemd also apply to the Linux kernel.
Grub customizer doesn’t work with Fedora because Fedora uses BootLoader specification (blscfg) and all the kernel entries are in other files.
See this for more detail:
https://systemd.io/BOOT_LOADER_SPECIFICATION/
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> Keep/Back up the /home partition, rename the user directory before logging in on the new system. That way you can easily move whatever configuration files you need on an application to application basis.
Think how much simpler that will become with systemd-homed
https://systemd.io/TEMPORARY_DIRECTORIES/
> For system services systemd provides the PrivateTmp= boolean setting. If turned on for a service (👍 which is highly recommended), /tmp/ and /var/tmp/ are replaced by private sub-directories, implemented through Linux file system namespacing and bind mounts.
>Therefore, one must somehow distrust this boot path.
Using full disk encryption and unified kernel image give you true secure setup with custom keys. Tpm would make it more secure
Can you give source/more info about when removing Microsoft certificates is safe? This is the first time I hear about it and I got a little scared
What you're referring to as SystemD, is in fact systemd, not SystemD, systemD, SyStEmD, or any other variation. It is stated on https://systemd.io that the only official names are "systemd" (all lowercase even on the beginning of a sentence), or "systém D" on high holidays (whatever that means)
So apparenlty I have 6 files with custom naming schemes in /etc/udev/rules.d but as far as I can tell none of them interfere with the naming scheme of network interfaces.
I also found out where the original name of my network interface comes from:
>Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Source: https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
So now im more convinced that this is somehow a problem with my MOBO because even with my HDDs the location would randomly change so I had to label them to mount them properly, I think this is happening here where the location changes for some reason and this messes with the naming scheme.
No. wlx972728484 is the predictable interface name, wlan0 would be an unpredictable kernel name.
If you want to use another name, the penultimate paragraph lists three options.
It typically indicates some kind of misconfiguration. For example, if you have a network filesystem, but don't ensure that it is unmounted before networking is disabled, you can end up in this situation.
In the OP's case, however, something was still holding a file open inside /dev/pts. Moreover, that something somehow survived the kill spree the shutdown process does before unmounting filesystems.
On a systemd system, processes can opt out of being killed by replacing the first character of their name with an <code>@</code> sign. But this should only be used by processes started from within the initrd — i.e. they shouldn't hold onto anything inside the "real" root filesystem.
> I've set up my desktop system to connect automatically to Ethernet and VPN, and it does. But I suspect there is no guarantee that every single access during system startup and login will go through the VPN. Early accesses may be leaking my IP address to destination sites, and revealing domain names or destination IP addresses to my ISP, for example.
> Has anyone tested this ? Is there such a guarantee ? Does systemd have the concept of guarantees or policies that will be followed ?
systemd does interact with your use case to some extend. But from my reading your use case is not the focus of systemd so you won't find a ready made solution.
There are some tools for you in the systemd documentation.
However, if I was looking for some sort of guarantees I would start looking into Linux networking namespaces. My Idea being that you put most processes in a networking namespace that only allows access to the VPN interface and doesn't allow access to the real network interface. systemd user units might help with that. I haven't done it myself though.
> What does the partition layout for systemd-homed look like? Do you need a separate partition for each user?
A witten explanations is at https://systemd.io/HOME_DIRECTORY/ and talk giving a good overview ist at https://media.ccc.de/v/ASG2019-164-reinventing-home-directories
There are finally some mumblings of doing that now with GNOME and KDE talking about integrating with systemd to control process resource limits in a fine-grained way: https://systemd.io/DESKTOP_ENVIRONMENTS/
> I'd say always disable it for desktop with enough ram if you don't need hibernation. The performance gain that the author claims is negligible in either case, imo.
My opinion FOR DESKTOP is that killing processes is a better experience than thrashing making the desktop totally unresponsive. There's a reason Fedora now enables earlyoom by default.
I think an OOM daemon is an okay stopgap while we start implementing lessons learned from the server world, leveraging cgroups and systemd slices to possibly kill and restart background services under memory pressure.
>> I don't want pacman messing around with files on the ESP
> That's interesting, I thought this was a good thing, but I admittedly haven't got much experience with all this, what issues are you trying to prevent with this measure ?
Boot loaders like rEFInd and GRUB can read your /boot and kernels in it from a variety of file systems. As an example, with btrfs you can boot into different snapshots - and it really pays to have /boot separate and have pacman and mkinitcpio dump kernels and initrd there.
systemd-boot can't read btrfs, so you have to put your kernel onto ESP. In this case solutions like bind mount are very convenient.
Multi Boot Linux With One Boot Partition | John Ramsden
And Fedora / systemd-boot have specification which will only add to confusion :-)
Good luck and let us know what you've ended up settling on!
Emulating uefi environment with clover and then using some efi boot loader, haven't decided yet, probably systemd-boot and make my partitions discoverable. [1] I like the idea of stateless system.
> Maybe I could make a feature request ?
I suggest you do.
Based on my knowledge of how the journal file format works, I'm pretty sure that this would only be possible by completely rewriting the existing files; i.e. by replaying the existing entries out into a set of new files. The data structures used by the journal are specifically designed to only support append operations. Having data structures that allowed arbitrary changes to the stored set of entries would make the data structures larger and more complicated, and this would penalise everybody that didn't need this facility.
(I should point out that this is essentially what you have to do when dealing with text files, so it's not as if the journal is any "worse" at this than plain text files. There's no way to punch out specific lines from a text file and leave the remaining lines alone.)
>1. LUKS encryption is mandatory with homed.
Where does it say that?
On https://systemd.io/HOME_DIRECTORY/ and https://wiki.archlinux.org/index.php/Systemd-homed#Storage_mechanism
LUKS is just one mentioned option of several(and not even the first). This is plain wrong.
>3. Good bye, backwards compatibility. This approach totally changes how the user authenticaion takes place and directories are structured (/home is mounted from a separate loopback device in /home/$user.homedir for ex). This is obviously going to break compatibility for a lot of apps and will also need lots of testing and experiment to ensure that it works reliably. This seems like a lot of wasted efforts for little or zero gains.
I wouldn't call uncovering bugs in Software "breaking backwards compatibility"
And after all this is just an option. It might become default on many distros in the future but why would they break e.g. ssh by making it default before those problems are solved?
> Lol, you're arguing semantics. Fine, Karen— it's not a monolith, it's a massive intractable system which isn't modular and is almost impossible to replace, which controls many aspects of your system. Happy now?
No, you're just repeating the same lie even though you've been shown to be wrong. That is a list of modules.
> So much for interoperability and promises
https://systemd.io/PORTABILITY_AND_STABILITY/
As I've said, you're not interested in being wrong, you're only interested in assuming you are right.
Just write an implementation. It is reasonably well documented and not really complex. If you don't want to take advantage of dynamic nature of it and resource management, then it can even be easy.
Thank you for correcting me.
>In fact, the users doesn't even need to exist at all in the local system in order to log in, everything user related can be in the self-contained home-dir
I understood that part correctly.
> or in the LDAP/Kerberos/* server.
I will have to play a little with that because I don't know how I can trust the relation between ldap and a self-contained JSON (I suppose kerberos will get a token and the user will have to reconnect often... Which I don't find "portable"-friendly, but why not).
>Are you sure about that? AFAIK RFC 7512 PKCS#11 smartcard and yubikey tokens work with the systemd-home backend and therefore all the supported encryption mechanisms like LUKS.
I'm pretty sure my source for this was https://systemd.io/HOME_DIRECTORY/ but it seems not and archive.org say it was not changed recently so I really don't know what I misunderstood.
I'd say review the following resources. I haven't set it up myself, but a friend has. He said is still has a few rough edges.
You don't need an fstab to boot.
You only need a root partition to boot and that's given on the kernel command line. After all, you'd need to read the fstab in the root partition to do anything with it, so it wouldn't be useful for finding the root partition. Feel free to remove your root partition from the fstab generated by genfstab.
It would boot without systemd (but Arch won't work, so don't try it). systemd itself generates .mount files from fstab via systemd-fstab-generator(8) and a couple of other places with other generators according to the discoverable partitions specification.
Now, you probably want an fstab. It's useful to set up a swap partition, and you also need your ESP mounted at /boot to update the kernel easily with the linux package, so you might as well keep that in your fstab too.
Monopolized EFI files that contain the initramfs, cmdline, os-release, splash, and linux image.
More about it in Boot Loader specification
Edit: If you're using systemd-boot and these images are placed under /esp/EFI/Linux they are automatically shown as entries when booting (if embedded os-release has enough information, which is mostly the case)
That type is a property of the partition, not the data in the partition (like the file system). In general, the type being wrong shouldn't cause any problems. At least as long as you don't rely on the type (e.g. with this).
It is probably possible to change the type with fdisk without affecting the data on the partition, but I'd make a backup first just to be sure.
Forgive my ignorance, but I've looked in the manual pages, the main website, and the presentation slides and I haven't come across anything that mentions having to edit the PAM configuration to log in. Before finding this thread, it was my understanding that one would be able to log in like normal, with su or login, but now I feel like there may be a bug or a missing configuration in the systemd package. I just find it odd that an average user would have to deal with this, specially with homectl being super easy to use and straightforward.
Could I be onto something or is this the way it's supposed to be done?
In case of systemd-homed it's going to be a loop device, so the filesystem doesn't really matter. It's going to end up as a single file. Also the docs say you can only use ext4, btrfs and xfs with systemd-homed, with xfs being discouraged.
A typical The Register article: snarky headline, but clueless about anything technical.
An extremely important part of the systemd-home concept is the "unified user record" or "JSON User Records" : that is a single JSON file that can contain everything user-related. For those that need flexibility, fine grained control, and scalability in user management, this will be a revolution.
I predict, that even those organisations that have no need for portable or encrypted home-dirs, will adopt "JSON User Records". It will help that this will be backwards compatible with classic user record API's, ie. programs won't notice a difference thanks to NSS.
See more here: https://systemd.io/USER_RECORD/
From Systemd's Boot Loader Interface:
>The EFI variable LoaderEntryDefault contains the default boot loader entry to use. It contains a NUL-terminated boot loader entry identifier.
So, to fix it:
# chattr -i /sys/firmware/efi/efivars/LoaderEntryDefault-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f # rm /sys/firmware/efi/efivars/LoaderEntryDefault-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
> every time at startup there is a message of "[FAILED] Failed to start Raise Network Interfaces",
Please post the output of
sudo journalctl -b -u networking.service
> and then "A start job is running for {the name is too long for my screen and it changes as the start process continues}"
It's pretty difficult to tell what the problem is without knowing that name. Perhaps you can get it with
systemctl --failed
A few other things:
In my experience, networking.service is used mostly for servers, not for desktops, and especially not for wifi. Did you configure it manually?
Also, the messages you posted are about eth0, which is interesting for two reasons: It shows that the problem is not related to wifi. And AFAIK the default on buster is to use systemd's predictable network interface names and eth0 is not one of them.
> Could uninstalling a simple browser actually have caused it
No. But some DE metapackages depend on firefox-esr. So if you uninstall it, such a metapackage would be removed as well. And if you then run apt autoremove (without carefully reading what it proposes to remove), that might cause such problems.
Or if not systemd-boot (which I suspect some people will not want for religious reasons), at least something that follows the Boot Loader Specification. Clean interoperability is something we should all embrace.