Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Andrei Borzenkov writes: > There is not a single word about "login session" in su man page. > It says it starts "login shell" - but "login session" is not created by > shell so I do not see where you draw this conclusion from. > > The primary reason to use "su -" in this cases is a) get a clean > environment and b) make started shell read usual startup files to > ensure some known state for running programs. Actually the only > difference between "login" and "non login" shells is which startup > files are processed. I'm no expert in this, but as far as I know, there's no solid documentation or specification regarding "login sessions" as a concept. But as you say, "the only difference between "login" and "non login" shells is which startup files are processed." And I take that to mean that when the "login" startup files are processed, the intention is to "create a login session", to initialize everything as if the named user was logging in. Whereas what the "non login" startup files are processed, the intention is that this is *not* a "new login", but rather an attempt to create a shell subprocess running under the new UID which is *not* disconnected from the environment of its parent process. And when an initscript does an "su" to get ready to run a daemon, it really ought to use the latter method, not the former. (I have written initscripts, so I know something about that.) I would expect the architects on the systemd project have thought about these problems more than I have. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Simon McVittie writes:
> On 18/12/14 14:10, Dale R. Worley wrote:
>> Simon McVittie writes:
>>> On 18/12/14 08:05, Andrei Borzenkov wrote:
>>>> Any initscript that is using "su -" would [cause badness]
>>>
>>> Don't do that then? Init scripts are fairly clearly not login sessions.
>>> Which init scripts do that?
>>
>> More to the point, why would an initscript do that, since it's *already*
>> running as root?
>
> su isn't just for becoming root; it can also cause transitions from root
> to a less privileged user ("su -c 'my-app-clear-cache' daemon" is one
> example of something that an init script might want to do).
Yeah, ack, that was my mistake. I was confusing "su", "su [user]", and
"su - [user]". But the question is about the "su - [user]" form, which
is basically intended to start a new login session (as far as I can see
from the man page), since it gives the user's shell a "-" in argv[0],
which is intended to instruct the shell to run the user's
initializations, etc.
Which means that the question I should have asked is "Why would an
initscript use 'su -', as that is intended to start a new login
session?"
Frederic Crozat writes:
> Unfortunately, we don't always have a choice, when initscripts are not
> shipped as part of packages in the distribution but shipped by an ISV or
> a random external software :(
And it seems that the answer is, "They do that, even if we think they
shouldn't."
Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Simon McVittie writes: > On 18/12/14 08:05, Andrei Borzenkov wrote: >> Any initscript that is using "su -" would [cause badness] > > Don't do that then? Init scripts are fairly clearly not login sessions. > Which init scripts do that? More to the point, why would an initscript do that, since it's *already* running as root? Though I'm sufficiently out of the loop regarding the architecture that I don't see how "su" can have such complexities -- As far as I know, its purpose is to create a subprocess whose UID is different from the UID of this process; in no way is it intended to be "a separate login". Why would shutting down "logind" suddenly cause one of my subprocesses to vanish? Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
> From: Zbigniew Jędrzejewski-Szmek > > That mostly applies to people who actually don't use systemd and are > commenting from the peanut gallery. Actual *users* when they are unhappy > are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as "nofail", some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. So it is clear that this is not a "bug", as it is the behavior intended by the designers, but I'm still not happy. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
> From: "Lennart Poettering" > > Please, let's discuss this elsewhere. Let's keep a strict technical > focus on this ML! I believe that you mean that outsiders are welcome here to provide assistance to systemd as it has already been implemented. One difficulty is that outsiders are usually not able to provide such assistance. It would be useful if there was a mailing list where outsiders could come with problems -- "systemd does not implement what I need as it is provided by the distro". I would expect such a mailing list to be named "systemd-users". But no such list seems to exist. (And thus, they show up in systemd-devel.) This leaves users with the sense that they are expected to use systemd as it is provided, and it makes it hard for them to customize systems that do what they need. This reminds them of Microsoft products and makes them unhappy. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Problem with modprobe in lm_sensors.service
I am running Fedora 16 with kernel 3.14.19-100.fc19.x86_64 and systemd-204-21.fc19.x86_64. On startup (and sometimes shutdown), I see a message like this in /var/log/messages: Oct 6 13:53:37 hobgoblin modprobe[623]: modprobe: ERROR: missing parameters. See -h. This message appears to be due to invocations of modprobe with these arguments: /sbin/modprobe -qab /sbin/modprobe -qabr Grepping all the system files (and looking in the journal), it seems likely that these invocations are made by systemd, under control of /usr/lib/systemd/system/lm_sensors.service: [Unit] Description=Initialize hardware monitoring sensors After=syslog.target [Service] EnvironmentFile=/etc/sysconfig/lm_sensors Type=oneshot RemainAfterExit=yes ExecStart=-/sbin/modprobe -qab $BUS_MODULES $HWMON_MODULES ExecStart=/usr/bin/sensors -s ExecStop=-/sbin/modprobe -qabr $BUS_MODULES $HWMON_MODULES [Install] WantedBy=multi-user.target Which suggests that $BUS_MODULES and $HWMON_MODULES are empty in this context. Is it normal for these variables to be empty (in which case, the lm_sensors people need to fix their .service file) or is systemd supposed to be providing values here (in wich case, this is a systemd problem)? (And if it's a problem with the .service file, is there a "standard" way to avoid this problem that I can suggest to the lm_sensors people?) Thanks, Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
> From: Lennart Poettering > We are always interested in technical feedback. > > We are not very interested in FUD mails that tell us how we'd "force" > people, how we'd behave like microsoft and so on. That's not useful, > that's pretty much only hurtful. I haven't read this full thread, and it probably isn't useful for me to do so. But it seems that the first question to be answered by the developers is: Are they concerned that uptake is not as fast as they'd like? and if the answer to that is Yes, then: Would they like to hear feedback from users as to what they might do about it? There's no point in jabbering about it unless the answer to the second question is Yes. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add edit verb
> From: Mantas Mikulėnas > Normally $VISUAL would be first, followed by $EDITOR... > > (But in practice nobody sets them to different values anyway, since no > programs aside from mailx care about the distinction. So it's fine > either way, and just ignoring $VISUAL would be just as good.) I ran into an archived message which suggested what the "traditional" indicator was for "visual" vs. "dumb" terminals: If TERM is unset, or had the value "dumb", then it's a dumb terminal. Otherwise, it's a visual terminal. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add edit verb
> From: David Herrmann > > On Sat, Oct 11, 2014 at 8:17 PM, Daniel Buch wrote: > > Nice, I was in the process of implementing this. Looks good to me. But I > > think it would be better to use "vi" instead of "vim" if no &editor is set. > > Vim is not installed on every system as default but vi is most likely. > > I'd prefer doing nothing. "vi" has quite different behavior than > "vim", especially in Ex mode. And for people uncomfortable with 'vi' > it's even worth. And everyone should have set EDITOR anyway.. My general understanding is that the traditional behavior when "you need an editor but the user hasn't specified one" is to use "vi", and so people who don't want "vi" *always* set $VISUAL in their environment. If you're being really nice, the program determines whether the terminal is dumb or visual, and then goes through the sequence of choices: 1) $VISUAL if the terminal is visual and it is specified 2) $EDITOR if it is specified (or if $VISUAL fails to execute) 3) vi if the terminal is visual 4) ed or ex (I think) (I don't know what the test for visual is. It may simply have been trying to execute $VISUAL (and vi) and seeing if they exit with an error.) Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
> From: Tom Gundersen > What we do, however, is to expose the configuration state using the > sd-network C API, which external programs can watch and react on (see > how timesyncd and resolved currently works). In a situation where one wants to do what a "hook" does, having a separate daemon program that watches for an event and then invokes the hook when the event happens is not a good solution -- it replaces the hook with an entire daemon. I am not experienced, but from what little I know about systemd, the "natural" way would seem to be to write a new unit file with the appropriate dependencies. The event that should call the hook is when some unit finishes starting, and then the new unit would then be started. The new unit's ExecStart command would be the desired invocation of the hook. Does that make sense? If it does, it might be useful to write a beginner's guide on how to construct and insert such a unit into a system. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
> From: Rahul Sundaram > We really should be more specific and call it virtualbox and hyper-v > instead, similar to say virt-what and other similar tools. I will be happy > write the patches if this makes sense. At the least, we need documentation that tells the user what name systemd uses, based on the name(s) that the user is likely to know the product by (which may not be the current name of the product). This would work reasonably well: The following technologies are currently identified: qemu, kvm, vmware, microsoft (a/k/a Hyper-V, Viridian, Windows Server Virtualization), oracle (a/k/a VirtualBox), xen, bochs, chroot, openvz, lxc, lxc-libvirt, systemd-nspawn. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shell expressions in EnvironmentFile
> From: Simon Peeters > > 2014-10-07 19:12 GMT+02:00 Jon Stanley : > > [Service] > > ExecStartPre=/something/that/sets/var > > ExecStart=/some/file $var > > ExecStart=/bin/sh -c ". /something/that/sets/var; /some/file $var" Yeah, I think some thing like this would work: ExecStartPre=/bin/sh -c '/something/that/sets/var ; printenv >/tmp/special' ExecStart=/bin/sh -c '. /tmp/special ; /some/file $var' But you probably want to reorganize how you're doing the job. You probably want a wrapper script that calculates $var and then invokes "/some/file $var". Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
> From: Zbigniew Jędrzejewski-Szmek > More seriously, the idea of having shell scripts which you're going > to modify to customize your setup is simply crazy. How robust would > your changes be? How would you ever handle upgrades? How would more > than one admin manage a machine without sitting in the same room? I've been editing init scripts since around 1992, and I'll bet that a lot of other people have, too. It's reasonably robust, since you know where the edits are and what they're for. You upgrade by bringing forward the edits into each new release you load. But there's no way around that. Suppose I'd like to adjust systemd's behavior regarding mounting devices (as I do). Is that going to be *easier* to do if I have to download the C, modify it, and recompile? I still have the same problems with upgrading, etc. In the end, what wins is usually what makes it easiest to accomplish the tasks people have at hand. E.g., in many ways, C is an inferior language to Pascal, but there are enough things that Pascal makes hard or impossible that C won out. Similarly with customizations. > Again, this seems rather ignorant of the status quo. Between the blog > posts and wiki documentation and the 164 man pages, systemd is rather > copiously documented. Not to say that things can't be improved, but > by Linux standards we are at least making an effort. Bugs for missing > or unclear documentation and usually handled, and any patches for > documentation are applied fairly quickly. OK, I'd like to modify systemd's handling of mounts. I've been told only that the units that are created from /etc/fstab are created and handled by the main systemd binary. What documentation do I look at that explains how systemd actually does that, what the relevant source is, etc.? With init scripts, I know it's somewhere in a script in /etc/rc.d/init.d; searching for "mount" probably reveals a couple of hundred lines of shell script within which the functionality is hiding. Another more generically useful pointer would be something that explains what the algorithm that does the sequencing between units *really* is. I've heard breezy descriptions of what the various dependency types mean, but I'm certain that there's a bunch of tricky details which a lot of thought has been spent on. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Let me offer this as a suggestion of what might be the root of some issues: One of the lessons in Fred Brooks' "The Mythical Man-Month" is that it takes three times more effort to produce a *program product* as it does to produce the *program*. That is, 2/3 of the effort is not to make the software do what it is supposed to, but rather to adjust the software to work in the (software and human) environment that it must work in, interacting with customers, etc. It might be worth examining the project and asking whether the non-software part of the work has been carried out with the same care as the software part of the work. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
> From: "Jóhann B. Guðmundsson" > > Did you ever ask yourself why your project provokes that amount of > > resistance and polarity? Did you ever ask yourself whether this > > really is just resistance against anything new from people who > > just do not like "new" or whether it contains*valuable* > > and*important* feedback? > > I'm not sure why you are under the assumption that we do not consider > and have not and are not gathering feedback from individuals, > communities or companies for that matter but I'm going to address your > questions anyway. I've brought a complaint about one of systemd's behaviors here. I have gotten useful feedback allowing me to refine what I think would be a good solution to the problem. What I *haven't* gotten is any useful feedback on how to implement a solution. I suspect others have had similar experiences. One metric that might be useful is to ask: Of the people who complain about one or another aspect of systemd, what fraction ultimately consider their complaint to be satisfactorily resolved? There are also "architectural" issues about systemd that I've noticed. I don't know to what degree these indicate quality control problems with the code, or whether they are just a matter of things being done in ways that are not common in the Un*x universe. But they do seem to me to be things that are going to inhibit adoption. 1. Systemd has some very large binaries, each of which implements many aspects of the system. Conversely, the typical Un*x approach is to separate functions into many executablels, many of which are scripts. The latter approach makes customization easier, especially for sysadmins who aren't deeply familiar with the system. 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. Ultimately, writing e-mail messages saying "They're wrong" is useless, even if they *are* wrong. If there is a substantial body of people out there who dislike systemd, it's going to prevent its adoption. The fix is adjusting systemd (or the project surrounding it) so that people like it better. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] journal: Do not count on the compiler initializing found_last to false
> From: Philippe De Swert
>
> There is a very unlikely case where this can happen since gcc usually
> does the sane thing. But let's make sure found_last is initialized anyway.
You'd better -- the C standard does *not* require the compiler to
intialize local ("auto") variables.
Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Tobias Geerinckx-Rice > That's not to say that it didn't happen to work most of the time. I > just hoped systemd could do better. I still do. I agree that systemd's current default behavior is better than the previous default. But there are some cases where I can easily define behavior that would be much better (for me) than systemd's current default behavior. And indeed, better than the previous default behavior. What I am looking for is advice or pointers as to what a proper way to implement a configurable option (presumably in /etc/fstab) that would cause the behavior I want. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Andrei Borzenkov > At least, it is impossible to achieve what the goal of OP was - > attempt to automount device exactly once on system boot and give up if > it was not successful. Which had been semantic of /etc/fstab for quite > some time. I don't have a need to "automount device exactly once", only that after a certain period of time, systemd would cease trying to mount the device. I'm guessing that a reasonable place to specify this would be in a special option in the /etc/fstab line. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Tobias Geerinckx-Rice > Step back, and define exactly what it is you actually need^Wwant to do. For a certain entry in /etc/fstab (which will in practice always have the option "nofail"), if the device is not available "until booting is over" (which I'm willing to denote with a specified period of time), after that, it will not be automatically mounted if it becomes available. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Colin Guthrie > I'm maybe missing something, but in the case of mount units, isn't that > framework program mount(8)? > > It has a mechanism for parsing default options that apply to all mounts > and then calling out to the appropriate, filesystem specific mount > program (e.g. mount.nfs, mount.cifs, mount.crypt, mount.fuse etc. etc.) > if appropriate. mount does the real work, of course, but it isn't the complete solution, because *something* has to figure out not only that /bin/mount should be invoked, but what its arguments are. And as you can see from the unit file # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab DefaultDependencies=no After=local-fs-pre.target Conflicts=umount.target Before=umount.target [Mount] What=/dev/Freeze02/Store2 Where=/Store Type=ext4 FsckPassNo=0 Options=nofail,x-systemd.device-timeout=1m,defaults none of that is specified *directly* in the unit file. Some piece of code has to know to assemble the What, Where, Type, and Options values (at the very least) -- and that piece of code is what contains special knowledge of how to handle mount units. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Mantas Mikulėnas > > What I was thinking of is, what is the program that reads (directly or > > indirectly) the Store.mount file and from that decides exactly how to > > call mount(8), and when to call it? > > It's systemd itself (pid 1). > > > My guess was that the name of this program would be listed *in* the > > *.mount file, but that does not appear to be so. > > That would not make any sense: if the program wasn't running yet, how > could it possibly start itself in order to read the .mount file which > just tells it to start itself? In many systems, there's a framework program that reads a lot of control files which describe the bits of work to be done. The framework program figures out the sequencing and dependencies of the various bits of work, while there are separate programs that *execute* the bits of work. And the names of the execution programs are not hard-coded within the framework program, they are specified in the control files. That sort of structure makes the framework program simpler, and enforces a defined interface between the framework program and the execution programs. It also makes it easy to add new execution programs without changing the framework program. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Simon McVittie > > In my "Store.mount" file, I see no indication of an executable which > > implements the unit. > > I think it's always mount(8), which has its own extension mechanism to > dispatch per-filesystem if necessary (e.g. mount.cifs). What I was thinking of is, what is the program that reads (directly or indirectly) the Store.mount file and from that decides exactly how to call mount(8), and when to call it? My guess was that the name of this program would be listed *in* the *.mount file, but that does not appear to be so. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Andrei Borzenkov > bor@opensuse:~/src/systemd> systemctl show boot.mount -p WantedBy --no-pager > WantedBy=dev-sda1.device > > Which has the effect that if device was not present at boot but appears > later, the very appearance of device triggers start of mount unit - > filesystem gets mounted. > > And yes, this makes semantic very different from > traditional /etc/fstab. And I'm not sure it has to do it by default ... > honestly, I'm not sure it has to do it at all. I think about situation > where I have persistent device names (SAN, iSCSI, LVM) and need to do > maintenance which causes device nodes disappear and appear again. I > definitely do not want any filesystem to be suddenly mounted in this > case until I have finished my tasks. > > And of course it is not documented anywhere. I admit that I haven't studied systemd enough to understand the significance of WantedBy. My understanding is that systemd performs a series of units, with dependencies showing which units must finish before other units start. But it appears that boot.mount does not represent a particular task, but some sort of generic task that is executed multiple times, one for each ".device" unit. -- Or is "boot" the name of the mountpoint, and "boot.mount" only represents the work for mounting /dev/sd1 as /boot? However, if I wanted to add an option that means "give up on attempting to mount this device after xx seconds", what would be a good way to organize it, given the architecture of systemd? It appears that there is a general mechanism for inserting information for systemd into the "options" part of an /etc/fstab line, so presumably the indication for the option would be placed there. In my "Store.mount" file, I see no indication of an executable which implements the unit. What is the code which implements it? Would it be possible for that code to determine how long it has been? Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: wor...@alum.mit.edu (Dale R. Worley) >When reading /etc/fstab a few special mount options are >understood by systemd which influence how dependencies are >created for mount points from /etc/fstab. [...] If >x-systemd.device-timeout= is specified it may be used to >configure how long systemd should wait for a device to show up >before giving up on an entry from /etc/fstab. Specify a time in >seconds or explicitly specify a unit as s, min, h, ms. > > I haven't tried this yet, but it should suffice for my problem. OK, that test failed: systemd does *not* stop attempting to mount a partition after x-systemd.device-timeout has passed. Here's the line in /etc/fstab: /dev/Freeze02/Store2/Store ext4 nofail,x-systemd.device-timeout=1m,defaults 0 0 And here's /run/systemd/generator/Store.mount: # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab DefaultDependencies=no After=local-fs-pre.target Conflicts=umount.target Before=umount.target [Mount] What=/dev/Freeze02/Store2 Where=/Store Type=ext4 FsckPassNo=0 Options=nofail,x-systemd.device-timeout=1m,defaults Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Andrei Borzenkov > > > Here's an interesting fact: What systemd does (in this situation) > > > isn't true automounting; rather it waits for the *first* time the > > > device/volume becomes available, and then mounts it. Any later > > > attachments of the volume do not cause mounting (until the next > > > reboot). > > Well, that's how /etc/fstab always behaved, right? Anything in there is > "automounted" just once, when system boots. Later you have to manually > do it. That's true, it's how it is expected to work. But that's not how I described the situation originally -- I called it "automounting" -- so upon discovering that I was wrong, I had to correct the record. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Mantas Mikulėnas > For fstab, the units are created by a 'generator' > (systemd-fstab-generator), which writes them under /run/systemd/generator > every time the configuration is reloaded. > > I'm not at my PC right now so I cannot check, but I /do/ remember someone > mentioning that if a fstab entry has the 'auto' option, then the generator > also symlinks the corresponding .mount unit under .device.wants/ > (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to > be triggered *every* time that device appears on the system. > > That is, in addition to local-fs.target triggering foo.mount and waiting > for bar.device one time only (as you describe), it makes bar.device itself > trigger foo.mount every time as well. Thanks for the information! I finally thought to do "man -k fstab" to see if it turned up anything, and I found the manual page for "systemd-fstab-generator", which references "systemd.mount", which tells me that I'm not the first person with this complaint: When reading /etc/fstab a few special mount options are understood by systemd which influence how dependencies are created for mount points from /etc/fstab. [...] If x-systemd.device-timeout= is specified it may be used to configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly specify a unit as s, min, h, ms. I haven't tried this yet, but it should suffice for my problem. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Thomas Suckow > > >> From: Lennart Poettering > > > >> Note that a concept of "mount at boot if it is there, otherwise don't" > >> cannot work. > > > > It worked until a week or two ago. I want it back. > > > > I'm sure you're right that in the abstract, it cannot be made to > > work. But that isn't the problem I'm facing. > > It seems that a workaround could be to not put the volume in fstab > and add a unit to the startup that would mount it if present. If you > wanted to mount it later, you could manually start the unit again. I'd rather adjust systemd and leave fstab stable than vice-versa. Here's an interesting fact: What systemd does (in this situation) isn't true automounting; rather it waits for the *first* time the device/volume becomes available, and then mounts it. Any later attachments of the volume do not cause mounting (until the next reboot). But at this point, I only need to investigate the issue. The documentation I've managed to find about systemd is rather abstract, there's no map between specific bits of functionality and the files that control them. My understanding is that everything systemd does is controlled by "units". In this case, entries in fstab cause the creation of units based on a "template". If you could point me to the template file in question, it would probably point me to all of the things I need to investigate. Thanks, Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Lennart Poettering > Note that a concept of "mount at boot if it is there, otherwise don't" > cannot work. It worked until a week or two ago. I want it back. I'm sure you're right that in the abstract, it cannot be made to work. But that isn't the problem I'm facing. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Suppressing automounting
(This is more proper for a systemd-users mailing list, but I can't find one.) I'd like to customize my systemd. (I'm running Fedora Linux 19, with systemd-204-20.fc19.x86_64.) I have a line in /etc/fstab like this, which refers to a logical volume on a USB storage device: /dev/Freeze02/Store2/Store2ext4 nofail,defaults 0 0 Of course, if the logical folume Store2 is present at boot time, it gets mounted. In the past, once the system is running, if I plug in the storage device, the volume does not get mounted unless I manuall issue "mount /Store2". More recently, if I plug in the storage device, the volume gets mounted automatically. Messages in /var/log/messages suggest that systemd is doing the mounting. I would like to suppress the latter automatic mounting. (This is for all filesystems, which means I don't want to have to modify every fstab line.) The documentation of systemd is voluminous and hard to understand, but I believe that in order to do this, I need to provide systemd with a value that applies to all *.automount units that suppresses the action of the unit. Because I do not want to put "noauto" in the fstab line, I expect that the initial mounting will still be done if the logical volume is present at boot time. I'm guessing that putting something in a "automount@.service" file will suffice. Does anyone have any advice? Thanks, Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
