Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I'm pretty confident in the accuracy of the controller mask
aggregation, especially given the new unit test. Here are the main
review questions.
Is it okay to couple realizing the cgroups and applying the attributes
the way the patch does? Before, we were often applying the attributes
for all of a
On Wed, Nov 20, 2013 at 2:18 AM, Marcos Felipe Rasia de Mello
wrote:
> ConditionFileIsExecutable=/usr/sbin/hdparm
It seems sketchy to me to put the executable in ExecStart into
ConditionFileIsExecutable. Is it supposed to fail silently when hdparm
is missing?
_
On Wed, Nov 20, 2013 at 3:00 AM, Marcos Felipe Rasia de Mello
wrote:
> In my first attempts, I forgot to install hdparm. ;)
Shouldn't you only drop the rules and service with installation of hdparm, then?
___
systemd-devel mailing list
systemd-devel@lis
On Wed, Nov 20, 2013 at 5:33 AM, Oleksii Shevchuk wrote:
> Any suggestions how to find the problem?
Valgrind
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Just to suggest the wildly different approach I mentioned on IRC, we
could treat addresses (including DHCP) as the main units and then
specify the backing hardware as part of the address's configuration.
This would be particularly useful for bridges.
___
On Thu, Nov 21, 2013 at 11:48 AM, David Timothy Strauss
wrote:
> This would be particularly useful for bridges.
Actually, I meant bonded interfaces, not bridges.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
h
I often get this when I have a dirty build. Have you tried a fully clean build?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
The service configuration is strange. Normally, this is how they work
with dependencies:
* Type=simple considers the service started immediately on exec()
with no respect for PIDFiles or sd_notify. This can cause dependent
services to come up too early.
* Type=forking considers the service start
On Thu, Nov 21, 2013 at 4:33 PM, salil GK wrote:
> 3. One more use case I can think of is - if the process fail to send
> heartbeat message ( WATCHDOG ) for some time and later it starts sending -
> because of some time. So during the time WATCHDOG notification is missing
> process can be mark
ov 22, 2013 7:50 PM, "Reindl Harald" wrote:
>
> Am 22.11.2013 03:04, schrieb salil GK:
> > Thanks a lot David
> >
> > On 22 November 2013 06:44, David Timothy Strauss
> > da...@davidstrauss.net>> wrote:
> >
> > On Thu, Nov 21, 2013
On Fri, Nov 22, 2013 at 10:24 PM, Reindl Harald wrote:
> your internal checks are mostly theory because in case of
> a bug you have undefined behavior and what you want to achieve
> with the watchdog is catch this undefined behavior and restart
> the service - in doubt this will not work in the ra
I'm disappointed in your response here. It's not up to your normally
high standards of technical discourse and tact on this mailing list. I
realize I've stepped on some feet, but there's quite a bit more to
this than me getting trigger-happy with a core commit.
On Fri, Nov 22, 2013 at 11:43 PM, Le
On Sat, Nov 23, 2013 at 7:53 AM, David Timothy Strauss
wrote:
> My attempts to discuss options and
> approaches with you at LinuxCon, on the mailing list, and IRC have
> only been marginally productive. Before my commit, we only had a TODO
> logged.
Actually, I'm being a bit unf
On Nov 25, 2013 4:36 AM, "Andrey Borzenkov" wrote:
>
> Interesting case (https://bugzilla.novell.com/show_bug.cgi?id=852021).
> Systemd enters emergency due to failed mount. At the same time syslog
> socket triggers syslog.service. Due to implicit Requires on
> basic.target which Requires sysinit.
On Mon, Nov 25, 2013 at 5:38 PM, Umut Tezduyar Lindskog
wrote:
> I would think port access protocols would be needed for servers even before
> sending a single IP package.
I've never used a server that required 802.1x. I've only encountered
it in places where physical network access is widesprea
On Tue, Nov 26, 2013 at 2:28 AM, Umut Tezduyar Lindskog
wrote:
> Any plans to support existing applications that are making use of thread
> level resource management? If not, what are we left with then, posix thread
> priorities?
Kay is right; there is no direct replacement. However, it's possi
On Tue, Nov 26, 2013 at 2:35 PM, Lennart Poettering
wrote:
> Not following here. What precisely does this fix, can you elaborate?
>
> We currently turn off the poll for the socket fds as soon as we queued
> the service socket, so that we don't get woken up anymore. What would
> EPOLLET do good her
Thanks. Applied.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Wed, Nov 27, 2013 at 2:32 AM, Lennart Poettering
wrote:
> Well, but EPOLLET only works correctly if each time an event is
> triggered we dispatch *all* possibly queued events on the fd, until
> EAGAIN is read again. But we don't do that, heck, if Listen=no is used
> we don''t even read a single
On Wed, Nov 27, 2013 at 6:23 AM, Shawn Landden wrote:
> I was worried that the fact that we never accept() the socket when using
> distribute (now I am convinced we shouldn't use it otherwise)
I'm not sure what you mean here. Distribute-style functionality is
absolutely useful with Accept=true (t
On Wed, Nov 27, 2013 at 7:57 AM, Shawn Landden wrote:
> Are you sure applications can handle the extra file descriptor of
> passing both the sockfd
> and the acceptfd in this case? I don't see why they wouldn't just do
> the accept() themselves?
>
> Can you explain what you mean here, and how it d
On Wed, Nov 27, 2013 at 12:03 PM, Lennart Poettering
wrote:
> Could you please explain what the usecase here is? Why is this better
> than having two socket units with two proxy services?
Right now, it's because separate services cannot exist in the same
network namespace with another service. Th
t;
wrote:
> On Wed, 27.11.13 14:09, David Timothy Strauss (da...@davidstrauss.net)
> wrote:
>
> > > If this is about running multiple things in the same Network namespace,
> > > then there are certainly other, better ways to achieve the same. For
> > > example, we
On Fri, Nov 29, 2013 at 1:58 AM, Umut Tezduyar Lindskog
wrote:
> Can someone explain the process level management?
Right now, it's possible to do directly in the cgroups file system,
but we're eventually moving away from anything manipulating that but
systemd. I think that there will still be a w
On Fri, Nov 29, 2013 at 12:53 PM, Lennart Poettering
wrote:
> On Fri, 29.11.13 00:11, Cecil Westerhof (cecil.wester...@snow.nl) wrote:
>> I have done a trial presentation about systemd. One of the questions
>> there was: when a restart of for example apache is doen, is this
>> restart done gracefu
On Nov 29, 2013 9:52 PM, "Cecil Westerhof" wrote:
>
> On 11/29/2013 08:59 AM, David Timothy Strauss wrote:
>>
>> On Fri, Nov 29, 2013 at 12:53 PM, Lennart Poettering
>> wrote:
>>>
>>> On Fri, 29.11.13 00:11, Cecil Westerhof (cecil.wes
On Sat, Nov 30, 2013 at 12:02 PM, Mantas Mikulėnas wrote:
> And smtpprox looks like it's a real daemon – when you start it, it
> continues to run waiting for connections. For this, Type=oneshot is
> wrong, and the default Type=simple should be right. (This also means
> KeepAfterExit= can be remove
On Wed, Dec 4, 2013 at 1:17 AM, Sascha Kattelmann wrote:
> Whats the status of this bug?
I personally think it would be best to:
(1) Keep the current behavior of sd_journal_seek_tail() +
sd_journal_previous_skip()
(2) Update the docs to reflect that usage
(3) Fix sd_journal_seek_tail() to set
On Thu, Dec 5, 2013 at 3:53 AM, "Jóhann B. Guðmundsson"
wrote:
> Never use a systemd unit to call modprobe.
And, even if you did, modprobe would be Type=oneshot (maybe also with
RemainAfterExit=true), definitely not Type=simple.
___
systemd-devel mailin
On Thu, Dec 5, 2013 at 7:29 AM, Colin Guthrie wrote:
> The above statement not withstanding, but the Type and RemainAfterExit
> applies only to ExecStart. This unit calls modprobe in ExecStartPre
> which is always expected to do something and return. So this branch of
> the thread really doesn't a
How reliable is the unit_id data this falls back to? If it's going
into an underscore-prefixed field in the journal, we need confidence
that it's not forgeable.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.or
This fails to apply for me. Just to check yours methods and mine, I
tried applying your "Ensure unit is journaled for short-lived or
oneshot processes" patch and succeeded. Comparing the two, it looks
like the text above the first triple-hyphen got dropped.
_
On Sun, Dec 8, 2013 at 12:23 PM, Dan McGee wrote:
> It is the "free(s->buffer);" bit that snuck in there from the other patches
> I sent this morning. I can rebase this one before those so it applies to the
> current tree, my mistake.
Aha! Applied. Thanks.
On Sun, Dec 8, 2013 at 8:25 PM, Shawn Landden wrote:
> This one doesn't work. I have have a somewhat-working next patch, but
> the way epoll_wait works it actually isn't
> lazy at all, and would require EPOLLET to even do
> one-spawn-per-connection (global connection), but we can't
> do that with
We currently use journal2gelf [1], which we also have a rewrite of
that uses the native Python bindings to the journal. We're probably
dumping our rewrite and adding journal integration to Beaver [2].
[1] https://github.com/systemd/journal2gelf
[2] https://github.com/clifton/beaver
___
After watching the results for an hour or so, this massively improves
the performance of is-enabled and several other systems on our heavily
loaded boxes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mail
On Thu, Dec 12, 2013 at 6:23 AM, Lennart Poettering
wrote:
> This isn't right. Units might be symlinked under different names, we
> need to support that. For example, all template instances carry a
> different name for the symlink then for the source.
Good point, though we could still support tha
On Wed, Dec 11, 2013 at 8:36 PM, Andrey Borzenkov wrote:
> This completely changes semantic of what it does. In this case no
> symlink is needed in the first place - just
> "touch .../unit.wants/other.unit" would be enough, as long as we assume
> units can only be located in standard config paths.
On Thu, Dec 12, 2013 at 8:15 AM, Kay Sievers wrote:
> We must not give the impression that this is "secure" in any way, it
> is not, and cannot generally be used unless it is secured by other
> things. So, no this is not secure at all, just possibly encrypted, but
> I doubt that was the question.
This new patch version fixes instance support by "replacing" the
instance with nothing, allowing a comparison equivalent to the one we
make against the target of the symlink (which is something like
abc@.service for instances).
___
systemd-devel mailing l
Hold on. This breaks is-enabled if you've enabled an instance *and*
that instance has its own override (using def@myinst.service versus
using def@.service).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/ma
On Sat, Dec 14, 2013 at 8:12 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> Are you sure that the sysctl is set early enough, before the listening
> socket is created?
Perhaps this is why your suggestion [1] for the journal bootup issue
didn't help.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=714
If we supported PIDFile= for Type=simple, daemons could drop a PID
file to indicate startup completion without having to be full-on
Type=forking.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
On Wed, Dec 18, 2013 at 10:32 AM, Holger Winkelmann [TP]
wrote:
> with HTTP you need to setup another server and provide a "Call back URL"
Folks seem to increasingly call this pattern "web hooks."
___
systemd-devel mailing list
systemd-devel@lists.freed
I replied in the thread with a subject line.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
It seems odd to combine Type=oneshot with Accept=false (which is the
default for socket activation). The latter setting causes systemd to
expect a persistent daemon to accept() connections.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.or
On Sun, Dec 22, 2013 at 11:43 AM, Tony Seo wrote:
> Frankly speaking, I don't understand why service daemon is infinitely
> spawned when I set the option "Accept= false".
> And Why couldn't the client process connect to socket unit that I made by
> setting "Accept= true".
I think you need to lear
On Sun, Dec 29, 2013 at 11:57 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> I have been looking at our bugs [1-10, there are others too] related to
> enabling/disabling of units and following of symlinks. Currently this
> is an unintuitive mess and some changes will have to be made.
Another goal I hav
On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer wrote:
> So using templated units, we could do for example :
> SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023
In the spirit of making isolation easy, it would be neat to have a
built-in convention for selinux isolation in systemd where the ful
On Mon, Dec 30, 2013 at 7:59 AM, Tony Seo wrote:
> That situation continued whether "Accept= true" or not in service unit.
The reason I encouraged you to learn more about socket programming is
because this Accept= option isn't some sort of optimization or nuanced
thing you just try either way unt
On Mon, Dec 30, 2013 at 9:53 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> Yep, this should be fixed too.
I'd be happy to sponsor fixes for all of this. I'm not sure if that's
the main blocker to getting this refinement done, but I want to remove
it right now if it is one.
On Tue, Dec 31, 2013 at 9:20 AM, Tony Seo wrote:
> But What I really want to know is why the server process always waited in
> the accept stage, when I executed client process for the first after system
> boot.
It may hang in accept() if the service is Accept=true and the daemon
still tries to ac
On Tue, Dec 31, 2013 at 3:33 AM, Michael Scherer wrote:
> I am not sure of the value of having 2 configuration file doing the same
> thing. What about
> SELinuxContext=auto , and so replace auto by some default configuration
> in that case ?
That works for me. I just like the idea of naming that
Just to consider what other folks are doing, I know Fedora builds
libcurl with a thread-isolated, NSS-based resolver.
On a less-related note, at Pantheon improve DNS performance on servers
by setting resolv.conf to localhost and running Unbound there. Unbound
then uses the datacenter's recursive D
On Sun, Jan 5, 2014 at 1:44 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> 3. The strategy of dup()ing the socket doesn't work. I wrote
>a simple server in python which logs the connections [2], and hooked
>it up into systemd [3-4] (*). If REUSEPORT was working correctly,
>each connection wo
On Mon, Jan 6, 2014 at 8:56 AM, Tony Seo wrote:
> But, I suspect that systemd has room not to get ACK from the server process
> executed by service unit.
> I concentrated on 3-way handshaking when I studied to analyze this problem.
>
> Isn't it right when we consider the systemd?
I'm not sure wha
We're running into this too with lots of automount units. They log a
fair bit as they start, and that overwhelms the journal buffer before
it starts.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/l
On Fri, Jan 17, 2014 at 12:17 PM, Lennart Poettering
wrote:
> Note that during really early boot the journal is not available yet,
> which means we can only log to kmsg then (and thus the
> console). However, as soon as the journal is available we then start
> logging directly to the journal. This
It would be nice if bootup could realize the journal queue is full and
wait for journal startup before proceeding further. It might cause
some annoying non-determinism, though.
We primarily see the problem with the logging from automounts and mount units.
__
JoinsNamespaceOf= probably only works for services because of how
namespace setup gets done just before forking off a process. I think a
socket get created in the namespace of the process instantiating it.
I'm not sure there's actually a way for PID 1 systemd to set up a
socket in a namespace othe
On Sat, Jan 18, 2014 at 8:45 AM, Dominique Michel
wrote:
> In /etc/fstab, we can set if a partition must be mounted or not at
> boot time, but not if, in the case it must be mounted, that partition is
> vital for the system (i.e. / or /var) and the system must wait for it to
> be mounted, or if th
On Tue, Jan 21, 2014 at 1:01 AM, Thomas Bächler wrote:
> So, I'd mask systemd-logind.service and remove pam_systemd.so from the
> PAM configuration (I think it's set so that failure is ignored anyway,
> but removing it should still be safer).
It will detect a lack of systemd-logind and no-op, but
Has anyone looked at using socketat() for this? It's unclear whether
that syscall actually exists in any supported form; it's certainly not
documented.
[1] http://lwn.net/Articles/407495/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
To join a namespace, you'll need a file descriptor for the namespace
so you can run setns() [1]. It's possible to share a file descriptor
by keeping it open while forking (which is how socket activation
works) or passing it over a Unix domain socket [2].
I know this doesn't really answer your ques
Our wiki page on the topic [1] was relevant before, but I'm pretty
sure we dropped ControlGroupAttribute= from the options. Any answer to
Barry's question here should probably involve an update to that wiki
page, too.
[1] http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
_
I think the intention for your needs (a lot of namespace sharing for a
family of services) would be to run another systemd in a namespece
using something like systemd-nspawn, libvirt-lxc, LXC, a user session,
or similar. Basically, a systemd instance would run in the namespace
itself. Is that a pro
You're using both onelan-player.slice and onelan-players.slice in your
example. Correct this first.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Alternatively, we should update the man pages to reflect what the
DefaultDependencies= option affects.
Zbyszek's argument for the patch, however, is that following the
recommended WantedBy= behavior already applies the same Before=
dependency, and anyone doing otherwise ought not to be subjected t
On Wed, Jan 29, 2014 at 3:14 AM, Lennart Poettering
wrote:
> What's the rationale here?
Three possibilities for an *enabled* timer with DefaultDependencies=true:
(1) WantedBy=timers.target, which redundantly adds
Before=timers.target (because DefaultDependencies already adds it)
(2) WantedBy= a
This seems applicable to what I'm working on (SaaS/PaaS company), but
I'm not sure I understand the distinction in capability this change
makes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listin
We would find this extremely useful. Our #1 long-term feature need is
a containerization tool that supports both socket activation and
selinux. libvirt-lxc has the former, but I'm seeing inconsistent
documentation on the latter. I'd be glad to see systemd-nspawn get
good support.
__
On Sun, Feb 2, 2014 at 8:55 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> I'm not certain if the current version is gramatically correct, but
> the proposed version seems wrong: there's just one sender, so only
> singular form makes sense.
The current text makes more sense to me.
_
On Tue, Feb 4, 2014 at 5:22 AM, Lennart Poettering
wrote:
> processlabel
The actual code processes this option as "label." I'll fix all of this
up (including the asprintf) and then commit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.o
Pushed with the following changes:
* Lennart's suggestions for option names.
* Lennart's other suggestion for no asprintf() in the options
processing. Moved the concatenation to strjoin() on use.
* Removed redundant trailing NULL in the arguments to strjoin().
* Removed invalid option "-s" from
"Elided" sees widespread use in the kernel and libc for locks:
http://lwn.net/Articles/534758/
They're not referring to adding ellipses, though. They're talking
about just removing locks. In that sense, "elide" and "ellipsize" are
not synonyms.
___
syste
In order to maximize consistency with newly committed options in
systemd-nspawn, would it make sense to allow independent configuration
of the process and file labels instead?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists
+1 on no crashing with invalid user input
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Wed, Feb 12, 2014 at 12:37 PM, Tomasz Torcz wrote:
> That's some downstream distro bug. And this is Fedora mailinglist.
> RHEL issues are offtopic here.
This is not a Fedora mailing list at all.
___
systemd-devel mailing list
systemd-devel@lists.fre
The only thing in master I'm still having to patch in production is
the is-enabled code path so it doesn't look up all the symlinks. I
don't see that as a release blocker, though.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://l
On Wed, Feb 19, 2014 at 10:57 AM, Lennart Poettering
wrote:
> did you see the changes I made to the cgroup mask propagation bits? I
> reworked some code there to make sure that the mask doesn't keep
> increasing, but actually can lose bits again if cgroup properties are
> unset. Now, as far as I c
On Wed, Feb 19, 2014 at 10:57 AM, Lennart Poettering
wrote:
> Now, as far as I can see I didn't break your scalibility changes,
> but I was wondering if you could give this a test run with your huge
> number of units setup?
With 4000 units (2000 sockets and 2000 corresponding services with
CPUSha
101 - 182 of 182 matches
Mail list logo
