1. 18

Original story link: https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Homed-Merged Talk: https://cfp.all-systems-go.io/ASG2019/talk/VSQRXA/

  1.  

  2. 26

    What problem does this solve, and how many folks have that problem?

    1. 14

      Having suffered for many years on NFS mounted home directories I can see the problems this aims to solve. I’d love to be able to use the same home directory across my various Linux machines.

      1. 7

        The still image from the post here seems to summarize the problems it aims to solve.

        1. 13

          No, it lists the goals of homed not what problems does it solve. To illustrate, one goal/feature is migratable home directories. Problems that would solve could be:

          • ‘I just bought a new laptop and I want to carry over all my configuration as well as Photos and other data’.
          • You’d like to share the same home directory from your $WORK PC when you work from home.
          1. 3

            I was expecting a meme of some kind.

            Almost not disappointed, these cases don’t seem worth the complexity for me the desktop user.

            1. 17

              The one that interests me is that it’ll unmount my encrypted home folder and delete the key from memory when my laptop goes to sleep, then it’ll re-mounted after I unlock from the computer.

              You know, one of those things that drove security-minded folks to start recommending iPhones.

              1. 3

                That actually is fair.

                I do wonder if this is the only solution, though. Does any other unix do this?

                Like with the stick being the cloud; back in the day there was NIS and NFS, and things pretty much worked. I wasn’t in a pure Solaris environment and Linux wasn’t this mature and it was still pretty solid.

                Maybe I’ll read up on the assorted links to see if the only reason to do this in systemd is that systemd exists everywhere already.

                1. 3

                  It’s been a loooooong time since I had a directory in NFS (actually still called AFS at the time!) but I doubt you had any sort of security against a systems administrator under that setup.

              2. 2

                How about if you move from machine to machine (“home on a stick”)?

                1. 5

                  I the desktop user could never be arsed finding a big enough stick and setting up encryption and shit on it.

                  Been moving homes between Linux installations for decades, and copying required files over a stick if network or anything hasn’t been an option.

                  So I dunno. Maybe someone wants this, and it’s a shame old geezers who want to just use Linux as easily as possible have to … ignore this and hope it never breaks, I guess.

                  1. 2

                    The “stick” is in the cloud nowadays.

              3. 2

                While locking LUKS on suspend-to-ram seems appealing, my Void Linux laptop (which doesn’t use systemd) just goes to hibernate after 30 minutes of inactivity in suspend…

              4. 2

                I really want to be able to lock LUKS on suspend. While I haven’t closely followed development of systemd-homed, my understanding from a few months back was that it will make that easier to support. (It might even include that as a feature out of the gate?)

                Given the general crappy support for hibernate to disk, and the lack of will to fully support that (I’m not willing to help with it either) I currently do a full shutdown when I want to lock LUKS.

                I’d like it a lot better if suspend would do, and I think many others would also.

                1. 3

                  This. If Linux is running off LUKS, then the key is in memory. With systemd-homed, your $HOME can encrypt without requiring a shutdown.

                  There might be better ways of doing this than requiring systemd and parsing a JSON file, but this looks like the Linux solution that currently works best.

                  This could be particularly effective for someone like me who installs all his user-facing programs in $HOME; taking my home directory with me on a USB could also carry over all my programs.

              5. 10

                I’ve been thinking more and more of “leveling up to bsd”. I’m not bothered by this a lot, but json? JavaScript and JSON are my tools, love it, but please not on a linux system service. I might just be too old, but I think unless we move lot of other tools to read and output JSON, we’ll have a mess where those system tools don’t work with each other.

                Another thing for me is the desktop use case, as mentioned in other comments. My media files are too big to live on a stick and even if the stick is the cloud, I probably still have to use cloud anyway, and sinceI’m a linux user, it’s half expected of me to then just mount the cloudstick in /mnt anyway and link to it. My work is all in the git repo, on migrating systems I just need basically the dotfiles, once per system.

                Butt on the other hand, the possibility to “hand off work” from desktop to laptop, to have my IDE plugins be totally personalized, to just resume browsing from phone to the PC… Why stop the future? In some not-so-distant utopia, I’m walking around with the said stick and just renting nearby computation as I move, my work never pausing for such peasant triviality like changing toa different computer.

                In any case, I hope they don’t make a mess :)

                1. 6

                  I’m not bothered by this a lot, but json? JavaScript and JSON are my tools, love it, but please not on a linux system service. I might just be too old, but I think unless we move lot of other tools to read and output JSON, we’ll have a mess where those system tools don’t work with each other.

                  So you would prefer a bespoke text format where you need to write a parser out of sed, cut and awk instead of a structured text format that already is widely adopted and has tools like jq to deal with it?

                  Plenty bad can be said about JSON, for sure, but what would be a sensible alternative to store structured information? TOML? Or even, gasp YAML? Or maybe you’d be happier with GNOME2-style XML?

                  1. 9

                    No, I’ve just meant that the traditionalist in me (the “I might just be too old” part hints at that) thinks we shouldn’t have to have jq available for “system service”. You need this at boot time. At boot time, you don’t want to import other tools than what already is there. Or, that is how I thought of it. So this was not about json itself, just about depending on another format in a system service.

                    1. 8

                      So you would prefer a bespoke text format where you need to write a parser out of sed, cut and awk instead of a structured text format that already is widely adopted and has tools like jq to deal with it?

                      conversely: it’s quite amazing that one can build a parser just out of a shell pipeline, isn’t it? :)

                      Or maybe you’d be happier with GNOME2-style XML?

                      as much as i dislike it, xml has nice properties given the right tools. i’ve used tdom recently and was pleasantly surprised. json for more complex usage is still full of hacks and afterthoughts, life $ref, json-schemas, etc. (xml was over designed from the start, though).

                      1. 6

                        conversely: it’s quite amazing that one can build a parser just out of a shell pipeline, isn’t it?

                        Those parsers tend to suck. What happens when your file format is tab-delimited, and someone injects a tab as contents into one of the fields? (the answer is that a lot of stuff breaks)

                        1. 2

                          what happens when i have an extra/missing delimiter in json? if one is lucky the parser tells you roughly where the position of the error is, ironically most of the time as line number :)

                          still, this isn’t my point. the fact that you can create a makeshift parser by putting together some otherwise unrelated tools is still amazing and helpful, especially for manual tasks which are not going to be repeated often.

                    2. 6

                      Both FreeBSD and OpenBSD are a breath of fresh air with regards to documentation and simplicity compared to Linux, so they’re definitely worth checking out.

                      On the other hand, you might lose some convenience compared to Linux if you use proprietary software that has Linux support (f.e. Dropbox, Steam). It’s a bit like using Linux 20 years ago :-D

                      1. 3

                        I’ve interacted with JSON in a hobby project and I’m seeing it as a format for external data feeds at work. In neither case is JS involved.

                        JSON is basically structured text now, filling the same niche as XML.

                        1. 3

                          Yes, it’s super easy to use, I get that. That was not my point.

                          1. 2

                            OK. What form of structured text would be more appropriate, in your opinion?

                            1. 3

                              I’d prefer a format that supported comments. Probably toml, but there’s also some JSON variants that do.

                              1. 1

                                That’s a good point. I’d like to see an example of this proposed file, if it’s a dozen entries the key names may be enough to comment the format.

                      2. 8

                        Does someone have a proper doc on this I could replace this thin blog post with?

                        1. 5

                          There is the document on homed itself here: https://systemd.io/HOME_DIRECTORY/

                          The merge request is here, merged 10 days ago: https://github.com/systemd/systemd/commit/4119d1e60a111bacca359b61b5bc3dae29932b67

                          1. 8

                            Inside of the home directory a file ~/.identity […]

                            How about no?

                            Landing systemd-homed adds over twenty-one thousand lines of code to systemd.

                            All written in one of the most dangerous and unsafe languages ever invented.

                            1. 13

                              All written in one of the most dangerous and unsafe languages ever invented.

                              Just like the vast majority of the code in Unix/Linux…

                              1. 12

                                I think it’s reasonable to accept the state of existing applications, but at the same time not wanting to add more gasoline to the tire fire.

                                (Another example: My home directory is read-only. Existing applications continue to work, but new applications better not dump their stuff into $HOME, because that just won’t work.)

                                1. 2

                                  What’s the best language to replace C? Rust? I’ve read a lot about how the multi-platform support simply isn’t there yet.

                                  1. 9

                                    To be frank, systemd’s one and only platform is Glibc/Linux, well supported by rust.

                                    1. 2

                                      This is true, systemd doesn’t really target anything other than Linux, and x86 is probably the most dominant platform.

                                    2. 7

                                      Rust multi-platform support in general is very good. The whole toolchain is build with cross-compilation in mind and it avoids hard to rely on specifics.

                                      But the set of platforms Linux has been ported to through GCC and that LLVM (and thus Rust) has support for are not the same. Also, some smaller platforms needs some practical care. e.g. we track ~5-10 bugs on OpenWRT that have more to do with specifics of their SDK/library layout then anything language related. Someone with OpenWRT knowledge will probably get that fixed in a week or so. Some of them are filed by me, but I only used OpenWRT at a glance and we don’t do “amateur fixes”. It’s not like Rust programs don’t run on OpenWRT, but they are a little too big, which just isn’t acceptable on that platform.

                                      So… Yessish, Rust is an option, if you are willing to help the project out a little.

                                      Also, when systemd started, Rust was an experimental language, so I would call support abysimal ;).

                                      1. 2

                                        Thanks a lot for this clarification.

                                2. 8

                                  Yeah we finally establish standards for not littering home directories with dotfiles beyond what we absolutely necessarily need and systemd just goes and shits all over that with yet another path directly under $HOME.

                                  1. 5

                                    It’s pretty much the “our rules are for other people to follow” crowd, same as Flatpak (”.var is fine, because we decided it’s fine, and if you don’t like it we will just add it to the XDG spec to say it’s fine”).

                                3. 4

                                  Hahahaha, you need to use a command line utility to generate json to tell your init system how to mount your home directory? This is insanity and I’m glad I’m not using a SystemD/Linux distribution.

                                  1. 25

                                    No, you don’t tell your init system how to mount your home directory. You tell systemd-homed, a separate daemon, how to mount your home directory. PID 1 isn’t involved.

                                    1. 3

                                      whew. I actually thought this was going to be merged into the main systemd codebase and would run as PID1 :D

                                      1. 7

                                        IIRC SystemD is a fleet of processes to avoid growing the amount of risky stuff in PID1.

                                        1. 5

                                          A monolith divided into too many processes is still a monolith.

                                          Schrodinger’s systemd: systemd is both just a better init replacement and the infrastructure of an entirely new OS, as is required in any given context to avoid criticism.

                                          1. 5

                                            Don’t get me wrong: there’s good reasons to criticise systemd.

                                            However, the people who volunteer their time to maintain distros have largely decided it solves problems they have.

                                            It’s definitely not ‘just a better init replacement’. It’s huge. However, there’s quite a few things that get criticised which are perfectly sensible.

                                            For instance:

                                            • Using JSON, a serialization format with multiple mature parsers, instead of inventing one.
                                            • Using multiple processes to reduce the surface area of PID 1 (no, it’s not perfect. Yes, it is better than jamming stuff into PID1).
                                          2. 6

                                            Whoa, don’t go spoiling the systemd hate with facts! If it’s not exactly the same as 4.2BSD on my VAX 11/750 then it must be un-unixy.

                                            1. 7

                                              Last time I checked /bin/systemd was about 2.5M, which still seems pretty large to me. More importantly, splitting systemd in separate processes is mostly an unimportant implementation detail; a lot of depends on each other and isn’t crash-resistent at all. Even restarting dbus will completely crash systemd, which is “fun” when your dbus no longer works correctly for some non-systemd related service and you think systemctl dbus restart is safe. It’s not and will crash your logind resulting in an irrecoverably broken system requiring a reboot 😐

                                              So, if we want to be flippant about it, then “ackchyually it’s not PID 1” is just an easy way to deflect criticism without actually having to engage in what the other person said.

                                              1. 4

                                                Even restarting dbus will completely crash systemd, which is “fun” when your dbus no longer works correctly for some non-systemd related service and you think systemctl dbus restart is safe. It’s not and will crash your logind resulting in an irrecoverably broken system requiring a reboot 😐

                                                I ran systemctl restart dbus on my machine for fun. systemd exists gracefully and kills all processes. Looking at the journal vim and spotify segfaulted (coredumpd picked them both up). Back at tty and able to log back into the system. The only process that really didn’t like this was NetworkManager which didn’t start after the login.

                                                I’m not too confident any of this hold true unless this is an experience from years ago and the situation has improved.

                                                1. 5

                                                  I don’t have access to a systemd system right now, but this was last year on my Arch Linux machine. It might depend on your configuration/version and whatnot, but a quick internet search reveals I’m hardly the first person with this issue (e.g., many more). One of the downsides of systemd is that it works fairly well when it works, but is really complex and hard to debug when it doesn’t.

                                                  Having all your programs crash is also not exactly great behaviour IMHO, but better than forcing a reboot.

                                                  1. 2

                                                    It might depend on your configuration/version and whatnot, but a quick internet search reveals I’m hardly the first person with this issue (e.g., many more).

                                                    People writing “It crashes” on stack overflow with no logs tells me they have the same behavior as I’m experiencing. Logs would prove otherwise, but I doubt that is the case.

                                                    Having all your programs crash is also not exactly great behaviour IMHO, but better than forcing a reboot.

                                                    Just two out of a lot. I assume enabling lingering would leave more of them untouched, but probably in a broken state when dbus is restarted.

                                                    1. 2

                                                      First search result: https://bugzilla.redhat.com/show_bug.cgi?id=1623651

                                                      I thought there was some GitHub issue for it too, but can’t find that right now. Either way, it still crashed for me last year, so…

                                                      Just two out of a lot.

                                                      Wait, you said that “systemd exists gracefully and kills all processes”?

                                                      1. 2

                                                        First search result: https://bugzilla.redhat.com/show_bug.cgi?id=1623651 I thought there was some GitHub issue for it too, but can’t find that right now. Either way, it still crashed for me last year, so…

                                                        Nice bug, but systemd is still not crashing. Restarting dbus is going to be wonkey and there will be bugs as there is no nice way of handling this.

                                                        Wait, you said that “systemd exists gracefully and kills all processes”?

                                                        Yes. Killing processes does in no way imply they crash. Sending SIGKILL should be handled by the process, after all.

                                                        1. 4

                                                          Oh c’mon, this is being pedantic to the point that it’s difficult to take in good faith. If restarting a system daemon stops all your processes then it’s a crash for all intents and purposes. Replying with “yeah but it doesn’t segfault” just comes off as trying to “win” an argument.

                                                          And this is why people get so frustrated and angry with systemd, because far too often they’re being told it’s “not a problem”. Well, having all my apps being stopped is a problem, segfault or not. I still had all my apps stopped and potentially lost my work. It’s also not something that seems to happen with other init systems, so for all intents and purposes this is a systemd problem.

                                                          1. 2

                                                            Oh c’mon, this is being pedantic to the point that it’s difficult to take in good faith.If restarting a system daemon stops all your processes then it’s a crash for all intents and purposes.

                                                            I think it’s more of what you expect when you claim “systemd crashes when you restart dbus”. I’m genuinely expecting poor handling, but all I see is systemd doing what it’s suppose to be doing. systemd killing your processes when you log out is expected behavior unless you enable lingering after all.

                                                            Replying with “yeah but it doesn’t segfault” just comes off as trying to “win” an argument.

                                                            Well yes. You are claiming restarting dbus results in a “irrecoverably broken system requiring a reboot”. But I have yet to see anything like that.

                                                            It’s also not something that seems to happen with other init systems, so for all intents and purposes this is a systemd problem.

                                                            You’d see this behavior with any software that depends on a central message bus. dbus handover was never proper even before the systemd merge, and It’s hard to see how this would change. The issue you linked above also echos notes the limitations you have when restarting debus.

                                                            1. 2

                                                              systemd killing your processes when you log out is not normal or expected behaviour and when it was introduced there was a lot of criticism of systemd. tmux shouldn’t need systemd-specific code to say ‘hey dont kill me when he logs out’.

                                                              Well yes. You are claiming restarting dbus results in a “irrecoverably broken system requiring a reboot”. But I have yet to see anything like that.

                                                              Because that was his experience.

                                                              You’d see this behavior with any software that depends on a central message bus.

                                                              Restarting dbus shouldn’t kill any processes, even those that use dbus. It’s a message bus. Restarting it should just queue up messages.

                                                              1. 2

                                                                systemd killing your processes when you log out is not normal or expected behaviour and when it was introduced there was a lot of criticism of systemd. tmux shouldn’t need systemd-specific code to say ‘hey dont kill me when he logs out’.

                                                                Feel free to disagree about expected functionality and what you personally think is correct behavior. It’s documented and there are options to turn off these features.

                                                                Because that was his experience.

                                                                Yes, and he is free to share his experience. But the claim is that systemd “isn’t crash-resistent at all” and that it “will crash your logind resulting in an irrecoverably broken system requiring a reboot”, which is what I’m unable to replicate. I have a hard time believing this is true unless there is more to the issue.

                                                                Restarting dbus shouldn’t kill any processes, even those that use dbus. It’s a message bus. Restarting it should just queue up messages.

                                                                I’m confused. The previous linked bugreport is an issue because there is a timeout on the socket connection. How would you queue up the messages if the dbus socket is not accepting them regardless?

                                                                1. 1

                                                                  Feel free to disagree about expected functionality and what you personally think is correct behavior. It’s documented and there are options to turn off these features.

                                                                  I know what is correct behaviour because it’s been correct behaviour for decades. systemd is, as usual, wrong and broken.

                                                                  It shouldn’t need to be turned off. It should need to be turned on. Breaking loads of programs and forcing them to write systemd-specific code because of the personal preferences of one systemd developer is complete madness.

                                                                  I have a hard time believing this is true unless there is more to the issue.

                                                                  There are thousands of cases of serious bugs in systemd, why are you surprised by this one?

                                                                  I’m confused. The previous linked bugreport is an issue because there is a timeout on the socket connection. How would you queue up the messages if the dbus socket is not accepting them regardless?

                                                                  By designing dbus differently in the first place. Obviously if dbus is down you should queue up messages to be sent when it comes back up.

                                                  2. 3

                                                    I ran systemctl restart dbus on my machine for fun. systemd exists gracefully and kills all processes.

                                                    Killing all my processes because I want to restart dbus is not ‘graceful’ in my book.

                                          3. 4

                                            Doesn’t mean it won’t become mandatory to run after a short while, like pretty much every other “stop worrying, it will always be optional” feature.

                                            1. 5

                                              Sure, that may happen, and it might be a valid criticism. You could also criticize how, even though everything is in separate processes, there are so many interdependencies through nonstandard DBus APIs and whatever that the systemd is too monolithic. Or you may criticize them for reimplementing existing tools and pushing the new versions before the bugs have been ironed out. Or for deprecating C API calls and asking projects to instead use a DBus interface.

                                              My position is that systemd overall probably is a good thing, but if you’re going to criticize it, that criticism better be based in fact. There’s enough bad crititique of systemd out there already.

                                              1. 3

                                                systemd is uniquely held immune from criticism. Any reasonable criticism of systemd has to be couched in a lot of meaningless phrasing so as to avoid being seen as being too negative. If you’re too negative about systemd (which is badly written and badly designed in every way I know that software can be badly written and badly designed, which is not an exaggeration) then you get downvoted as a ‘troll’ even if your criticisms are entirely valid.

                                          4. 1

                                            They have adressed this: this is generally an issue with the base CLIs not supporting JSON manipulation and generation and they didn’t want people to hand-write it. systemd is at a place where accidentally breaking the configuration file syntactically may make your system not boot.

                                            They still wanted to use a generally and widely supported format.

                                            1. 1

                                              There’s already a generally and widely supported format: /etc/passwd, which specifies where my home directory is perfectly well already.

                                              1. 2

                                                That’s not the point. The OP was complaining that they ship JSON tooling, which is a reasonable second-order decision after deciding to use JSON as a format.

                                                /etc/passwd is still a custom format, where even syntactical validation is not available as a standalone tool. I’ve spent a couple of years using and training puppet/chef and mistakes when generating/parsing /etc/passwd and similar files for providers is a very nice way to experience the bolted on mess that Unix is. Validating even just the correctness of such formats basically equates to “generate it, see if the system still works”.

                                                1. 1

                                                  The complaint was about the use of JSON in the first place. The need to have code to deal with a format is obviously a necessary consequence of the poor decision to use the format in the first place.

                                                  The point is not the format of /etc/passed but that the world already has a mechanism for specifying home directory location. This entire mechanism is just yet another example of systemd reinventing the wheel because it has the social power to do basically anything it likes due to its monopoly on init across almost every distro.

                                                  This feature cream is what we warned would happen if systemd were adopted almost everywhere, but did anyone listen? Of course not.

                                                  1. 2

                                                    The point of homed is to fundamentally change the integration of home directories into the operating system (and thus make them easily to migrate without changes to the base system), so /etc/passwd is a bad mechanism for that.

                                                    That has been sufficiently addressed by the systemd team.

                                                    Who’s the “we” you are speaking of, by the way. systemd adoption indicates there’s a substantial “they”.

                                                    1. 1

                                                      That has been sufficiently addressed by the systemd team.

                                                      No, it has been stated outright by the systemd team. It hasn’t been justified properly at all. Nowhere have they addressed why it “needs” to be done this way, what the alternatives are, how it could be done in a less disruptive way, any issues with doing it other ways, or any of that, because they’ve realised over time they don’t NEED to justify their actions. They maintain software that is now tightly integrated into every major Linux distribution that they can do whatever they want and people just have to accept it unless they want to fork it and maintain the now-massive codebase that is systemd.

                                                      Who’s the “we” you are speaking of, by the way. systemd adoption indicates there’s a substantial “they”.

                                                      The thousands and thousands of people that pointed out the inevitable issues with systemd when it was being adopted by major Linux distributions as their init systems, but who were ignored and called ‘trolls spreading FUD’.