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
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
> 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
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
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.
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.
__
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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]
__
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
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
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 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: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
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
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
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
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
Didn't we recently drop this option?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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.
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
> 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]
___
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
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
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
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
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-
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
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
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
Please ignore. This patch is incomplete.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
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
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
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
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
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 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
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
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.
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
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
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
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
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
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
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.
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
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
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
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
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
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,
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
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
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 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
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
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
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
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
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
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
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 is not the solution we need. :-(
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
Comments welcome (please reply here):
https://wiki.php.net/rfc/socketactivation
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
st of the man pages, especially the systemd.service one,
and this is the first I've heard that oneshot couldn't do reload in
the first place.
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-dev
main file system.
Has anyone else looked into this?
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Thu, Oct 18, 2012 at 12:03 PM, Mirco Tischler wrote:
> Every deviation I would count as a bug. Or is my logic flawed?
That's my logic, too. Unfortunately, it's not what happens right now.
--
David Strauss
| da...@davidstrauss.net
__
Here is the initial ticket with implementation:
http://trac.nginx.org/nginx/ticket/237
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd
d filtering are
already part of that interface for using local (including mounted
network file system) files.
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
ened
> for user root by sweetth(uid=0)
>
>
> Many thanks for your time and assistance,
>
>
>
> _______
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
run with their
>> cursor as the identifier. ___
>> systemd-devel mailing list systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> setroubleshoot would be interested in this also, since it would eliminate the
> need to run with the audit daemon. But journal needs to be getting audit
> data.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCcBCUACgkQrlYvE4MpobNa/gCdHkTSLU4AC/1PRce6zm/0ZwEB
> X8gAoLYRinLAPafNQc+cDHqxLz+Kk3pE
> =fDOK
> -END PGP SIGNATURE-
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
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 Sun, Nov 11, 2012 at 5:24 PM, David Strauss wrote:
> Units "subscribed" to specific message IDs has two negative effects
I meant to say:
Units "subscribed" to specific message IDs *via the unit name* have
two negative effects...
__
t I'd like consensus on what it should be.
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I just enabled anonymous access to the build workspace on the Jenkins
server. Aside from making the build artifacts downloadable, this
allows web access to the man pages for HEAD:
http://systemd.getpantheon.com:8080/jenkins/job/build-master/ws/man/index.html
If you bookmark this, it will *always*
ut systemd won't
consider the stopping of the first service and the starting of the
second a transaction.
--
David Strauss
| da...@davidstrauss.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
r/msg00014.html
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
hut down. If the service
handles its own accept() for connections, systemd won't know about
those connection file descriptors or handle their persistence across a
daemon restart.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
1 - 100 of 282 matches
Mail list logo
