Salta al contenuto principale


systemd-tmpfiles, deleting /home

TIL (thankfully second hand) that running "systemd-tmpfiles --purge" will delete /home in systemd 256 [1]. Apparently if you think linux is mainly for running cloud services, this seems reasonable to you. Or something.

[1] tested with systemd-tmpfiles --dry-run --purge on debian. I guess it _could_ be a Debian addition, but I'm guessing not.

in reply to David Bremner

systemd-tmpfiles, deleting /home
Home is temporary, David, for we are mere mortals
in reply to David Bremner

systemd-tmpfiles, deleting /home

@David Bremner

I really hope that command isn't run *automatically*, right?

in reply to Elena ``of Valhalla''

@valhalla No, it's not. According to someone-who-should-know, it's intended to be a "factory reset" command. But alas, it is too easy to think that "oh, I should use this nice command to clear /var/tmp".
in reply to Snausages

@Snausages @valhalla the problem was that the documentation specifically said (paraphrasing) "deletes all files listed in the tmpfiles.d configuration" which, I mean, I would have certainly expected the configuration list tmpfiles.d would be a list of temporary file directories. But it's not! It got overloaded to do other things also.
in reply to David Bremner

no please! That's an horrible misleading option. It's systemd-tmpfiles, not systemd-userfiles.
in reply to David Bremner

systemd-tmpfiles, deleting /home
what is your systemd-tmpfiles --cat-config?
in reply to shironeko

@shironeko The full output would require a thread, but it contains in particular
# /usr/lib/tmpfiles.d/home.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

# See tmpfiles.d(5) for details

Q /home 0755 - - -
q /srv 0755 - - -

in reply to David Bremner

systemd-tmpfiles, deleting /home
Haha that content warning
in reply to David Bremner

systemd-tmpfiles, deleting /home
excuse me what the fuck
in reply to David Bremner

systemd-tmpfiles, deleting /home

systemd is an abomination. I still can't fathom why the mainstream ran with it.

Why does anyone listen to Poettering? Why?

in reply to David Bremner

systemd-tmpfiles, deleting /home

I haven't understood the full details, but I hope this doesn't infect my devuan installations in the way that the so-called "usrmerge" did.

My direct relationship with debian ended on the day I retired. Unfortunately, devuan depends on a lot of upstream packages from debian. From my viewpoint it sometimes seems that systemd is taking over everything.

in reply to David Bremner

systemd-tmpfiles, deleting /home
Lennart working for Microsoft makes more sense now.
in reply to David Bremner

systemd-tmpfiles, deleting /home

I would love to say that I am surprised by this.

But I am not.

systemd is shite. There, I said it.

Unknown parent

David Bremner
systemd-tmpfiles, deleting /home
@linus It's an upstream choice. They may reconsider in future releases, but that is upstream default configuration in release 256.
in reply to David Bremner

systemd-tmpfiles, deleting /home
and then ypu have snapnwhich forces you to have your home in /home.
I bet there is a snap&systemd conspiracy!
in reply to David Bremner

systemd-tmpfiles, deleting /home
Seriously, I don't know who is responsible for that decision, but considering /home under the umbrella of "tmpfiles" is way off the "how arrogant you are" chart. I'd suggest them to get off from that high horse and shift their focus from their mighty software to their users instead. I can reinstall or repair OS' from tons of sources, which is not true for my unique (and obviously more important) data.
in reply to David Bremner

systemd-tmpfiles, deleting /home

Related:

commit 9ebcac3b5125a8b0b11f371731ea167cd4684adc
Author: Nick Rosbrook <enr0n@ubuntu.com>
Date: Fri Jun 14 17:31:22 2024 -0400

man: add a bit of a warning to systemd-tmpfiles --purge

Mention that by default, /home is managed by tmpfiles.d/home.conf, and
recommend that users run systemd-tmpfiles --dry-run --purge first to
see exactly what will be removed.

in reply to David Bremner

systemd-tmpfiles, deleting /home

"systemd-tmpfiles: unrecognized option '--dry-run'"

???

in reply to David Bremner

The fun thing is that every reply to this post is now censored with the content warning by default. πŸ˜‚ Thanks Mastodon
in reply to Kaito

@kaito02 Indeed my use of content warnings as subjects has been critiqued in the past, but I blocked those people, now everybody is happy!
in reply to David Bremner

systemd-tmpfiles, deleting /home
We should check if Lennarts account was compromised. The commit where this was introduced (fed2b07ebc9e8694b5b326923356028f464381ce) does not mention that /home will be now be purged. It only states some unrelated stuff about btrfs subvolumes and read-only rootfs. This looks very suspicious to me.
in reply to David Bremner

systemd-tmpfiles, deleting /home
btw, i am not sure why involve systemd-tmpfiles with that though? Just call "rm -rf /home"? requires same privs, and is shorter?
in reply to David Bremner

Original reporter here! Just learned about this thread, seems like a lot of people here direct unnecessary hate towards the project.
The fact this option *exists* isn't wrong, it just wasn't documented well and could possibly be invoked by accident (though the latter wasn't what I was dealing with).
Both of these have been rectified and await release.
All projects (and especially docs) have bugs, so we shouldn't judge them based on bugs alone, but rather on how reports are received.

David Bremner reshared this.

in reply to David Bremner

systemd-tmpfiles, deleting /home
AI taking over - (l)users are just a temporary annoyance
in reply to Ariadne Conill 🐰:therian:

re: systemd-tmpfiles, deleting /home

@ariadne --purge (newly added) is a "factory reset" option and `/home` is in the default confs as a subvolume, so... yeah

it's quite clear about what it does, so don't run --purge unless it's really really really what you want to do (--clean is probably what you are looking for) :)

in reply to nina

@q66 @ariadne Has anyone actually filed the fucking bug against systemd yet?

_EDIT:_ Yes, and wow holy shit the first developer reply:
github.com/systemd/systemd/iss…

Questa voce Γ¨ stata modificata (9 mesi fa)
in reply to nina

@q66 @jnpn @apicultor @ariadne
Never seen that before, but a brief glance suggests that they are mostly interested in ranting rather than cooperative action.
in reply to okanogen VerminEnemyFromWithin

@Okanogen @dashdsrdash @jnpn @apicultor @ariadne what is devuan doing other than endlessly holding onto shellscripted boomerware in their 2010-ass distro and building a community of chuds and flatearthers

(well, to be fair, they did write a libseat support patch for xorg, but i can't really think of anything else)

in reply to nina

@q66 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne
Have you considered that some of us just want systemd to leave us alone and not find exciting new ways to break things and confuse us?
BTW I'm a millennial/borderline zoomer, not everyone who dislikes systemd was born in the 50's. Or is a "chud" or "flat-earther." Some people just like different things than you do.
Does liking anarchy only apply when red hat/IBM isn't ultimately calling the shots? Or is this some form of anarcho-capitalism.
in reply to Wyatt (πŸ³οΈβ€βš§οΈβ™€?)

@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne this is super funny to me because

1) have you been to the devuan forums? if not i suggest taking a look
2) ftr i strongly dislike systemd and am actively driving efforts to have properly portable session tracking and the likes without nasty and deficient workarounds like elogind

any accusation against me that i'm a part of some kind of ibm conspiracy is both hilarious and sad

in reply to nina

@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne the reason I make fun of the anti-systemd crowd is not because i approve of systemd but because said crowd has failed to do anything to address what systemd is actually addressing in practice over the years (and what people in the end care about)

"it was already fine" is a terrible mindset to have, and if you don't want to see systemd take over completely, you better get rid of that, or it absolutely will

in reply to nina

@q66 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne it already has, and I will say that even if the use case exists, it doesn't need to be forced on everyone. The reason everyone doesn't use Jackd even though it's an awesome idea for linux audio. Not everyone wants to deal with its breakages.
in reply to Wyatt (πŸ³οΈβ€βš§οΈβ™€?)

@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne the reason everybody doesn't use jackd for audio is because it's highly impractical for most regular audio cases

(inflexible routing, deals badly with device removal and restarts, etc.)

systemd has been "forced" on everyone because distros found it practical and fit their use case the best; sticking your head in the sand just makes things even worse

in reply to nina

@q66 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne I have no way of convincing you that you should be more compassionate about others, but I would ask that you take a step back and remember that we are all humans with different lived experiences and that other peoples' are no less valid than your own.
It is clear I can't say anything that will change your mind.
in reply to Wyatt (πŸ³οΈβ€βš§οΈβ™€?)

@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne ok, let's put it another way - you can do and use whatever you like, but don't be mad when other people stop caring about supporting your usecases

the "traditional" inits and whatever on linux have long been a source of issues due to cargo cult complexity and resulting issues like lack of process supervision, lack of a safe session/seat handling interface, lack of user services, etc.

Questo sito utilizza cookie per riconosce gli utenti loggati e quelli che tornano a visitare. Proseguendo la navigazione su questo sito, accetti l'utilizzo di questi cookie.

⇧