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
>
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? Ini
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
> 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 com
> 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
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 du
> 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
> 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 ra
> 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 i
> 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 pro
> 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, bas
> 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
> 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 i
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 softwa
> 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*
> 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
___
> 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
> 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 exact
> 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
> 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
> 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
> 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 pr
> 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
> 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 spec
> 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 (un
> 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
> 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.
> 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
___
(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
29 matches
Mail list logo
