On 2022-04-27 17:34:17-0400, Jonathan Billings wrote:
> On Apr 27, 2022, at 07:25, Justin Moore
> In general, the way I suggest debugging these kinds of hangs at
> shutdown/reboot are to run:
>
> journalctl --boot=-1 --reverse
One thing to note.
I got bitten by the following quite recently:
[la
On Apr 28, 2022, at 07:05, Justin Moore wrote:
>
>
>> On Wed, Apr 27, 2022 at 5:35 PM Jonathan Billings
>> wrote:
>
>>
>> Just as much as frustrating as people who say “systemd is evil” and because
>> it has bugs it should be tossed out entirely.
>
> That attempted equivalence doesn't ack
On Wed, Apr 27, 2022 at 5:35 PM Jonathan Billings
wrote:
>
> Just as much as frustrating as people who say “systemd is evil” and
> because it has bugs it should be tossed out entirely.
>
That attempted equivalence doesn't acknowledge the power imbalance in the
situation. The "systemd can't possi
On Apr 27, 2022, at 07:25, Justin Moore wrote:
>
>
>> On Tue, Apr 26, 2022 at 6:06 PM Jonathan Billings
>> wrote:
>
>> [snip] Could systemd do a better job saying what it was waiting on? Yes.
>> Is it so horribly broken it doesn’t know how to exit? No.
>
> This kind of blanket dismissal
On Tue, Apr 26, 2022 at 6:06 PM Jonathan Billings
wrote:
> >> The systemd --user daemon does hang around though, and it is likely it
> is waiting on terminating some pesky user process that wasn’t terminating
> properly. It isn’t the blocking process, it is the daemon trying to
> terminate it.
>
On Tue, 26 Apr 2022 18:05:39 -0400
Jonathan Billings wrote:
> Most likely it was trying to remove something from the session (such as a
> mount) that wasn’t responding. The user daemon itself will terminate once
> the session has been terminated.
Not even close. No mounts, no resources used a
On Apr 26, 2022, at 17:58, Tom Horsley wrote:
>
> On Tue, 26 Apr 2022 17:41:34 -0400
> Jonathan Billings wrote:
>
>> The systemd --user daemon does hang around though, and it is likely it is
>> waiting on terminating some pesky user process that wasn’t terminating
>> properly. It isn’t the bl
On Tue, 26 Apr 2022 17:41:34 -0400
Jonathan Billings wrote:
> The systemd --user daemon does hang around though, and it is likely it is
> waiting on terminating some pesky user process that wasn’t terminating
> properly. It isn’t the blocking process, it is the daemon trying to terminate
> it.
On Apr 25, 2022, at 21:17, Tom Horsley wrote:
>
>> On Mon, 25 Apr 2022 16:45:41 -0400
>> Jonathan Billings wrote:
>>
>> if you want it to, it will terminate all user processes *for that session*
>> when it logs out
>
> This only recently started working moderately well. If I ever ssh'ed into
>
Jonathan Billings writes:
> There are several features in systemd that directly benefit the
> desktop.
Sure, but the ones you mention don't benefit me and people like me. I
can't imagine why I would even notice them on my personal desktop.
The odd man out (and thank you for mentioning enterpr
On Mon, 25 Apr 2022 16:45:41 -0400
Jonathan Billings wrote:
> if you want it to, it will terminate all user processes *for that session*
> when it logs out
This only recently started working moderately well. If I ever ssh'ed into
my desktop for a separate login session, systemd would create some
On Apr 23, 2022, at 22:36, Stephen J. Turnbull wrote:
> As far as I know there isn't really a technical argument for systemd
> or any particular systemd.* on Fedora workstations. The various
> traditional inits and daemons work fine in that environment.[1]
There are several features in systemd
On Mon, 2022-04-25 at 14:50 +0900, Stephen J. Turnbull wrote:
> You make me curious what experience in open source maintenance you
> have.
I got involved in the mailing lists for non-open source programs on the
Amiga, that'd be in the 1990s, where some program authors were
promoting user-input. W
Michael Hennebry writes:
> The point seems to have been missed.
The same could be said here, but it would be valid.
> The primary salutary effect of a *collective*
> decision would be on prospective smokers,
> e.g. children.
You make me curious what experience in open source maintenance you
On Sun, 2022-04-24 at 10:48 -0700, Kevin Fenzi wrote:
> The scriptlets will set /etc/resolv.conf to point to the
> systemd-resolved resolver if:
>
> * The /etc/resolv.conf file doesn't exist yet
> AND
> * systemd is being used to boot (so, it's not a container, etc)
> AND
> * systemd-resolved ser
On Sun, Apr 24, 2022 at 12:00:50PM -0500, Michael Hennebry wrote:
> On Sat, 23 Apr 2022, Samuel Sieb wrote:
>
> > The benefits have been well explained. The problem is that some people
> > really don't like change even if it's for the better. And sometimes
> > things do break when changed and in
On Sat, 23 Apr 2022, Samuel Sieb wrote:
The benefits have been well explained. The problem is that some people
really don't like change even if it's for the better. And sometimes things
do break when changed and instead of finding out why it breaks and how to
fix, they just say how terrible
On Sun, 24 Apr 2022, Stephen J. Turnbull wrote:
Michael Hennebry writes:
> One way to get rid of smoking would be for non-smokers
> to make a collective decision to make fun of smokers.
That might work for smoking, although more likely because the smokers
will leave when they see you coming,
On Sun, 24 Apr 2022 07:54:11 -0400
Jonathan Billings wrote:
> There are several features in systemd that directly benefit the
> desktop.
[snipped information]
Thanks, that was interesting.
___
users mailing list -- users@lists.fedoraproject.org
To uns
On Apr 23, 2022, at 22:36, Stephen J. Turnbull wrote:
> As far as I know there isn't really a technical argument for systemd
> or any particular systemd.* on Fedora workstations. The various
> traditional inits and daemons work fine in that environment.[1]
There are several features in syste
On 4/20/22 08:04, Petr Menšík wrote:
Could repeated flames around systemd mean something is wrong with the
way systemd introduces new features?
If people complain often, maybe those changes should have been made in
opt-in mode. Especially on upgrades from previous releases. The
mentioned change
Michael Hennebry writes:
> I also know of no technical argument on the
> fedora forum that persuaded fedora's authors.
As far as I know there isn't really a technical argument for systemd
or any particular systemd.* on Fedora workstations. The various
traditional inits and daemons work fine in
On Fri, 22 Apr 2022, Jerry James wrote:
On Fri, Apr 22, 2022 at 10:24 AM Michael Hennebry
wrote:
Does making fun of *code* violate either?
Maybe, maybe not. But it doesn't do any good either. Are you aware
of a single instance of somebody making fun of code, and the author of
said code the
On Fri, Apr 22, 2022 at 10:24 AM Michael Hennebry
wrote:
> Does making fun of *code* violate either?
Maybe, maybe not. But it doesn't do any good either. Are you aware
of a single instance of somebody making fun of code, and the author of
said code then saying, "Oh, now that you have made fun o
On Mon, 18 Apr 2022, Todd Zullinger wrote:
Tom Horsley wrote:
Nah! It is the first computer fungus, slowly growing over all the rest of Linux.
With a very grudging list admin hat on...
Before anyone feels the need to pile onto this thread,
please carefully read the Fedora Code of Conduct a
On Wed, 20 Apr 2022 17:04:39 +0200
Petr Menšík wrote:
> Could repeated flames around systemd mean something is wrong with the
> way systemd introduces new features?
>
> If people complain often, maybe those changes should have been made in
> opt-in mode. Especially on upgrades from previous rele
Could repeated flames around systemd mean something is wrong with the
way systemd introduces new features?
If people complain often, maybe those changes should have been made in
opt-in mode. Especially on upgrades from previous releases. The
mentioned change were invasive and has broken multiple s
On Apr 18, 2022, at 20:58, Matthew Miller wrote:
>
> It's fine for you to discuss the technical aspects — and even the "merits",
> as you said. But if that's what you want to do, do that. Several years ago,
> all of the vitriol and trolling on this list got so bad we had to shut down
> pretty muc
On Mon, 2022-04-18 at 20:57 -0400, Matthew Miller wrote:
> This is quite missing my point. I'm not interested in _arguing_ at
> all. The point is: your hyperbole about "hijacking" and etc. is not
> appropriate. This is an intentional, discussed, and approved change
> that went through the proper pr
On Mon, Apr 18, 2022 at 07:47:28PM -0400, Sam Varshavchik wrote:
> This looks like an appeal to authority, and not an argument on its
> own merits.
>
> But let's go back and revisit all of that, if you insist.
This is quite missing my point. I'm not interested in _arguing_ at all. The
point is
Matthew Miller writes:
On Sun, Apr 17, 2022 at 06:34:48PM -0400, Sam Varshavchik wrote:
> but it was mostly working, so stayed under the radar, until the
> recent update broke it. Additionally, the systemd-resolved rpm is
> actively hijacking /etc/resolv.conf. From the package's scriptlet:
Sam,
Tom Horsley wrote:
> On Mon, 18 Apr 2022 23:35:35 +0200
> Bob Marcan wrote:
>
>> Better for users? Are you kidding?
>> All this systemd is reinventing the wheel.
>> Go back to Windows, when you grow up.
>
> Nah! It is the first computer fungus, slowly growing over all the rest of
> Linux.
With
On Mon, 18 Apr 2022 23:35:35 +0200
Bob Marcan wrote:
> Better for users? Are you kidding?
> All this systemd is reinventing the wheel.
> Go back to Windows, when you grow up.
Nah! It is the first computer fungus, slowly growing over all the rest of Linux.
_
On Mon, 18 Apr 2022 15:29:01 -0400
Matthew Miller wrote:
> On Sun, Apr 17, 2022 at 06:34:48PM -0400, Sam Varshavchik wrote:
> > but it was mostly working, so stayed under the radar, until the
> > recent update broke it. Additionally, the systemd-resolved rpm is
> > actively hijacking /etc/resolv.
On Sun, Apr 17, 2022 at 06:34:48PM -0400, Sam Varshavchik wrote:
> but it was mostly working, so stayed under the radar, until the
> recent update broke it. Additionally, the systemd-resolved rpm is
> actively hijacking /etc/resolv.conf. From the package's scriptlet:
Sam, can you _please_ not use
Gordon Messmer writes:
On 4/17/22 12:26, Sam Varshavchik wrote:
I don't see where it's picking this up. The only thing I can think of is
nsswitch.conf, but the "hosts" entry there is identical to what's on
another, un-upgraded system.
Maybe remove the "resolve" entry from the hosts line:
On 4/17/22 12:26, Sam Varshavchik wrote:
I don't see where it's picking this up. The only thing I can think of
is nsswitch.conf, but the "hosts" entry there is identical to what's
on another, un-upgraded system.
Maybe remove the "resolve" entry from the hosts line:
$ rpm -qf /lib64/libnss_r
37 matches
Mail list logo
