[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
Re: [systemd-devel] Suppressing automounting
From: Lennart Poettering lenn...@poettering.net 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
Re: [systemd-devel] Suppressing automounting
From: Thomas Suckow thomas.suc...@pnnl.gov From: Lennart Poettering lenn...@poettering.net 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: Mantas Mikulėnas graw...@gmail.com 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 devpath.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: Andrei Borzenkov arvidj...@gmail.com 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: 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 arvidj...@gmail.com 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: Simon McVittie simon.mcvit...@collabora.co.uk 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: Mantas Mikulėnas graw...@gmail.com 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: Colin Guthrie gm...@colin.guthr.ie 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: Tobias Geerinckx-Rice tobias.geerinckx.r...@gmail.com 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: Andrei Borzenkov arvidj...@gmail.com 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 tobias.geerinckx.r...@gmail.com 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] [PATCH 1/3] journal: Do not count on the compiler initializing found_last to false
From: Philippe De Swert philippedesw...@gmail.com 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] 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] 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: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 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] Shell expressions in EnvironmentFile
From: Simon Peeters peeters.si...@gmail.com 2014-10-07 19:12 GMT+02:00 Jon Stanley jonstan...@gmail.com: [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] systemd-detect-virt and vendors
From: Rahul Sundaram methe...@gmail.com 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] [question] networkd: Any support for hooks?
From: Tom Gundersen t...@jklm.no 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] [PATCH] systemctl: add edit verb
From: David Herrmann dh.herrm...@gmail.com On Sat, Oct 11, 2014 at 8:17 PM, Daniel Buch boogiewasth...@gmail.com 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] [PATCH] systemctl: add edit verb
From: Mantas Mikulėnas graw...@gmail.com 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] I wonder… why systemd provokes this amount of polarity and resistance
From: Lennart Poettering lenn...@poettering.net 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
[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 lenn...@poettering.net 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
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 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] logind, su - sessions and initscripts compatibility
Simon McVittie simon.mcvit...@collabora.co.uk 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] logind, su - sessions and initscripts compatibility
Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 14:10, Dale R. Worley wrote: Simon McVittie simon.mcvit...@collabora.co.uk 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 fcro...@suse.com 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
Andrei Borzenkov arvidj...@gmail.com 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
