Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Frans de Boer

On 28-08-19 14:41, Lennart Poettering wrote:

On Mi, 28.08.19 09:33, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:


Hi!

systemd in SLES 12 is causing endless frustration here:

Yesterday I was migrating some filesystems to a new device (multipath, MD-RAID, 
LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other files as 
needed.
After migration was successful, I also cleaned up the now obsolete resources 
(multipath, MD-RAID, filesystem, mountpoints, etc.)
Everything looked OK...

But some time later the application was stopped, as the new
filesystems were unmounted by systemd (even though active processes
were using it) WITHOUT giving a reason for "Stopped target Local
File Systems" in syslog. Instead systemd tried to mount the
filesystems that had been removed from /etc/fstab!

You need to issue "systemctl daemon-reload" when updating this file,
systemd only takes notice of changed configuration files when you
issue that.

This is documented widely, for example here:

https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

Moreover, well-meaning distributions would most likely include a
comment about this in /etc/fstab to make this discoverable easily by
the admin. On Fedora you'll find this comment at the top of the file
for example:


# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.


systemd does not automatically reload configuration files when they
change since that is inherently racy: systemd reads a larger number of
unit files and other configuration files and simply by watching file
changes with inotify we cannot know when the right time is to reload
configuration: we might end up seeing some of the old
unit/configuration files and some of the new unit/configuration files,
as they are manipulated if we reload at the wrong time. For example,
consider the case where you rename a unit file: there is likely a
timeframe where enumerating all unit files might see just the old
name, and one where it would see just the new name. It might also
happen that enumeration sees the file both under the old and the new
name, or under neither (simply because file enumeration is a long
process). In all these cases we'd end up reading a borked
configuration, hence we just don't do that.

It is expected for the admin to issue "systemctl daemon-reload"
explicitly at the correct time, i.e. when a set of changes to
configuration and unit files is complete and before the next set of
changes is begun. Only the admin really knows when that is. (I mean,
the alternative would be if we'd have a transactional file system on
Linux, but we do not, and I don#t see that coming either.)

(Another example where things might go very wrong if we'd start
reading configuration files at the wrong time: consider RPM
removing/updating/installing a bunch of unit files in one go: if we'd
wake-up whenever even one file changes we'd very likely wake up at the
wrong time and see a file removed with its replacement not there yet,
or the opposite. So if we did that and you update a bunch of RPMs at
once you'd basically get the guarantee that you will hit this case.)


So I tried to "start local filesystems" after realizing the problem
this morning. Then disaster (named "systemd") strikes back:
It tried to mount the old filesystems that do no longer exist (and
are no longer present in /etc/fstab), resulting in a "dependency
failed", and in turn it transitioned a fully running server from
multi-user mode to emergency mode, shutting down all services,
network, etc.

That is why I hate systemd!

So, there are changes between systemd and pre-systemd, non trivial
ones, even. They are documented though, and generally well
communicated. Yes, there's a learning curve, and yes you have to read
some docs if you have a non-trivial setup you want to convert to
systemd. But I am not sure why you unload this on our doorstep. There
are technical reasons for these choices, documented ones even. If you
convert a machine from pre-systemd systems to systemd, please
read the docs thoroughly, and understand the incompatibilities that
there are. We write these docs because we know how important this is,
not so that you then ignore all we did and blame us anyway. And no,
doing a live-update between major OS releases of production
infrastructure without reading the docs is a very very bad idea, but
not one we came up with, did we?

I mean, short of actually *being* sysvinit there's literally nothing
we could do to make you happy, can we?

Anyway, please vent your frustrations elsewhere, this is not helpful
nor new.

And: RTFM!

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Compliments to Lennart, for writing a civilized and clear reaction.

In the past, I had my share of frustration with systemd too. To 

Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Lennart Poettering
On Mi, 28.08.19 10:46, Reindl Harald (h.rei...@thelounge.net) wrote:

> a good start for a discussion as always :-)
>
> just the topic "/etc/fstab obsolete?" alone makes one puke given that
> /etc/fstab is mentioned dozens of times in the manuals and yes you get
> generated units for years now, but hey who needs to read any manual when
> he can also write useless posts with "causing endless frustration here"
> and "That is why I hate systemd"

Reindl, please tone it down. While I don't think the tone Ulrich chose
wasn't right either, let's not make it worse (by saying things like
"makes on puke"), it's entirely unnecessary.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Lennart Poettering
On Mi, 28.08.19 09:33, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> systemd in SLES 12 is causing endless frustration here:
>
> Yesterday I was migrating some filesystems to a new device (multipath, 
> MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other 
> files as needed.
> After migration was successful, I also cleaned up the now obsolete resources 
> (multipath, MD-RAID, filesystem, mountpoints, etc.)
> Everything looked OK...
>
> But some time later the application was stopped, as the new
> filesystems were unmounted by systemd (even though active processes
> were using it) WITHOUT giving a reason for "Stopped target Local
> File Systems" in syslog. Instead systemd tried to mount the
> filesystems that had been removed from /etc/fstab!

You need to issue "systemctl daemon-reload" when updating this file,
systemd only takes notice of changed configuration files when you
issue that.

This is documented widely, for example here:

https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

Moreover, well-meaning distributions would most likely include a
comment about this in /etc/fstab to make this discoverable easily by
the admin. On Fedora you'll find this comment at the top of the file
for example:


# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.


systemd does not automatically reload configuration files when they
change since that is inherently racy: systemd reads a larger number of
unit files and other configuration files and simply by watching file
changes with inotify we cannot know when the right time is to reload
configuration: we might end up seeing some of the old
unit/configuration files and some of the new unit/configuration files,
as they are manipulated if we reload at the wrong time. For example,
consider the case where you rename a unit file: there is likely a
timeframe where enumerating all unit files might see just the old
name, and one where it would see just the new name. It might also
happen that enumeration sees the file both under the old and the new
name, or under neither (simply because file enumeration is a long
process). In all these cases we'd end up reading a borked
configuration, hence we just don't do that.

It is expected for the admin to issue "systemctl daemon-reload"
explicitly at the correct time, i.e. when a set of changes to
configuration and unit files is complete and before the next set of
changes is begun. Only the admin really knows when that is. (I mean,
the alternative would be if we'd have a transactional file system on
Linux, but we do not, and I don#t see that coming either.)

(Another example where things might go very wrong if we'd start
reading configuration files at the wrong time: consider RPM
removing/updating/installing a bunch of unit files in one go: if we'd
wake-up whenever even one file changes we'd very likely wake up at the
wrong time and see a file removed with its replacement not there yet,
or the opposite. So if we did that and you update a bunch of RPMs at
once you'd basically get the guarantee that you will hit this case.)

> So I tried to "start local filesystems" after realizing the problem
> this morning. Then disaster (named "systemd") strikes back:

> It tried to mount the old filesystems that do no longer exist (and
> are no longer present in /etc/fstab), resulting in a "dependency
> failed", and in turn it transitioned a fully running server from
> multi-user mode to emergency mode, shutting down all services,
> network, etc.
>
> That is why I hate systemd!

So, there are changes between systemd and pre-systemd, non trivial
ones, even. They are documented though, and generally well
communicated. Yes, there's a learning curve, and yes you have to read
some docs if you have a non-trivial setup you want to convert to
systemd. But I am not sure why you unload this on our doorstep. There
are technical reasons for these choices, documented ones even. If you
convert a machine from pre-systemd systems to systemd, please
read the docs thoroughly, and understand the incompatibilities that
there are. We write these docs because we know how important this is,
not so that you then ignore all we did and blame us anyway. And no,
doing a live-update between major OS releases of production
infrastructure without reading the docs is a very very bad idea, but
not one we came up with, did we?

I mean, short of actually *being* sysvinit there's literally nothing
we could do to make you happy, can we?

Anyway, please vent your frustrations elsewhere, this is not helpful
nor new.

And: RTFM!

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Frans de Boer

On 28-08-19 11:54, Reindl Harald wrote:

Am 28.08.19 um 11:24 schrieb Frans de Boer:

Unnecessary use of shaming and hurting words. Although the intention was
good, systemd is - in my view - overly complex. And yes, when starting
with it, one should read the manuals at least once, as a matter of
preparation. But I also understand that one can get lost in the jungle
called systemd.

So, don't pass judgment if you have only a portion of the information.
Rather, start asking questions to get the full picture. I hate the self
righteous posture of some people, just because they */think/* they know
it all/better.

look in the archive how this guy started with systemd to get the whole
picture, his inital greeting on 2019-05-09 started with that attitude:

"I had to subscribe to this list, even though I'm no systemd fan. Still
I'll have to deal with it as the distribution we use switched to systemd..."

"Cause of the trouble (and possible reason for systemd's unpopularity)
seems to be rather arbitrary restrictions without reasoning (which is
completely against the GNU spirit of seeking for limitless software)"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


So, that makes it alright for you to go shaming and bashing?

--- Frans.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Reindl Harald

Am 28.08.19 um 11:24 schrieb Frans de Boer:
> Unnecessary use of shaming and hurting words. Although the intention was
> good, systemd is - in my view - overly complex. And yes, when starting
> with it, one should read the manuals at least once, as a matter of
> preparation. But I also understand that one can get lost in the jungle
> called systemd.
> 
> So, don't pass judgment if you have only a portion of the information.
> Rather, start asking questions to get the full picture. I hate the self
> righteous posture of some people, just because they */think/* they know
> it all/better.

look in the archive how this guy started with systemd to get the whole
picture, his inital greeting on 2019-05-09 started with that attitude:

"I had to subscribe to this list, even though I'm no systemd fan. Still
I'll have to deal with it as the distribution we use switched to systemd..."

"Cause of the trouble (and possible reason for systemd's unpopularity)
seems to be rather arbitrary restrictions without reasoning (which is
completely against the GNU spirit of seeking for limitless software)"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Reindl Harald


Am 28.08.19 um 09:33 schrieb Ulrich Windl:
> systemd in SLES 12 is causing endless frustration here:

a good start for a discussion as always :-)

just the topic "/etc/fstab obsolete?" alone makes one puke given that
/etc/fstab is mentioned dozens of times in the manuals and yes you get
generated units for years now, but hey who needs to read any manual when
he can also write useless posts with "causing endless frustration here"
and "That is why I hate systemd"

CTRL+F "fstab" here:
https://www.freedesktop.org/software/systemd/man/systemd.mount.html

> Yesterday I was migrating some filesystems to a new device (multipath, 
> MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other 
> files as needed.
> After migration was successful, I also cleaned up the now obsolete resources 
> (multipath, MD-RAID, filesystem, mountpoints, etc.)
> Everything looked OK...

"looked ok"

> But some time later the application was stopped, as the new filesystems were 
> unmounted by systemd (even though active processes were using it) WITHOUT 
> giving a reason for "Stopped target Local File Systems" in syslog. Instead 
> systemd tried to mount the filesystems that had been removed from /etc/fstab!

in other words your poor univesity either can not afford testing systems
or competent sysadmins using them and RTFM or why do you go ahead on
production servers with a procedere obviously no tested before?

any sane sysadmin (especially when he admits that he is new to the
system) has testing setups and in times of virtualizatioin there is no
longer any excuse

> It seems systemd does not like root to unmount a filesystem that is still 
> present in /etc/fstab.

no, it just don't like when you edit config, doing steps manually and
don't issue "daemon-reload"

> So I tried to "start local filesystems" after realizing the problem this 
> morning. Then disaster (named "systemd") strikes back:
> It tried to mount the old filesystems that do no longer exist (and are no 
> longer present in /etc/fstab), resulting in a "dependency failed", and in 
> turn it transitioned a fully running server from multi-user mode to emergency 
> mode, shutting down all services, network, etc.

the from the old fstab generated units where partially still there

> That is why I hate systemd!

believe it: systemd hates you too

honestly, after all that threads in the past months i would recommend
your employer to replace you with someone with better reading
comprehence and some solid education you obviously don't have for the
SLES your are supposed to maintain

> I did a "daemon-reload" in the emergency shell, and then I was able to start 
> the default target again.
if you only would have done it in the production system after mangle
/etc/fstab
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread František Šumšal
On 8/28/19 9:33 AM, Ulrich Windl wrote:
> Hi!
> 
> systemd in SLES 12 is causing endless frustration here:
> 
> Yesterday I was migrating some filesystems to a new device (multipath, 
> MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other 
> files as needed.
> After migration was successful, I also cleaned up the now obsolete resources 
> (multipath, MD-RAID, filesystem, mountpoints, etc.)
> Everything looked OK...
> 
> But some time later the application was stopped, as the new filesystems were 
> unmounted by systemd (even though active processes were using it) WITHOUT 
> giving a reason for "Stopped target Local File Systems" in syslog. Instead 
> systemd tried to mount the filesystems that had been removed from /etc/fstab!
> 
> It seems systemd does not like root to unmount a filesystem that is still 
> present in /etc/fstab.
> 
> So I tried to "start local filesystems" after realizing the problem this 
> morning. Then disaster (named "systemd") strikes back:
> It tried to mount the old filesystems that do no longer exist (and are no 
> longer present in /etc/fstab), resulting in a "dependency failed", and in 
> turn it transitioned a fully running server from multi-user mode to emergency 
> mode, shutting down all services, network, etc.
> 
> That is why I hate systemd!
> 
> I did a "daemon-reload" in the emergency shell, and then I was able to start 
> the default target again.

It looks like you forgot to issue `systemctl daemon-reload` after updating 
/etc/fstab, which is, actually, a documented incompatibility
with SysV scripts:

Excerpt from 
https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/:
> On SysV systems changes to init scripts or any other files that define the 
> boot process (such as /etc/fstab) usually had an immediate effect on 
> everything started later. This is different on systemd-based systems where 
> init script information and other boot-time configuration files are only 
> reread when "systemctl daemon-reload" is issued. (Note that some commands, 
> notably "systemctl enable"/"systemctl disable" do this implicitly however.) 
> This is by design, and a safety feature, since it ensures that half-completed 
> changes are not read at the wrong time.

As you stated later, running `systemctl daemon-reload` later fixes the issue, 
because that's what you're supposed
to do after updating pretty much any configuration when it comes to systemd.

Also, I'm still amazed how you expect people to help you with all the "insults" 
on systemd's behalf - maybe try to refrain from
doing them in the future, as the issue may not be in systemd. And even if it 
is, this attitude won't make it magically better.

> 
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] /etc/fstab obsolete?

2019-08-28 Thread Ulrich Windl
Hi!

systemd in SLES 12 is causing endless frustration here:

Yesterday I was migrating some filesystems to a new device (multipath, MD-RAID, 
LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other files as 
needed.
After migration was successful, I also cleaned up the now obsolete resources 
(multipath, MD-RAID, filesystem, mountpoints, etc.)
Everything looked OK...

But some time later the application was stopped, as the new filesystems were 
unmounted by systemd (even though active processes were using it) WITHOUT 
giving a reason for "Stopped target Local File Systems" in syslog. Instead 
systemd tried to mount the filesystems that had been removed from /etc/fstab!

It seems systemd does not like root to unmount a filesystem that is still 
present in /etc/fstab.

So I tried to "start local filesystems" after realizing the problem this 
morning. Then disaster (named "systemd") strikes back:
It tried to mount the old filesystems that do no longer exist (and are no 
longer present in /etc/fstab), resulting in a "dependency failed", and in turn 
it transitioned a fully running server from multi-user mode to emergency mode, 
shutting down all services, network, etc.

That is why I hate systemd!

I did a "daemon-reload" in the emergency shell, and then I was able to start 
the default target again.

Regards,
Ulrich




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel