Re: [systemd-devel] /etc/fstab obsolete?
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 little
Re: [systemd-devel] /etc/fstab obsolete?
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?
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?
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?
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?
On 28-08-19 10:46, Reindl Harald wrote: 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 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. --- Frans. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/fstab obsolete?
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?
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?
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
