On 10/25/2014 05:57 PM, Michael Hamilton wrote:

I had the same problem when trying to merge partitions and grow a filesystem. It was really quite scary to see the /home remounted while in the middle of re-partitioning and re-sizing (I had to spend some time diffing the result against a backup to make sure it was OK).

Unless you are running A FS such as ReiserFs which supports resizing while mounted, then trying to resize while in multi-user mode is going to be risky.

I don't really have an answer - I somehow muddled through. But from reading man systemd.mount, it seems temporarily changing the fstab entry to noauto might help. I suspect it would take a reboot or some kind of systemd command to make such a change stick.

It strikes me that if the /etc/fstab says that a FS should be mounted that if systemd is trying to maintain that definition of the system state this behaviour is predictable; that changing the state definition to noauto makes sense of you don't want the system automatically mounted. Think 'state' rather than 'command sequence'.

I'm not that happy to see umount fail to behave it the old expected manner - perhaps it is no longer the umount we expect it to be and should be renamed.

I think there is a misunderstanding here. In effect there is an 'automounter' running. The fsatab tells the 'automounter' what _should_ be mounted and it tried to maintain that state. Perhaps the misunderstanding is that, as I keep saying, systemd takes a DECLARATIVE approach rather than a PROCEDURAL approach.

But it would be good to get some pointers in how to do admin in a systemd environment. Does anyone know of a HOWTO for doing standard system maintenance tasks, such as re-sizing filesystems, in a systemd environment?

I think you need to step back and look at how to prepare the system for resizing first. The ability to dynamically resize without the unmount/remount cycle is one of the reasons I chose to use ReiserFS. YMMV. As such this whole issue does not arise. The OP clearly was using LVM. In the case I've had to convert from non-ReiserFS to ReiserFS I've created the new partition, created the ResiserFS then rsynced across and altered to fstab and done the umount (the long, literal way, not using fstab) and then 'mount -a'. That worked before systemd and works after systemd. Once the ResierFs was in place adjusting its size (and that of the LVM partition to match) was quite independent of systemd vs sysvinit. I think you will find that there are other file systems that permit dynamic resizing, or at lest dynamic increase in size. As far as I'm concerned the idea of sysadmin by defining the state of the machine and having tools that keep it in that state makes a lot of sense. But then, as I've said before, I have the hardware background in state machines so this is not strange to me. I can see how it is, how all the state definition nature of systemd, is strange to people who are used to the procedural -- "do this now do this not do this" ... Sequencing -- approach. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/27/2014 11:45 AM, Carlos E. R. wrote:

This worked till systemd changed this particular behaviour and mounted automatically things that the administrator umounted. No matter what fstab says, if I, root, do "umount", I want it to stay till I "mount".

In this event, systemd is running an automounter and doing its best to maintain state. It doesn't know the sysadmin is a sysvinit generation guy and can't tell such a umount from a an accident or malice. A systemd generation sysadmin will 'change state definition" and let the automounter do the unmount. if this was a non-local disk and this was a nfs mount using the old, well recognized automounter, then you're recognise this behaviour for what it is. As I keep saying, systemd is about DECLARATIVE not procedural management of the system. So long as the state tables, in this case /etc/fstab, DECLARE that the fs should be mounted, the automounter function will keep it mounted. That is the correct and expected behaviour. What we have here is a paradigm shift.... -- "Many people may listen, but few people actually hear." -- Harvey Mackay. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 10/27/2014 11:45 AM, Carlos E. R. wrote:

...

This worked till systemd changed this particular behaviour and mounted automatically things that the administrator umounted. No matter what fstab says, if I, root, do "umount", I want it to stay till I "mount".

In this event, systemd is running an automounter and doing its best to maintain state. It doesn't know the sysadmin is a sysvinit generation guy and can't tell such a umount from a an accident or malice.

Either one, since it doesn't know the cause it shouldn't try to remount. Accident or malice -- since it is unknown then the effect of remounting is unknown and further corruption occurs.

A systemd generation sysadmin will 'change state definition" and let the automounter do the unmount.

--- Change it how? from the command line? in 1 command specifying the device?

if this was a non-local disk and this was a nfs mount using the old, well recognized automounter, then you're recognise this behaviour for what it is.

---- If automounting was desired it would be in /etc/auto.xxx

As I keep saying, systemd is about DECLARATIVE not procedural management of the system. So long as the state tables, in this case /etc/fstab, DECLARE that the fs should be mounted, the automounter function will keep it mounted. That is the correct and expected behaviour.

--- That is a bug and is not expected behavior. On *nix based systems, the files in fstab are mounted once. If you want automount behavior then put everything in /etc/auto.xxx, but don't try to change the established meaning of /etc/fstab.

What we have here is a paradigm shift....

No... it's broken behavior. /etc/fstab is not for automounted file systems. That's what /etc/auto.xxx is for. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

No... it's broken behavior. /etc/fstab is not for automounted file systems. That's what /etc/auto.xxx is for.

Yeah, I would tend to agree. -- Per Jessen, Zürich (9.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Please Linda, there's no need to cc me. I subscribe to this list. I don't need to get two copies of your mail responses. On 10/28/2014 06:50 PM, Linda Walsh wrote:

...

A systemd generation sysadmin will 'change state definition" and let the automounter do the unmount.

--- Change it how? from the command line? in 1 command specifying the device?

If this were the nfs automounter of old how would you tell it to adopt a new state? By changing the definition tables. Why should it be any different? This question has been answered, the controlling table in question is /etc/fstab. The people that altered it got the desired result.

If automounting was desired it would be in /etc/auto.xxx

Perhaps in an ideal world all storage would be treated the same, local and non local, and there would be just one definition table. Sadly we are dealing here with backward compatibility, that local storage is defined in /etc/fstab. Sidebar: most of the problems we face with systemd seem to arise from it having to deal with backward compatibility. If there really was a new systemdOS that didn't have to deal with backward compatibility then none of these problems would occur but you'd be screaming a different tune. In essence, there is no reason all storage should not be defined in /etc/auto.xx and managed by the old automounter model. As i've pointed out, the SUN networked 'thin client' workstations with 'rovong logins' worked that way. Having state clearly defined - documented - is important. The arguments I see presented are al "I ... I ... I". They don't seem to consider the situation where there are many sysadmins. Sysadmin#1 does the unmount to deal with what he sees as a problem. Perhaps he gets interrupted, "run over by a bus" we used to say[1][2]. Sysadmin#4 comes along and sees a disk unmounted "for no apparent reason", since the fstab says it should be mounted. Or perhaps sysadmin#2 sets up a new LVM/filesystem, adds it to fstab and runs "mount -a". if sysadmin#1 had modified the definition of state to communicate his change by altering fstab then the actions of #2 and #4 would not disrupt his work. Its been pointed out repeatedly that Linux has to "grow up" to deal with large installations. Cgroups and resource mapping are an example of that, and they too are irrelevant to home and single user systems and the kind of small "traditional" Linux installations. The arguments against a state model make sense for people who are procedurally oriented, who don't have to deal with heavily multi-tenanted, heavily multi-virtual installations where resource management and allocation is important. An ISP, for example, running SUSE on a IBM "mainframe (which is list a little larger than my tower and would still fit under my desk) might have to deal with 4000+ virtual instances. [1] The in-joke in BOFH style was that the VP/IT drove to work in a VW bus. And was a ... not very good ... driver. [2] Or for some other reason does come back to undo his change, there is no record of what he's done or why. -- Excellence is not an accomplishment. It is a spirit, a never-ending process. - Lawrence M. Miller -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

[repost w/fixed subj, as original subj w/system subbed for cistern, hasn't been echoed on list for >50 minutes] Anton Aylward wrote:

...

Please Linda, there's no need to cc me. I subscribe to this list. I don't need to get two copies of your mail responses.

Sorry, but my responses don't always make it through to the list. I had to retitle 2 of my posts using "cisternd" in the title to get them to come through -- THEN my original posts that had systemd in the title came through. Given the unreliability of the posting mechanism here, putting you on the delivery list is the only way of ensuring that the person I am responding to gets the message, though it doesn't solve the delayed/moderated post problem. Question will be how long this message take to show up in the list. If I see the echo back within 1 minute (usually it's under 30 seconds (see below)) I'll know it went through. If I don't I know that Cc'ing is the only way you will know that I did respond to you -- it is, also, only the only way you will know I responded, as the list copy seems to have become unreliable. Note in the headers: ==== (1) Received: from lists4.suse.de (localhost [127.0.0.1]) by lists4.suse.de (Postfix) with SMTP id 5D8C5868A3C; Wed, 29 Oct 2014 10:14:50 +0000 (GMT) X-Original-To: opensuse@lists4.opensuse.org Delivered-To: opensuse@lists4.opensuse.org (2) Received: from relay1.suse.de (unknown [149.44.160.133]) by lists4.suse.de (Postfix) with ESMTP id 1937086898B for ; Tue, 28 Oct 2014 22:50:40 +0000 (GMT) ==== In GMT: From 28-Oct-22:50(sent)... passed through to the list @ 29-Oct-10:15 => (decimalized): 1029:1015(arrival on list) - 1028:2250(sent) => 0000:0815 == delay of 8h15m The first email w/this problem (in ISP sent/rcved & decimalized): 1027:2210 -> 1029:0316 => 0001:0506 = delay of: 29h06m Vs. "Normal mail" (in ISP-sent/rcved): 1028:234452(arr.) - 1028:234437(sent) => 15 second delay for a "normal message" and 1028:234103 - 1028:234122 => 19 second delay for other "normal message" I.e. depending on the subject (and likely sender), am seeing an additional delay of 18.5 hours (std.dev 9.5 hr) (with 29 hour max) over a sample size of 2. With such random delivery times, it makes sense to ensure, that at least, the person I am responding to gets a timely copy. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Henne Vogelsang wrote:

Hey,

On 30.10.2014 00:02, Linda Walsh wrote:

...

I.e. depending on the subject (and likely sender), am seeing an additional delay of 18.5 hours (std.dev 9.5 hr) (with 29 hour max) over a sample size of 2.

I moderate mails about systemd for a while now. I also moderate certain users. This will stop when everybody has learned to play by our rules.

Henne

What exactly are the rules, Henne? The mostly off-topic thread about batteries and UPS'es was left to carry on long enough. -- Per Jessen, Zürich (12.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Henne Vogelsang wrote:

Hey,

On 30.10.2014 15:19, Per Jessen wrote:

...

Henne Vogelsang wrote:

...

On 30.10.2014 00:02, Linda Walsh wrote:

...

I.e. depending on the subject (and likely sender), am seeing an additional delay of 18.5 hours (std.dev 9.5 hr) (with 29 hour max) over a sample size of 2. I moderate mails about systemd for a while now. I also moderate certain users. This will stop when everybody has learned to play by our rules. What exactly are the rules, Henne?

1. https://en.opensuse.org/openSUSE:Guiding_principles 2. https://en.opensuse.org/openSUSE:Mailing_list_netiquette 3. Whatever I say

...

The mostly off-topic thread about batteries and UPS'es was left to carry on long enough.

If you think it's to off-topic, complain to opensuse+owner@opensuse.org.

Do you think I read every message to this list and scan it for rule violations? Get real :-)

Hey, you are the self-appointed list-police, you ought to take your job seriously. I don't mind rules at all, but I don't like rules I don't know and I don't like rules that are applied arbitrarily. Just my opinion. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-31 12:03, Henne Vogelsang wrote:

Hey,

On 30.10.2014 18:24, Per Jessen wrote:

...

I don't mind rules at all, but I don't like rules I don't know and I don't like rules that are applied arbitrarily. Just my opinion.

If you think I do a bad job, step up and do a better one :-)

There was an offer of help some years ago and was rejected. They said it has to be an employee. Have they switched minds? :-? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRTnPsACgkQtTMYHG2NR9VcTwCfWoF7Tfd0WSye1Hg6nn7yGpKX gX4An2fSki4LjK5A5wzLwVNHhVKtaiZP =bzDD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-03 11:32, Henne Vogelsang wrote:

...

There was an offer of help some years ago and was rejected. They said it has to be an employee. Have they switched minds? :-?

Who is they? Doesn't really matter, everyone can help me here with assisting people to use the list, telling people the rules, moderation, etc.

Some years ago, and I don't remember who exactly. The offer required access to the server somehow, to actually do things like blocking posts, not just talk into people. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRXafYACgkQtTMYHG2NR9Vi8gCeL2M3Pfu6phERYSrV3iJNX/lv UhYAoI2D7acvqEbvB8cIDV/PBdSuOqjb =5YBA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-03 13:19, Henne Vogelsang wrote:

...

Some years ago, and I don't remember who exactly. The offer required access to the server somehow,

No need to. Most of the things with mlmmj.org work via mail.

I don't know. That's what they told us back then. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRXdesACgkQtTMYHG2NR9VzTACcDm3/KhnoN35ffenCM5xSBvWI ouMAoJIwtQYEVRDN8OGmkDmX9mYkdEeO =Vy/W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/30/2014 01:24 PM, Per Jessen wrote:

...

Hey, you are the self-appointed list-police, you ought to take your job seriously.

I don't mind rules at all, but I don't like rules I don't know and I don't like rules that are applied arbitrarily. Just my opinion.

The important point is when Henne says Do you think I read every message to this list and scan it for rule violations? Get real Henne is not like the NSA, soaking up and examining every message. There's no paranoid agenda, he'd not out to make us conform to some procrutian bed, just to stop runaway excesses and abuse. There mere fact that we can ask and discuss this tells a lot. Technical differences are .. Technical differences. But swearing, threatening bodily harm ... That's clearly a violation of etiquette. -- The final test of a leader is that he leaves behind him in other men the conviction and will to carry on. - Walter J. Lippmann -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Moin, On 30.10.2014 18:04, Linda Walsh wrote:

Henne Vogelsang wrote:

...

I moderate mails about systemd for a while now. I also moderate certain users. This will stop when everybody has learned to play by our rules.

Exactly what rules did I violate with systemd in the subject that require moderation?

Moderation is the action to manually check _if_ a mail violates the rules before I let it through to the list. Moderation is not the "punishment" for rule breaking. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-30 11:54, Henne Vogelsang wrote:

Hey,

On 30.10.2014 00:02, Linda Walsh wrote:

...

I.e. depending on the subject (and likely sender), am seeing an additional delay of 18.5 hours (std.dev 9.5 hr) (with 29 hour max) over a sample size of 2.

I moderate mails about systemd for a while now. I also moderate certain users. This will stop when everybody has learned to play by our rules.

Appreciated. Thanks. Perhaps you could automate a message to posters that their email is awaiting moderation, and please do not resubmit it? I know that some mail list software do this. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRSfggACgkQtTMYHG2NR9UhMQCZAaVfuxDXSKYqPiDpvwTmbvnY 4CAAnREsnlnhv8Djq/5GIWAhxy48P2ks =TWdF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hey, On 31.10.2014 00:33, Istvan Gabor wrote:

Also, moderating linux related messages only because of the topic (systemd) is outrageous.

If people in those threads could behave like grown ups, I wouldn't have to give those threads special attention. They cannot... And you seem also to misunderstand what moderation means. Maybe I ought to explain this in detail. Moderation means: * You send a mail to the list * if this mail matches the list of things I moderate I get a notification about it * I then read your mail to see if it violates the rules * If it does, I talk to you about it * If it does not, I let it through to the list Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hey, On 31.10.2014 17:18, Ruediger Meier wrote:

On Friday 31 October 2014, Henne Vogelsang wrote:

...

On 31.10.2014 00:33, Istvan Gabor wrote:

...

Also, moderating linux related messages only because of the topic (systemd) is outrageous.

If people in those threads could behave like grown ups, I wouldn't have to give those threads special attention. They cannot...

And you seem also to misunderstand what moderation means. Maybe I ought to explain this in detail. Moderation means:

* You send a mail to the list * if this mail matches the list of things I moderate I get a notification about it

Could you please either publish this "list of things"

I won't, would make it too easy to circumvent them...

or send back an automatic notification when an email is on hold.

That's a feature of the mailing list manager that isn't available for our version yet. Maybe later... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/06/2014 11:14 AM, Ruediger Meier wrote:

From my point of view our emails are currently just randomly delayed ... and that's really annoying.

LOL! I've been using mailing lists since 1982 and have that happen for reasons that have nothing to do with "moderation" and a lot to do with technical matters I have no control over.

Last week I've spent at least 30 minutes to validate my email setup because one email did not appeared on the list.

I think you're overly sensitive! I've posted to lists and been away from the computer for much longer than 30 minutes, days even! If you're expecting SMTP and mailing lists run by computers you have no control over to be instantaneous then I think you really don't grok this technology. Perhaps if this was run on a guaranteed service system, running perhaps on an Amazon cloud Saas, then you'd have cause for complaint. Heck, I've had SMS messages that took more then 30 minuts to get through!

People already started to complain about me.

Oh? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/30/2014 07:33 PM, Istvan Gabor wrote:

Also, moderating linux related messages only because of the topic (systemd) is outrageous.

It wasn't the simple subject, it was that some people were being abusive; swearing, threatening others with bodily harm. It ceased to be a technical discussion. The battery thread drifted, yes, but stayed purely technical and did not involve threats of violence to others (except as warning about equipment exploding), but the threat came from mis-use of equipment and not from human agents. The thread at least started with a question about UPS for powering computer equipment so was on-topic enough. Threatening to kneecap someone or execute them or saying they should have been aborted before birth is not tolerated. -- What goes around comes around. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

"Carlos E. R." írta:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-10-31 00:33, Istvan Gabor wrote:

...

Henne Vogelsang írta:

...

...

I moderate mails about systemd for a while now. I also moderate certain users. This will stop when everybody has learned to play by our rules.

That's ridiculous. I thought this list is for discussing openSUSE/linux related stuff. I am interested in such conversations including systemd, pro and contra opinions.

I could not even understand why the previous systemd threads had to be stopped. I could not understand those either who frequently suggested to stop threads they didn't like. Nobody is obligated to read all messages. If someone is not interested in a thread/message simply should skip it. Why are they bothered then when others are interested?

Also, moderating linux related messages only because of the topic (systemd) is outrageous.

You misunderstand.

Yes, indeed. But this moderation still results in very long delays of message delivery, which disrupts normal conversation. And this delay is only based on a term in the subject or message body. This is not normal. For example according to the header of the message I am answering to it was was sent on Oct 31 but I received it on Nov 3. It is # days delay, extremely long for an email message.

The issue is not the subject, but manners. Insults and threats. That's why threads have been closed.

I agree that insults, bad language are not allowed. But I don't think it should be the ground of closing threads, instead the insulting messages should be blocked. It could occur to any thread that some idiot send insulting message. Should the given thread be closed then?

And it happens that some people are so disgusted with systemd that they attack people with insults; and personal attacks can not be allowed here.

Yes, mostly I agree. Personally I don't think that some weak-mild personal attack, sarcasm, etc is unbearable. Rude insults and ugly language is another category.

Henne is not blocking systemd threads. He just "watches" them, and stops them if the language becomes offensive and uncontrollable. Before that, I understand he tries to convince whoever in private to control himself. Being in private, we do not see this in public, obviously.

I absolutely support this policy.

I don't. The reason for that is no one has to read the threads if don't like it. It is easy to skip them. I think closing threads and long delays are too much price for preventing some insulting messages. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

...

--- Change it how? from the command line? in 1 command specifying the device?

If this were the nfs automounter of old how would you tell it to adopt a new state?

By changing the definition tables.

Why should it be any different?

I wouldn't have a need to temporarily unmount a network file system to do local maintenance.

This question has been answered, the controlling table in question is /etc/fstab. The people that altered it got the desired result.

That overrides the *predefined-ADMIN-CONTROLLED-mount table used by the mount command*. If systemd wants an automounter file, why doesn't it use /etc/auto like *nix systems have for ages?

...

If automounting was desired it would be in /etc/auto.xxx

Perhaps in an ideal world all storage would be treated the same, local and non local, and there would be just one definition table. Sadly we are dealing here with backward compatibility, that local storage is defined in /etc/fstab.

Local vs. remote isn't the issue. It's about manual & static control vs. automatic. /etc/auto.{xx} is ALREADY defined for automatic control. It is a serious design flaw to corrupt normal system function stemming from previous decisions to make /etc/fstab-static and /etc/auto-auto.

Sidebar: most of the problems we face with systemd seem to arise from it having to deal with backward compatibility. If there really was a new systemdOS that didn't have to deal with backward compatibility then none of these problems would occur but you'd be screaming a different tune.

--- The problem here is a gratuitous and unnecessary redefinition that removes local-static controlled mounts when a mechanism for "auto" already existed. There is also the statement of the "mount" developer regarding changing its format or usage: Karel Zak wrote:

On Wed, Aug 06, 2014 at 03:59:27PM -0700, Linda A. Walsh wrote:

...

As another matter of being user friendly, why can't we specify a defaults line for all mounts with the option of per-type defaults ...

Well, the problem is that fstab is de-facto standard. If you want to change semantic than you have to fix all programs that follow fstab setting. The file is no private mount(8) config file

----- The options and semantics for fstab are a "de-facto standard". (Karel Zak is the current maintainer of "mount"). systemd is not following the standard.

In essence, there is no reason all storage should not be defined in /etc/auto.xx and managed by the old automounter model. As i've pointed out, the SUN networked 'thin client' workstations with 'rovong logins' worked that way.

I whole-heartedly agree... and have, at times, have experimented with mounts I didn't need local control of, but that were local, in /etc/auto.xxx. I worked at Sun for 3-4 years over the switch from bsd-based -> SysV based, so am familiar with their practices.

Having state clearly defined - documented - is important. The arguments I see presented are al "I ... I ... I".

??? Excuse me? show me 1 argument presented that way.

Its been pointed out repeatedly that Linux has to "grow up" to deal with large installations. Cgroups and resource mapping are an example of that, and they too are irrelevant to home and single user systems and the kind of small "traditional" Linux installations.

No they are NOT. Home users are constantly concerned about their local buffer cache being thrashed by a large copy as well as a network copy hogging the bandwidth. Those are primarily HOME and single user systems that don't have the resources of LARGE installations. "Growing up" doesn't mean breaking all standards you learned as a kid. That's generally called *criminal* behavior.

[1] The in-joke in BOFH style was that the VP/IT drove to work in a VW bus. And was a ... not very good ... driver. [2] Or for some other reason does come back to undo his change, there is no record of what he's done or why. === So someone undid the change and the resulting catastrophe put the company out of business. Good reason to study a system as a whole before introducing incompatible change.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2014 06:49 AM, Anton Aylward wrote:

...

This worked till systemd changed this particular behaviour and mounted automatically things that the administrator umounted. No matter what fstab says, if I, root, do "umount", I want it to stay till I "mount". In this event, systemd is running an automounter and doing its best to

On 10/27/2014 11:45 AM, Carlos E. R. wrote: maintain state. It doesn't know the sysadmin is a sysvinit generation guy and can't tell such a umount from a an accident or malice.

A systemd generation sysadmin will 'change state definition" and let the automounter do the unmount.

if this was a non-local disk and this was a nfs mount using the old, well recognized automounter, then you're recognise this behaviour for what it is.

As I keep saying, systemd is about DECLARATIVE not procedural management of the system. So long as the state tables, in this case /etc/fstab, DECLARE that the fs should be mounted, the automounter function will keep it mounted. That is the correct and expected behaviour.

What we have here is a paradigm shift....

Indeed. The two paradigms seem to be "Windows" and "UNIX". For whatever reason, the Windows mind-set seems to be seeping into the way we've been doing things for more than 30-years. As we UNIX old-farts leave the theater, will UNIX be assimilated by the "Windows Way"? Maybe Linux will morph into a free Windows distribution? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Oct 30, 2014 at 04:17:50AM +0100, Carlos E. R. wrote:

On 2014-10-29 15:37, Lew Wolfgang wrote:

...

...

As I keep saying, systemd is about DECLARATIVE not procedural management of the system. So long as the state tables, in this case /etc/fstab, DECLARE that the fs should be mounted, the automounter function will keep it mounted. That is the correct and expected behaviour.

What we have here is a paradigm shift....

Indeed. The two paradigms seem to be "Windows" and "UNIX". For whatever reason, the Windows mind-set seems to be seeping into the way we've been doing things for more than 30-years. As we UNIX old-farts leave the theater, will UNIX be assimilated by the "Windows Way"? Maybe Linux will morph into a free Windows distribution?

Huh, no. I have used even driven, non-procedural programming, in MsDOS, by the end of the eighties.

Borland had it in Turbo Pascal, and C. Windows itself was event driven when I first met it, although we programmed it with procedures.

Are you implying that DOS is Unix? Actually, it looks like you are saying that outright.

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [10-27-14 11:43]:

On 2014-10-25 23:57, Michael Hamilton wrote:

...

I had the same problem when trying to merge partitions and grow a filesystem. It was really quite scary to see the /home remounted while in the middle of re-partitioning and re-sizing (I had to spend some time diffing the result against a backup to make sure it was OK).

I had similar issues when creating image backups of partitions, or adding partitions: they were mounted again behind my back. I'm not sure if this was recently or not.

I was told to use "noauto" in fstab, but that won't do for a mount that is expected to be mounted again, automatically, on the next boot.

We need that what is "umounted" manually sticks.

procedural change :^), temporarily edit fstab to not "auto-mount" the subject fs, perform the work, restore the "auto-mount". with new things comes altered approaches. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Monday 27 October 2014, Patrick Shanahan wrote:

* Carlos E. R. [10-27-14 11:43]:

...

On 2014-10-25 23:57, Michael Hamilton wrote:

...

I had the same problem when trying to merge partitions and grow a filesystem. It was really quite scary to see the /home remounted while in the middle of re-partitioning and re-sizing (I had to spend some time diffing the result against a backup to make sure it was OK).

I had similar issues when creating image backups of partitions, or adding partitions: they were mounted again behind my back. I'm not sure if this was recently or not.

I was told to use "noauto" in fstab, but that won't do for a mount that is expected to be mounted again, automatically, on the next boot.

We need that what is "umounted" manually sticks.

procedural change :^), temporarily edit fstab to not "auto-mount" the subject fs, perform the work, restore the "auto-mount".

Does this work instantaneously? Or do you have to "reload" fstab? man systemd-fstab-generator: "systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded." I've tried to edit fstab by adding test mount points but couldn't see new units (systemctl list-units | grep mount). I had tried "systemctl daemon-reload" and executing "systemd-fstab-generator" manually. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On October 25, 2014 5:57:07 PM EDT, Michael Hamilton wrote: <snip>

I'm not interested in another systemd bashing session (if you don't like it, contribute to an alternative, or lobby elsewhere). But it would be good to get some pointers in how to do admin in a systemd environment. Does anyone know of a HOWTO for doing standard system maintenance tasks, such as re-sizing filesystems, in a systemd environment?

This whole thread and earlier threads have been way tl;dr. Is there an answer to the above? I.e. how are things supposed to work in 13.1 and newer? What are the bugs? Does noauto always work if set on boot? How to change a volume from auto to noauto during maintenance? Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 31 Oct 2014, Greg Freemyer wrote:

On October 25, 2014 5:57:07 PM EDT, Michael Hamilton wrote: <snip>

...

I'm not interested in another sd bashing session (if you don't like it, contribute to an alternative, or lobby elsewhere). But it would be good to get some pointers in how to do admin in a systemX environment. Does anyone know of a HOWTO for doing standard system maintenance tasks, such as re-sizing filesystems, in a systemX environment?

This whole thread and earlier threads have been way tl;dr.

Is there an answer to the above?

I.e. how are things supposed to work in 13.1 and newer? What are the bugs? Does noauto always work if set on boot? How to change a volume from auto to noauto during maintenance?

Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

I haven't really seen a satisfactory answer, from just reading the documentation, but not actually trying anything, the following might work: 1) change the fstab to make a mount point noauto (man systemX.mount) 2) systemctl daemon-reload to reload the manager configuration (man systemctl) 3) umount and make changes. 4) reverse fstab changes and do another reload of the manager configuration But if this is supposed to be a UNIX-like system, I think the unexpected behaviour subsequent to umount is wrong. It seems that, for better or worse, GNU Linux is now transitioning to something that is truly not UNIX. It may be better to make a clean break rather than creating a minefield for old players. GNU Linux++ or LinuxNT perhaps. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 31/10/2014 14:19, Greg Freemyer a écrit :

My real concern is for drives that don't have an entry in stab.

For my day job, on occasion I _need_ to be able to connect random USB drives (thumbs/rotating/ssd) and never have them automount.

I'm using 13.1 kde and this is how things works. if I plug a device, some daemon see it read it's name and display it's presence, but *do not mount it*. I get the name in dolphin and a menu asking what to do in the applet jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-10-31 14:19, Greg Freemyer wrote:

My real concern is for drives that don't have an entry in stab.

Not only systemd, but also yast partitioner and gparted can be a concern. Using I don't remember which one, I had all my partitions mounted, even those I did not wish because I was doing things to them. And I don't remember now what was in fstab that moment.

For my day job, on occasion I _need_ to be able to connect random USB drives (thumbs/rotating/ssd) and never have them automount.

I do this today by being in "init 3" state before connecting the drives. Is systemd changing this?

I'm unsure. However, I wonder if apparmour could be used to block anything any kind of access to a particular hard disk device. And of course, allow it for your apps. If this is possible, you could then use graphical mode, too :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Sat, Nov 01, 2014 at 08:02:44AM +0100, jdd wrote:

Le 31/10/2014 22:21, Carlos E. R. a écrit :

...

However, I wonder if apparmour could be used to block anything any kind of access to a particular hard disk device. And of course, allow it for your apps.

You want to use the broken apparmour or SELINUX that breaks with unix admin paradigns in order to fix a problem with systemd that also breaks unix operations.... How about ditching them both and let the well designed OS do its job correctly...in an understandable, trackable, and usable framework. Or just keep spinning and dartboard about the room while trying to hit the bullseye.

if you really speak of *mounting*, I don't have this feature, so may be it's only you, because some config?

I have never seen this

jdd

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 26 Oct 2014 01:57:26 +0200 "Carlos E. R." пишет:

On 2014-10-24 21:57, Ruediger Meier wrote:

...

So what kind of automount is this? How to disable this odd behaviour? Is this a known bug?

Yes.

Date: Sat, 24 May 2014 19:07:18 -0400 From: Michael Fischer <> To: opensuse@opensuse.org Subject: [opensuse] Why is systemd[1] is mounting noauto partitions?

That is exact reason why I asked "what is in /etc/fstab". I never got any reply so we still have no idea what is causing it. I know why it is mounting filesystem without "noauto" option and I strongly believe it should be changed. Change is actually two liner. Slightly more would be to add an option to *consciously* activate "persistent mount state" although I'm not sure I understand why it would be needed - we have autofs for this. But I have no idea why it happens for OP because he never replied.

You participated in that thread :-)

x-posted to factory, as this is 13.2 behavior... Carlos E. R. wrote:

On 2014-10-24 21:57, Ruediger Meier wrote:

...

So what kind of automount is this? How to disable this odd behaviour? Is this a known bug?

Yes.

Um... this sounds like a different bug than the one you mention below. The previous discussion that you quote had auto-remounting happen despite inclusion of "noauto". Now it "only" happens in situations that should ***NEVER*** occur unless someone (or something -- like a kernel) with administrative privileges has manually unmounted. If that's the case --- then something automounting it again is horrible problem -- if there was file corruption causing the unmount, or if suspected file corruption causes an admin to unmount a file system, having a something in the background try to auto-remount such an file system could cause a severe increase of corruption -- not just on that file system, but on the system as a whole -- where it could very easily crash the system. I.e. if a file system that was set for auto-mounting at boot is found to be "unmounted", than any attempt to mount it is "glossing over" the reason why the file system became unmounted in the first place and quite possibly contributing to its corruption or, in worst case, loss of the data on the file system. >>>>>>>>>> /etc/fstab != /etc/auto.xxx... <<<<<<<<<<<<<

Date: Sat, 24 May 2014 19:07:18 -0400 From: Michael Fischer <> To: opensuse@opensuse.org Subject: [opensuse] Why is systemd[1] is mounting noauto partitions?

You participated in that thread :-)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

unless someone (or something -- like a kernel) with administrative privileges has manually unmounted. If that's the case --- then something automounting it again is horrible problem -- if there was file corruption causing the unmount, or if suspected file corruption causes an admin to unmount a file system, having a something in the background try to auto-remount such an file system could cause a severe increase of corruption -- not just on that file system, but on the system as a whole -- where it could very easily crash the system.

That is not a BUG. That is a design failure. The OS should do what you tell it to all the time, not what it wants to do. ----------------------------------------------------------------- Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org