I could be missing something, but I think there's a gap in the
functionality for timers for periodic tasks on battery-powered devices.
Basically, I want to generate a security report (SCAP style) approximately
weekly but avoid doing so on battery.
Here's what I've tried or looked at:
- If I use C
> But I don't want to wait for those services to shutdown.
Then there's no reason to interact with systemd if you want to force an
immediate, unclean reboot. You just want something like the reboot syscall
with LINUX_REBOOT_CMD_RESTART.
___
systemd-devel
This failure is not from systemd; systemd is only the messenger:
> Mar 07 11:08:09 3CX systemd[1]: 3CXPhoneSystemMC01.service start
operation timed out. Terminating.
Someone needs to troubleshoot why 3CXPhoneSystemMC01.service is hanging
when it tries to start, and this list can't answer that. Yo
Admin-created service files should go in /etc/systemd/system/. You
manage them using systemctl and the name of the service file *with no
path*.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinf
This is not the solution we need. :-(
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I'm specifically wondering if it's safe to use cgroup_mask in slices
to aggregate the masks of their children. If not, it's trivial to add
another item to the struct (like cgroup_mask_children) to use for
aggregation.
___
systemd-devel mailing list
system
This may need a few tweaks, most notably the extraneous log items. Is
this a decent approach, though, to caching cgroup mask data?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-dev
Another critical feature for server configs is bonding. It's possible right
from Kickstart and with the normal configurations in Fedora. We use it on
every bare-metal server we manage to get HA networking.
___
systemd-devel mailing list
systemd-devel@list
On Sat, Nov 2, 2013 at 11:40 PM, Peter Lemenkov wrote:
> Does it add anything if I change
> type of a main service to "dbus" thus allowing systemd to know for
> sure if my service is fully initialized?
Yes. Changing to Type=dbus will cause systemd to only consider the
service fully started after
I did a quick follow-up to make some of them %zu where they're
actually unsigned. Can you let me know if that still works for you?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-dev
Committed. Did you happen to be on 32-bit? I didn't see any warnings
on my own builds (64-bit Fedora 19).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Thank. I'll commit this once I'm at my desk.
On Oct 31, 2013 11:26 AM, "Ronny Chevalier"
wrote:
> multiple warnings like
>
> src/socket-proxy/socket-proxyd.c: In function ‘transfer_data_cb’:
> src/socket-proxy/socket-proxyd.c:237:25: warning: format ‘%ld’ expects
> argument of type ‘long int’, bu
On Mon, Oct 28, 2013 at 11:30 AM, Lennart Poettering
wrote:
> So yeah, cool feature, and I'd be very happy to see this in PID 1, but I
> am very sure we shouldn't merge this tool like this!
Can I get some pointers on how to do it in PID 1? If I start them the
same way as the semicolon delimiter f
On Mon, Oct 21, 2013 at 4:59 AM, David Strauss wrote:
> I've already noticed that it doesn't work so well with multiple processes and
> EPOLLIN to do
> accept() callbacks (like in systemd-socket-proxyd), but I'm looking for
> options there.
Thanks to some helpful a
On Mon, Oct 21, 2013 at 7:08 AM, Tom Gundersen wrote:
> This is a cool feature. However, it seems to me that adding it to the core
> makes much more sense, that way the children can be managed properly by
> systemd as real services. What problems do you see with adding this to pid1?
There's no in
Since there aren't docs yet, here's an example way to run it:
ExecStart=/usr/lib/systemd/systemd-socket-process-poold
/usr/lib/systemd/systemd-socket-proxyd example.com http
systemd-socket-proxyd will complain about trying to accept() and
failing because of the stampede issue I mentioned in my la
This daemon is a proof-of-concept that manages a process pool of
(usually) socket-activated child processes. It exploits the ability to
have multiple processes accept() on the same socket, allowing the
kernel to distribute requests among the children. We've talked about
adding this to systemd core,
For anyone watching here at home, the utility is now named
systemd-socket-proxyd in git.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Initial perf results confirm cgroups rework as the culprit. We're
seeing huge time spent in unit_get_members_mask,
cgroup_context_get_mask, and unit_get_cgroup_context.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freede
On Wed, Oct 16, 2013 at 6:59 AM, Kay Sievers wrote:
> Also this thing does not actually *activate* anything it just proxies.
I was going more for socket *activated* proxy, in the sense that the
proxy uses socket activation to get its listen() fd.
> And long-running processes should get a d(aemon
On Wed, Oct 16, 2013 at 4:34 AM, Lennart Poettering
wrote:
> This is explicitly not supported by epoll, as discussed earlier. You
> should get an EEXIST if you try to do this, and rightfully so.
Yes, but I only truly understood what you meant after having failure
as the teacher (and then fixing i
It turned out to be an error on my part in assuming systemd's event
library abstracts sources from watched fds added to epoll. saproxy now
manages its own bitwise operations and only uses a single
source/watcher per socket fd.
___
systemd-devel mailing li
This appears to be a case of having more than one source enabled for
the same fd, even if they're for different conditions (EPOLLIN vs.
EPOLLOUT). I'm looking now at changing the code to use only one source
but in a disabled, EPOLLIN only, EPOLLIN only, or EPOLLIN | EPOLLOUT
state.
We're also looking at supporting process-pools at the system
service/socket level.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedes
On Tue, Oct 15, 2013 at 5:33 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> So, is the bump to 16kB based on benchmarking? If you could post any
> results that would be great. Also, how does the original threaded aproach
> compare to the sd_event based one?
The 16kB bump is based on using the same buff
On Mon, Oct 14, 2013 at 1:25 PM, David Strauss wrote:
> On Mon, Oct 14, 2013 at 12:33 PM, Lennart Poettering
> wrote:
>> COuld you rebase please and try to reproduce
>> the issue?
>
> I'm not seeing the issue anymore after doing that, but I may have
> fixed some
Oh, and Zbigniew, if you have any follow-ups on the code I pushed to
master, I'm happy to handle them right now. 100% of your feedback
should either be implemented or in the TODOs. If you think any of the
TODOs are release blockers, I can handle those now, too.
My backup plan if we think the shell
EWOULDBLOCK, even if it
got a partial send(). This also works well under load tests.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I've merged this. I'll update the main task list with follow-up work.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Connection structs were using dirty memory for the buffer offsets,
which were the only struct members not initialized. This had worked
fine in all of my small tests, but under load it was failing terribly.
Using malloc0() causes it to now work with any level of concurrency.
The partial-send and recv is still buggy. :-(
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Oct 15, 2013 at 1:59 PM, David Strauss wrote:
> One question, though: Is it safe to assume send will block if it
> returns having sent fewer bytes than requested?
Much searching is not giving me an answer, so I've also posted [1] to
Stack Overflow.
[1]
http://stacko
One question, though: Is it safe to assume send will block if it
returns having sent fewer bytes than requested?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On less-exhausted self-review, the partial send code is broken here.
Please await a follow-up.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
lso some comments below the --- about what changed in v2 and v3
> etc. would be nice).
Ah, I see now. git send-email does that if you use --thread and
--no-chain-reply-to. I'll use those in the future.
--
David Strauss
| da...@davidstrauss.net
Current feature limitations I'd like to overcome *after this gets in master*:
* getaddrinfo() is still blocking, though this shouldn't be an issue
for things like "localhost."
* Running sabridge in the same namespace as the daemon requires an
ugly shell script.
* The nginx shell script may be ra
On Mon, Oct 14, 2013 at 5:53 PM, Kay Sievers wrote:
> Please give it a name a human can parse and pronounce. :)
sa-bridge? act-bridge? other suggestions?
I named it in the spirit of cgtop, systemctl, etc., none of which use
delimiters.
--
David Strauss
| da...@davidstrauss.net
| +1
Of course, I can commit this myself if there are no objections. The
risk to non-users of the tool is pretty much zero.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Please ignore. This patch is incomplete.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Oct 14, 2013 at 12:33 PM, Lennart Poettering
wrote:
> COuld you rebase please and try to reproduce
> the issue?
I'm not seeing the issue anymore after doing that, but I may have
fixed something on my side, too.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5
Slightly better performance now with per-connection buffers.
[root@olympian systemd]# ab -n1000 -c10 http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, h
Right now, I'm just using inet_ntop() for IP clients and nothing for
other types, but this does the annoying IPv6-mapped-IPv4 formatting.
instance_from_socket() in socket.c has some nice checks for this so
IPv4 comes out as a dotted quad, but maybe we should move that to
shared code?
It would be u
without *any* conditionals for
the different types? Basically, I'd like to get just a string
describing the client origin.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-
I'm not using multiple threads. This is occurring when I create, then
mute, and then unmute an IO source.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Oct 14, 2013 at 3:53 AM, David Strauss wrote:
> Here's a revised version that should be pretty close to done
And also aside from my Unix socket and IPv6 TODOs, which are tiny.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827
end in a proper patch set. The full
sabridge branch is here [1], including the sd-event.c fix for EEXIST.
[1] https://github.com/davidstrauss/systemd/tree/sabridge
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd.
Copyright 2013 David Strauss
ssume we should ignore it in the event library?
[1] http://linux.die.net/man/4/epoll
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedeskto
and
> quite happily running with a few thousand threads, no matter the number
> of cores.
The number of processes or threads per core shouldn't substantially
affect any architecture work we're doing.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
s is useful for ensuring we have consistent support for
server-first (MySQL) and client-first (HTTP) protocols.
[1] https://github.com/systemd/systemd/pull/5/files
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd.
Copyright 2013 David Strauss
and Twisted. Both support socket
activation these days, but they have no reliable mechanism for
distributing the load across multiple processes.
So, a big +1 to generic support for pools of socket-activated
processes that still run accept() on their own.
--
David Strauss
| da...@davidstrauss.
Didn't we recently drop this option?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Thu, Oct 10, 2013 at 1:20 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> Best-practice is using just one thread :)
That depends on whether you need to scale up to multiple cores.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mob
I was actually planning to rewrite on top of libuv today, but I'm
happy to port to the new, native event library.
Is there any best-practice for using it with multiple threads?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lis
gt; and start the target binary itself. But maybe that's not so bad,
> since the proxy can be introduced by adding one word to ExecStart=.
This is why I opted for the tiny script to start nginx and then the
bridge in my proof-of-concept implementation.
--
David Strauss
| da...@davidstrauss
The bridge won't relay traffic until it gets a connection. This is also no
worse than the situation with other systemd services.
On Oct 8, 2013 3:28 PM, "Cristian Rodríguez"
wrote:
> El 08/10/13 08:56, David Strauss escribió:
>
> > (2) Waits for nginx's PID file
On Tue, Oct 8, 2013 at 4:56 AM, David Strauss wrote:
> There's no reason it couldn't scale to any number in future versions.
Sorry for the copious replies, but I have another thing to add here.
The current design doesn't rely on globals; it passes all state up the
stack in the
I should also mention that the way I've integrated libev in the
autotools chain makes it optional. If you don't have it, you just
won't get the bridge utility.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org
On Tue, Oct 8, 2013 at 4:12 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> how do you intend target service to be started? I understand that the
> intended use case case is for non-socket-activatable services, so they
> should be started synchronously in the background. In case of local
> services norma
I'll get a proper git-based patch up here later this week. I just
wanted to post something before heading home.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
tage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 2
95% 2
98% 2
99% 2
100% 3 (longest request)
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd.
C
probably means you've missed some
items. That might be worth knowing rather than silently handling. You
can always fall back to fetching all if the cursor has rolled out of
memory.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
__
- I need to transfer this data in a clearly readable format (plain text) as
> I want to read the log entries via webinterface.
Not that this matters anymore, but you could do this with the journal
gateway service. It allows reading journal files on a machine over the
web, whether the client is a
Instead of doing your own compressed dump to flash, how about this:
(1) Enable persistence.
(2) When you want a backup, force rotation by sending the journal SIGUSR2 [1].
(3) Copy away the rotated journal file and delete it.
This would allow getting entries in a way that's compressed and never
ecord a special log entry just before you dump.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
David Fisher has kindly informed me that high-level socket activation
support is now available for Haskell developers!
http://hackage.haskell.org/package/socket-activation
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile
And, of particular importance to some high-density users: unit
ordering reworked around a hashmap that scales much better with large
numbers of Unix socket and mount units. Initial testing shows
daemon-reload times dropping from 8+ seconds to under 2 with thousands
of mount+automount unit pairs. Fu
On Tue, Oct 1, 2013 at 6:13 AM, Colin Guthrie wrote:
> Ouch 5s for a status is nasty.
We regularly see this on our production systems. Yes, it's unfortunate.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
syste
I would strongly prefer Brussels for travel reasons.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
It's also possible to create your own file system type. "mount"
(including via systemd mount units) simply invokes
/usr/sbin/mount.YOURTYPEHERE as root.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailma
Does this supersede your earlier patch for get_status_field()?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
The larger backtracking ("t -= 2;") makes assumptions about the source
data and pattern that make Zbigniew and me uneasy. Zbigniew apparently
has a bunch of tests in this area that should land soon. We can take a
fresh look then.
___
systemd-devel mailing
e/systemd/man/systemd.exec.html
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Committed, including the spelling fix.
signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Wed, Aug 14, 2013 at 11:11 PM, Harald Hoyer wrote:
> Linux Foundation is looking into it. Right now they don't have space, but they
> are trying to find something for us. We should know early/mid next week.
Any word on this?
--
David Strauss
| da...@davidstrauss.net
| +1 5
ing any tests beyond a
successful build. I plan to continue maintaining the Jenkins CI, if
only to ensure the systemd GitHub mirror is always buildable on the
master branch.
[1] http://systemd.getpantheon.com/
--
David Strauss
| da...@davidstrauss.net
| +1 512 577
However, I should ask if we have space formally reserved yet. I'm
willing to go in on costs here if we need that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Aug 13, 2013 at 7:36 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> Is this definite?
With 10 RSVPs, we'll make it happen. I added the G+ event after Kay
said, "The current idea is to do [a hackfest] during the two LinuxCon
days before Plumbers starts."
--
Dav
On Tue, Aug 13, 2013 at 1:23 PM, David Strauss wrote:
> Thanks. That's all I need to know for booking. I'll edit the systemd
> wiki if it's not already there.
I noticed there wasn't a G+ event for it, either. So, I made one [1]
and posted it to the Hackfest sectio
On Tue, Aug 13, 2013 at 1:16 PM, Kay Sievers wrote:
> The current idea is to do that during the two LinuxCon days before
> Plumbers starts.
Thanks. That's all I need to know for booking. I'll edit the systemd
wiki if it's not already there.
--
David Strauss
| da...@dav
Are there any plans?
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Aug 5, 2013 at 12:59 AM, David Strauss wrote:
> I'll be following up with them to see if
> there are good coordination opportunities, especially around socket
> activation, security isolation, and resource management.
We're meeting Monday afternoon at my office do
focus [2] for me.
[1] http://coreos.com/
[2]
http://www.linuxjournal.com/content/containers%E2%80%94not-virtual-machines%E2%80%94are-future-cloud
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing
ociate with a mount
unit to invoke the "mount" command as root.
It would seem possible to use it with a new UID namespace, but such
capability is very new and disabled in kernels like Fedora's. You
could also just treat FUSE mounts as normal services in the user
account.
--
David S
Oh, just noticed your attached boot chart. That definitely doesn't
look right, but I'm not really sure what the problem is. It looks like
no single service is blocking the other services, just that a ton of
things already running in parallel are taking excessive time.
__
Please don't send HTML mail to this list.
On Thu, Jul 25, 2013 at 4:58 AM, Tony Seo wrote:
> 1. what is "-.mount" ?
> when I first saw "-.mout", I was confused how to configure it.
You configure it from the /etc/fstab entry for the root file system,
which then generates that unit during boot-up.
With thousands of units, doing a daemon-reload puts a surprisingly
huge CPU and memory burden on the system. Has anyone profiled why? I'd
like to get started on optimizing this, but I'll obviously need to
understand where the problem is first.
--
David Strauss
| da...@davidstrauss.n
On Sun, Jul 14, 2013 at 10:40 PM, Holger Hans Peter Freyther
wrote:
> Maybe do "echo 'Not running tests as they always fail in this setup.'"
> is better? There were several fanboys sending me private mail claiming
> that the tests were run because of the 'ma
On Mon, Jul 15, 2013 at 4:32 AM, Tom Gundersen wrote:
> Most probably due to GMail (or something similar) ignoring
> In-Reply-To, and instead grouping messages by Subject.
Oh, my apologies! I do use GMail, and all I saw was the
"[systemd-devel] Manpage updates" message with no replies or patches.
On Sun, Jul 14, 2013 at 4:19 PM, Jan Engelhardt wrote:
> There is inherently no series possible, nor would I think that splitting
> {the single patch as emitted by the below recipe} into multiples by
> group of correction type (grammatical, typograhical, etc.) would offer
> benefit.
I clearly sai
Would you mind posting these as a patch or patch series here? It cuts
down on review time.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Sorry for not chiming in earlier. I was traveling with limited connectivity.
I added the CI because I was frustrated with the frequency of my
"master" clone builds failing and, more importantly, the duration they
would remain broken. By "failing," I mean actually failing to build,
not build *and*
On Mon, Jun 24, 2013 at 9:55 AM, David Strauss wrote:
> For example, you certainly wouldn't want the box to go into swap because of
> start-up allocation spikes.
I should clarify: that's not a context-switching example. It's just
another case where throttling might he
In our case, the issue wasn't kernel process creation; it was the CPU
and I/O overhead of service start-up. At some point, the system gets
dominated by context-switching, and throughput suffers. For example,
you certainly wouldn't want the box to go into swap because of
start-up allocation spikes.
Exciting! You should post this to the systemd group on Google+.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
mmend other users use cgroups on
systemd-based distributions.
So, +1.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
It definitely works for me on Fedora, but it's terribly slow with
1000+ units. I've been meaning to look into that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
from socket activation and accept connections
on it even if it doesn't have permission to unlink the socket.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.free
We have machines with thousands of containers on them. The key for us
was understanding that we didn't need thousands of containers to run
after start-up; we needed thousands of containers to be *accessible*
after start-up. The vast majority of our containers use socket
activation or "resurrection"
On Tue, Jun 11, 2013 at 10:59 PM, Michael Olbrich
wrote:
> Not for me. "systemctl {start,stop} " never prints anything.
I think it "prints status" in the Unix way: stderr explanation on
failure and nothing on success.
--
David Strauss
| da...@davidstrauss.net
|
On Thu, Jun 6, 2013 at 10:15 PM, David Strauss wrote:
> I'll be especially interested if we can work for three or four of the hacking
> days.
To clarify, I mean if systemd developers are hacking together for at
least three of the days.
--
David Strauss
| da...@davidstrauss.net
1 - 100 of 282 matches
Mail list logo
