[opensuse] How to stop systemd automounting umounted devices?
Hi, just noticed that systemd automatically mounts devices again allthough I've manually umounted them. Here is what I did $ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered) ## umount and disable that lvm device $ umount /mnt/local $ lvchange -an vg0/local systemd[1]: Stopping File System Check on /dev/vg0/local... systemd[1]: Stopped File System Check on /dev/vg0/local. ## enable device again $ lvchange -ay vg0/local systemd[1]: Found device /dev/mapper/vg0-local. systemd[1]: Found device /dev/disk/by-uuid/177a415d-174d-4c30-8897-5502c0419ef8. systemd[1]: Found device /dev/disk/by-id/dm-uuid-LVM-uF33oY4c9yu00EPAP42a8A2XZCfQTRRPGfiv0cNZRwPKIRJnOboscsc1z60174dd. systemd[1]: Found device /dev/disk/by-id/dm-name-vg0-local. systemd[1]: Found device /dev/dm-0. systemd[1]: Found device /sys/devices/virtual/block/dm-0. systemd[1]: Starting File System Check on /dev/vg0/local... systemd-fsck[6386]: /dev/mapper/vg0-local: clean, 648240/3276800 files, 9308645/13107200 blocks systemd[1]: Started File System Check on /dev/vg0/local. systemd[1]: Mounting /mnt/local... kernel: [ 5542.579700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr systemd[1]: Mounted /mnt/local. $ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered) So what kind of automount is this? How to disable this odd behaviour? Is this a known bug? cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Oct 24, 2014 at 11:57 PM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
Hi,
just noticed that systemd automatically mounts devices again allthough I've manually umounted them.
Here is what I did
$ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered)
## umount and disable that lvm device $ umount /mnt/local $ lvchange -an vg0/local
systemd[1]: Stopping File System Check on /dev/vg0/local... systemd[1]: Stopped File System Check on /dev/vg0/local.
## enable device again $ lvchange -ay vg0/local
systemd[1]: Found device /dev/mapper/vg0-local. systemd[1]: Found device /dev/disk/by-uuid/177a415d-174d-4c30-8897-5502c0419ef8. systemd[1]: Found device /dev/disk/by-id/dm-uuid-LVM-uF33oY4c9yu00EPAP42a8A2XZCfQTRRPGfiv0cNZRwPKIRJnOboscsc1z60174dd. systemd[1]: Found device /dev/disk/by-id/dm-name-vg0-local. systemd[1]: Found device /dev/dm-0. systemd[1]: Found device /sys/devices/virtual/block/dm-0. systemd[1]: Starting File System Check on /dev/vg0/local... systemd-fsck[6386]: /dev/mapper/vg0-local: clean, 648240/3276800 files, 9308645/13107200 blocks systemd[1]: Started File System Check on /dev/vg0/local. systemd[1]: Mounting /mnt/local... kernel: [ 5542.579700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr systemd[1]: Mounted /mnt/local.
$ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered)
What's in your /etc/fstab?
So what kind of automount is this? How to disable this odd behaviour? Is this a known bug?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 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. 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'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? On Sat, 25 Oct 2014, Ruediger Meier wrote:
Hi,
just noticed that systemd automatically mounts devices again allthough I've manually umounted them.
Here is what I did
$ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered)
## umount and disable that lvm device $ umount /mnt/local $ lvchange -an vg0/local
systemd[1]: Stopping File System Check on /dev/vg0/local... systemd[1]: Stopped File System Check on /dev/vg0/local.
## enable device again $ lvchange -ay vg0/local
systemd[1]: Found device /dev/mapper/vg0-local. systemd[1]: Found device /dev/disk/by-uuid/177a415d-174d-4c30-8897-5502c0419ef8. systemd[1]: Found device /dev/disk/by-id/dm-uuid-LVM-uF33oY4c9yu00EPAP42a8A2XZCfQTRRPGfiv0cNZRwPKIRJnOboscsc1z60174dd. systemd[1]: Found device /dev/disk/by-id/dm-name-vg0-local. systemd[1]: Found device /dev/dm-0. systemd[1]: Found device /sys/devices/virtual/block/dm-0. systemd[1]: Starting File System Check on /dev/vg0/local... systemd-fsck[6386]: /dev/mapper/vg0-local: clean, 648240/3276800 files, 9308645/13107200 blocks systemd[1]: Started File System Check on /dev/vg0/local. systemd[1]: Mounting /mnt/local... kernel: [ 5542.579700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr systemd[1]: Mounted /mnt/local.
$ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered)
So what kind of automount is this? How to disable this odd behaviour? Is this a known bug?
cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-27 14:58, Anton Aylward wrote:
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.
No, not really. You umount the partition, and nobody except root can mount it again, and it will not mount automatically. Then you can manipulate it to your heart content - that is, unless you change the partition table and you get the message "failed to convince the kernel to re-read the changes, reboot". 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". (Warning: please, no systemd bashing here. We are trying to find workaraounds) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlROaJEACgkQtTMYHG2NR9UnKQCfbMKveHEhiWBTfLfXrCLQAAaI j4cAn31Mc77WKq/TIs7PAuE3jDBqOiyL =48sW -----END PGP SIGNATURE----- -- 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
On Tuesday 28 October 2014, 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".
FYI I filed a bug report https://bugzilla.suse.com/show_bug.cgi?id=902612 But seems that they just defend this systemd "feature". Again ignoring the fact that any existing user would expect the old behavior ... that umount just works.
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.
There is a solution to get rid off systemd mount stupidity. kernel command line: fstab=no /etc/init.d/after.local: /usr/bin/mount -a I have not tested yet. Could be that there are drawbacks. But probably these drawbacks will be advantages too. :) cu, Rudi -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-29 07:40, Linda Walsh wrote:
Anton Aylward wrote:
On 10/27/2014 11:45 AM, Carlos E. R. 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?
Exactly! Editing fstab is not it.
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.
We may also wish to mount again something that got momentarily off. But we need control over it. For example, you may have a rack of disks, where /srv/www/ is, and it loses power, then gets power back, so we may want the system to attempt fsck and mount of the devices back, posibly restarting apache, or telling apache about it, without us having to even be called. It is just an example, it may be nfs shares, samba, mail, whatever. But we need control of this, a versatile control. Like switches in fstab to mount automatically anytime, or only at boot, or never. Commands to manually umount a device anytime we want, regardless how it is defined in fstab, because we want to do it now for whatever reason.
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.
Yes, currently it is broken. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRQmJoACgkQtTMYHG2NR9XpgACfZGeC/enHn+tJ3+XTuoEgnJ4D RSgAnR6udfCRSJCrIMSgB1/vHp5PTAms =JnBr -----END PGP SIGNATURE----- -- 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
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 <opensuse@lists4.opensuse.org>; 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
[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 <opensuse@lists4.opensuse.org>; 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
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 -- Henne Vogelsang, Mailinglist Admin http://www.opensuse.org -- 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
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 :-) 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
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
Hey, On 30.10.2014 18:24, Per Jessen wrote:
Henne Vogelsang wrote:
On 30.10.2014 15:19, Per Jessen wrote:
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.
If you think I do a bad job, step up and do a better one :-) 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-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
Hey, On 31.10.2014 15:30, Carlos E. R. wrote:
On 2014-10-31 12:03, Henne Vogelsang wrote:
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? :-?
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. 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-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
Hey, On 03.11.2014 12:41, Carlos E. R. wrote:
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,
No need to. Most of the things with mlmmj.org work via mail. 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-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
Hey, On 03.11.2014 13:32, Carlos E. R. wrote:
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.
I do know.
That's what they told us back then.
That's what I'm telling you today :-) 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 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
Henne Vogelsang wrote:
Hey,
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? -- 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
Henne Vogelsang wrote:
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.
If you want to moderate -- automate. If you think some subjects are more likely than others to get abusive, or even in general, scan for swearing or--best would be to run them through a Bayseian filter -- i.e. run good and bad through a filter -- train it, and let it perform the 1st level filtering. Sure it would need to be trained, but seems like it would be ideal for this type of task. -- 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
Henne Vogelsang <ml-admin@opensuse.org> írta:
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.
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. Istvan -- 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
On Friday 31 October 2014, Henne Vogelsang wrote:
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
Could you please either publish this "list of things" or send back an automatic notification when an email is on hold.
* 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
cu, Rudi -- 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 Monday 03 November 2014 at 11:59, you wrote:
On 31.10.2014 17:18, Ruediger Meier wrote:
On Friday 31 October 2014, Henne Vogelsang wrote:
* 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...
Don't understand how it could be wrong if users would avoid that "list of things" ...? Why do you filter then? My guess is that you simply don't publish it because your filter looks ridiculus!? Do you filter for "sy****d" in the subject?
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...
From my point of view our emails are currently just randomly delayed ... and that's really annoying. Last week I've spent at least 30 minutes to validate my email setup because one email did not appeared on the list. It took about 20 hours before my email got through so in the meanwhile I had completely forgotten about it and missed all the answers to my question. People already started to complain about me. So please tell us how to write an email to the list. cu, Rudi -- 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 2014-11-06 19:09, Anton Aylward wrote:
Heck, I've had SMS messages that took more then 30 minuts to get through!
And more than 24 hours. And thousands of whatsups, not getting anywhere, worldwide. At least SMSs being stuck do not affect that many people simultaneously! :-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-31 00:33, Istvan Gabor wrote:
Henne Vogelsang <ml-admin@opensuse.org> í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. The issue is not the subject, but manners. Insults and threats. That's why threads have been closed. 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. 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. Think of debates on TV or elsewhere. The task of the moderator is not to ban the discussion. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRTkd4ACgkQtTMYHG2NR9UtlgCgkVoUEXegvIe1rMmDTVu2tgZG GfUAn0d2IX+ZBAXWoKd6e7uTQOtl8bqP =JIJG -----END PGP SIGNATURE----- -- 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
On 10/30/2014 07:33 PM, Istvan Gabor wrote:
Henne Vogelsang <ml-admin@opensuse.org> írta:
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.
Walsh must be in cahoots with Poetering. OUR RULES??? It was just looking like an attempted dictatorship. Now it is obvious! -- 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/29/14 14:13, Anton Aylward wrote:
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?
Because we want to have both: Automount behavior *AND* manually controlled mount behavior. Before systemd, we had it: autofs and mount-on-boot/unmount-on-shutdown with fstab. autofs even supported LDAP maps or YP maps. Now, systemd proponents like you tell us that we don't need manually controlled mount behavior any more. We, people who used both before, simply don't buy your argument. Btw, it's a standard systemd proponents argument: It's not support because you don't need it. As if you would know what I need. And, to make this clear: This is ***NOT*** a paradigm shift, as you wrote before. The paradigm of automounts has been there before and is used heavily[*]. A paradigm shift would introduce something that has not been there before. That is *not* happening here. Joachim [*] Incidentially, LDAP maps are not supported by systemd's automount functionality. Thus, it's deficient and useless as an automounter, IMNSHO. It's neither a replacement for manual fstab configuration nor a proper replacement for autofs. PS: I actually like systemd. I don't like that systemd fanboys react to every systemd critic that's well supported by arguments with "deal with it, that's the new paradigm" -- when there doesn't exist any *new* paradigm at all, but the paradigm has been well established in much better functionality for decades already. In common life, such behavior is called "my way or the highway". -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- 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 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. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlROZy4ACgkQtTMYHG2NR9W7UQCdHaf2Dj/F4ngdUTCSWwXAaUmu E2YAn3Xn/66hbMDE09uVKy269iJBHdvS =fhjS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <carlos.e.r@opensuse.org> [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 2014-10-27 19:06, Patrick Shanahan wrote:
* Carlos E. R. <> [10-27-14 11:43]:
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".
That's a hack. A dirty one, if I may say so. What Andrei proposes is way more reasonable. My fstab is ... wait. Telcontar:~ # wc -l /etc/fstab 307 /etc/fstab Telcontar:~ # It is not trivial to keep track of changes and get them right at the first try, when doing maintenance, and then undo them properly. Recently I was doing some maintenance using the rescue image, which has no entries in fstab to mount hard disks, or another 13.1 in another disk. I don't remember. So I changed partitions, adding and deleting some. When I exited, dunno what, perhaps gparted or the yast partitioner - all my hard disk partitions were mounted. Which I strictly did not want, because I wanted to run a verbose fsck before replaying journal logs, for debugging a problem. Even without that need, to continue formatting and repairing I needed to umount manually all that crap. I don't need that feature, I want it out. Or a way to easily disable it on all partitions, existing or new, with a command. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Monday 27 October 2014, Patrick Shanahan wrote:
* Carlos E. R. <carlos.e.r@opensuse.org> [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 10/28/2014 01:00 PM, Ruediger Meier wrote:
On Monday 27 October 2014, Patrick Shanahan wrote:
* Carlos E. R. <carlos.e.r@opensuse.org> [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.
I haven't drilled down to investigate the workings of this yet, but some things I do see. Please note that I'm guessing and speculating based on what I do see. I think this is how parts work. I haven't experimented by breaking things to get the "Ah!' discovery. When the fstab-generator runs and the units are generated they are used then seem to vanish. I think they are held open but unlinked. As you know, that measn they don't really go away :-) I also note the use of sockets. That seems to be a way of watching for changes. Grep for that in the output of systemctl I also notice these are still active: local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems Then there's the matter of udev. It does a lot and could do a lot more :-) I'm sure one could configure udev rules to get rid of things like /etc/fstab :-) Just speculating ... -- Hell, there are no rules here--we're trying to accomplish something. - Thomas A. Edison -- 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 <michael@actrix.gen.nz> 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 10/30/2014 05:29 AM, Greg Freemyer wrote:
On October 25, 2014 5:57:07 PM EDT, Michael Hamilton<michael@actrix.gen.nz> 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?
Michael and Greg nail it. How will this paradigm change affect how we interact with our systems? I have a couple of machines that literally contain hundreds of non-raided disk drives. I use filesystem labels for the most part, but have to manually mount/umount both by label and by /dev/sdxyz as necessary without booting. It would be bad indeed if systemd started to second-guess what I need to do at any given time. These boxes are still on 12.1 if memory serves. Regards, Lew -- 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 <michael@actrix.gen.nz> 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
On October 30, 2014 3:51:53 PM EDT, Michael Hamilton <michael@actrix.gen.nz> wrote:
On Fri, 31 Oct 2014, Greg Freemyer wrote:
On October 25, 2014 5:57:07 PM EDT, Michael Hamilton
<michael@actrix.gen.nz> 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.
If noauto can be set in fstab and it works I theoretically can live with it. 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 do this today by being in "init 3" state before connecting the drives. Is systemd changing this? This is a seriously important question for me. I can't trust Windows to ignore random drives being connected. Even with a physical write-blocker in place, Windows can become unstable because a drive it doesn't understand gets connected to it. It refuses to simply ignore the drive. Historically with Linux, in "init 3" state I was in total control of random drives I connect to my machine. If I loose that control, I will have to loose systemd one way or another. Fyi: in the security:forensic repo there are tools to work with raw drives. There are imaging tools, parsing tools, timeline analysis tools, file carving tools, data recovery tools. Proper use of those tools needs the drives to not be mounted at all once the forensic analysis of the drives commences. That is my day job and why I maintain that repo. Greg 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
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 10/31/2014 10:39 AM, jdd wrote:
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
Doesn't this - pluggable - have to do with the udevd, its rules, and possibly apparmor? <quote src="http://hackaday.com/2009/09/18/how-to-write-udev-rules/"> Since the adoption of Kernel 2.6, Linux has used the udev system to handle devices such as USB connected peripherals. If you want to change the behavior when you plug something into a USB port, this section is for you. </quote> You can also google for "linux udev usb plug" and learn about persisitent naming of pluggable USB devices :-) -- The significant problems we face cannot be solved at the same level of thinking we were at when we created them. - Albert Einstein -- 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)
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.
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
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
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? You participated in that thread :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
В Sun, 26 Oct 2014 01:57:26 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
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 :-)
Hi, sorry for late replying. On Monday 27 October 2014, Andrei Borzenkov wrote:
В Sun, 26 Oct 2014 01:57:26 +0200
"Carlos E. R." <robin.listas@telefonica.net> пишет:
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?
You participated in that thread :-)
Ah, I remember this thread now. Is it still not fixed?
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.
This is the relevant part of my fstab .... /dev/vg0/local /mnt/local ext4 acl,user_xattr 1 2 /mnt/local/opt/intel /opt/intel none bind 0 0 /mnt/local/opt/Matlab /opt/Matlab none bind 0 0 /mnt/local/opt/TWS /opt/TWS none bind 0 0 .... Actually only the first line (/mnt/local) is relevant for the bug. This one got auto mounted while I wanted do some offline maintenance. If this kind of automounting is a systemd feature then it's broken ... because the other "child" bind mounts were not automounted again. So what it does is not only unwanted behavior but also completely useless. Anyway. I don't like that. How can I tell systemd to NEVER ever mount anything after boot.
I know why it is mounting filesystem without "noauto" option and I strongly believe it should be changed. Change is actually two liner.
Where do I have do change these two lines? Systemd source?
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.
cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
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
On 10/24/2014 03:57 PM, Ruediger Meier wrote:
So what kind of automount is this? How to disable this odd behaviour? Is this a known bug?
You might also look at /usr/lib/udev/rules.d/81-mount.rules -- You may have afresh start any moment you choose, for this thing that we call 'failure' is not the falling down, but the staying down. - Mary Pickford -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (18)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Doug -
Greg Freemyer -
Henne Vogelsang -
Henne Vogelsang -
Istvan Gabor -
jdd -
Joachim Schrod -
Lew Wolfgang -
Linda Walsh -
Michael Hamilton -
Patrick Shanahan -
Per Jessen -
Ruben Safir -
Ruediger Meier