On Tue, Jan 22, 2013 at 7:46 PM, Lennart Poettering
wrote:
> While we generally try to avoid supporting too many different formats
> and protocols in systemd, and only support those we really know we can
> support for good and make work well, and where we know they have a
> strong future I think "
On Tue, Jan 22, 2013 at 10:17 PM, Kok, Auke-jan H
wrote:
> I'm pushing for cleaning up Simon's patch and including it in the tree
> - it will directly replace the python code since the output and
> interface is consistent with the old output.
Yep, don't interpret my critique over the format to me
On Tue, Jan 22, 2013 at 7:46 PM, Lennart Poettering
wrote:
> On Tue, 22.01.13 16:15, David Strauss (da...@davidstrauss.net) wrote:
>> I was writing up a bunch of arguments in favor of DOT (now deleted
>> after reviewing the existing "analyze" output and how DOT would not be
>> good for achieving i
On Tue, Jan 22, 2013 at 7:33 PM, Kay Sievers wrote:
> On Wed, Jan 23, 2013 at 4:21 AM, Lennart Poettering
> wrote:
>> On Mon, 21.01.13 14:33, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
>>
>>> > ps: doing some extra cleaning on the code, expect a new patch soon.
>>>
>>> I just updated my EF
On Tue, 22.01.13 02:33, JB (gene...@itpsg.com) wrote:
>
> Subsequent starts and stops of the application of course do not
> change those process ID and kernel threads because, I can only
> assume, they are reused. A kill -9 as root will not even kill them.
> The problem I have is that system shu
On Mon, 21.01.13 13:38, Umut Tezduyar (u...@tezduyar.com) wrote:
> I would like to start a service on shutdown/restart. This service accesses
> (read/write) to the file systems and for that reason I don't want any of
> the file systems unmounted by systemd before the service completes.
Right now
On Wed, Jan 23, 2013 at 04:49:00AM +0100, Lennart Poettering wrote:
> On Wed, 23.01.13 04:08, Kay Sievers (k...@vrfy.org) wrote:
>
> > >> Not sure what the best way is to detect an architecture where time_t is
> > >> "long long" rather than "long". I figure there must be some macro we
> > >> could
On Wed, 23.01.13 04:08, Kay Sievers (k...@vrfy.org) wrote:
> >> Not sure what the best way is to detect an architecture where time_t is
> >> "long long" rather than "long". I figure there must be some macro we
> >> could check for. If we have that, the code can be changed to:
> >>
> >> #ifdef MACR
On Tue, 22.01.13 16:15, David Strauss (da...@davidstrauss.net) wrote:
>
> I was writing up a bunch of arguments in favor of DOT (now deleted
> after reviewing the existing "analyze" output and how DOT would not be
> good for achieving it). But, I'd really prefer moving the output to
> something m
On Sun, 20.01.13 18:00, Peeters Simon (peeters.si...@gmail.com) wrote:
> Hej all,
>
> Because of the discution about the python dependencies for systemd-analyze
> I made a rewrite in C.
>
> The patch is available from my github repo[1] so please test it.
> (especially efi systems with gummyboot
On Wed, Jan 23, 2013 at 4:21 AM, Lennart Poettering
wrote:
> On Mon, 21.01.13 14:33, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
>
>> > ps: doing some extra cleaning on the code, expect a new patch soon.
>>
>> I just updated my EFI system to HEAD with your latest patch applied,
>> and everyt
On Mon, 21.01.13 14:33, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
> > ps: doing some extra cleaning on the code, expect a new patch soon.
>
> I just updated my EFI system to HEAD with your latest patch applied,
> and everything works fine - the DBus warnings are now gone.
>
> However, I'
On Sat, 19.01.13 04:24, poma (pomidorabelis...@gmail.com) wrote:
>
> On 01/18/2013 07:23 PM, Lennart Poettering wrote:
> > On Fri, 18.01.13 16:57, poma (pomidorabelis...@gmail.com) wrote:
> >
> >>
> >> Bonne journée,
> >>
> >> If brackets can be of any help.
> >> Lennart, have you tested this *n
On Fri, Jan 18, 2013 at 11:11 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Jan 18, 2013 at 07:34:29PM +0100, Lennart Poettering wrote:
>> On Fri, 18.01.13 18:22, Stephan Raue (mailingli...@openelec.tv) wrote:
>>
>> >
>> > Am 18.01.2013 18:14, schrieb Colin Walters:
>> > >On Fri, 2013-01-18 at
On Sat, 19.01.13 00:03, Ian Pilcher (arequip...@gmail.com) wrote:
> Is there any way to create something like an "instantiated socket"?
Nope, there isn't. We currently do not allow this because we don't
really know what to the per-connection service instances would be called
like. i.e. if the soc
test-unit-file links with libsystemd-core which needs
sd_* symbols from libsystemd-daemon
Signed-off-by: Khem Raj
---
Makefile.am |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index 7d5bd5a..884227a 100644
--- a/Makefile.am
+++ b/Makefile.am
@
On Mon, 21.01.13 21:56, poma (pomidorabelis...@gmail.com) wrote:
> This is contradictory to what I have experienced with DisplayLink DL-165
> based device[1].
> *Without engaging multiseat(udev's rule)* picture is garbled on the
> connected monitor, regardless of whether monitor(DVI) comes with th
On Mon, 21.01.13 15:25, Stef Bon (stef...@gmail.com) wrote:
> Hi,
>
> I'm experimenting with the plugable ud-160-A as seat extender. I'm
> borrowing it from Hans de Goede.
>
> Now it works very good, only with new monitors using the newest EDID
> technique it blocks. Hans has already posted a pa
On Tue, 22.01.13 16:25, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> On Sun, Jan 20, 2013 at 04:27:58PM +0100, Eelco Dolstra wrote:
> > ---
> > man/systemd.service.xml | 2 +-
> > src/core/manager.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> Applied.
>
> >
On Mon, 21.01.13 16:29, Paul Wouters (pwout...@redhat.com) wrote:
> >>A solution for now could be to
> >>'sed s/Restart=yes/Restart=no/ ipsec.service >
> >>/run/systemd/systemd/ipsec.service'
> >>and 'systemctl daemon-reload'. The changes will go away at next
> >>reboot. (This will only work if y
On Tue, 22.01.13 18:25, Scott Shambarger (scott-syst...@shambarger.net) wrote:
>
> (oops, forgot to reply-all :)
>
> On 2013-01-22 17:14, Lennart Poettering wrote:
> >On Tue, 22.01.13 16:55, Scott Shambarger
> >(scott-syst...@shambarger.net) wrote:
> >>Agreed, however I'd like to suggest another
(oops, forgot to reply-all :)
On 2013-01-22 17:14, Lennart Poettering wrote:
On Tue, 22.01.13 16:55, Scott Shambarger
(scott-syst...@shambarger.net) wrote:
Agreed, however I'd like to suggest another possibility. Perhaps
journalctl could add an option to output to a syslog socket (say
here /ru
I was writing up a bunch of arguments in favor of DOT (now deleted
after reviewing the existing "analyze" output and how DOT would not be
good for achieving it). But, I'd really prefer moving the output to
something more semantic like callgrind [1] or HAR [2]. DOT is
certainly more semantic than SV
'Twas brillig, and Lennart Poettering at 22/01/13 22:11 did gyre and gimble:
> Heya,
>
> I just learned that a number of systemd downstream and upstream folks
> are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog
> Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around.
>
On Tue, Jan 22, 2013 at 2:14 PM, David Strauss wrote:
> On Sun, Jan 20, 2013 at 9:00 AM, Peeters Simon
> wrote:
>> Because of the discution about the python dependencies for systemd-analyze
>> I made a rewrite in C.
>
> I was only advocating for the data collection side to move to C so
> small,
On Sun, Jan 20, 2013 at 9:00 AM, Peeters Simon wrote:
> Because of the discution about the python dependencies for systemd-analyze
> I made a rewrite in C.
I was only advocating for the data collection side to move to C so
small, Python-less systems can still dump startup data for analysis
elsewh
Heya,
I just learned that a number of systemd downstream and upstream folks
are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog
Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around.
We were wondering whether it might be a good idea to meet up for some
kind of systemd B
A quick web search is failing me, so I'll ask here: is this "type X" a
novel thing you're introducing or something used elsewhere? I don't
see it mentioned in Lennart's overview of tmp storage areas [1],
either.
[1] http://0pointer.de/blog/projects/tmp.html
On Fri, Jan 18, 2013 at 7:13 AM, wrot
If unmounting happens, deterministically, before shutdown, why not
make your service WantedBy=umount.target (maybe still with
DefaultDependencies=no)?
On Mon, Jan 21, 2013 at 4:38 AM, Umut Tezduyar wrote:
> Hi
>
> How do I start a service on shutdown that will start and finish before any
> of the
On Tue, Jan 22, 2013 at 1:40 PM, Lennart Poettering
wrote:
> We
> had the question of creating C libraries for wrapping D-Bus APIs in
> GNOME upstream a few years ago, and we all came to the conclusion that
> instead of writing those we should rather make the D-Bus python glue
> nicer. The result
On Tue, 22.01.13 15:02, Scott Shambarger (scott-syst...@shambarger.net) wrote:
> I'm running Fedora 17 with rsyslog, but since I also need to also
> receive logs via UDP, I've updated rsyslog.service to include
> After=network.target (so the private network binding works).
>
> However, syslogs cr
On Fri, Jan 18, 2013 at 10:03 PM, Ian Pilcher wrote:
> Accept=true
This, alone, would instantiate a new service for each client
connection. But, combined with MaxConnections=1, you'll deny any
connections if one is active.
> ExecStart=-/usr/bin/Xvnc -SecurityTypes None -query 127.0.0.1 -inetd -o
On Tue, 22.01.13 08:43, George McCollister (george.mccollis...@gmail.com) wrote:
> Are there plans (or desire) to expand the Python module included
> with systemd beyond Journal? Is there desire to replicate or wrap
> functionality provided by the DBUS API or is this beyond the design
> scope of t
On Tue, Jan 22, 2013 at 10:02 PM, Scott Shambarger
wrote:
> I'm running Fedora 17 with rsyslog, but since I also need to also receive
> logs via UDP, I've updated rsyslog.service to include After=network.target
> (so the private network binding works).
>
> However, syslogs created before network.t
I'm running Fedora 17 with rsyslog, but since I also need to also
receive logs via UDP, I've updated rsyslog.service to include
After=network.target (so the private network binding works).
However, syslogs created before network.target aren't forwarded to
rsyslog when it's started (rsyslog is
On Tue, Jan 22, 2013 at 6:43 AM, George McCollister
wrote:
> Is there desire to replicate or wrap functionality provided by the DBUS API
> or is this beyond the design scope of this module?
I think it would be worthwhile to support Pythonic APIs for things
like what systemctl can do from the CLI.
On Tue, Jan 22, 2013 at 7:01 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> The package is stuctured so that it is possible to easily add new
> modules. Any new additions would have to be generally useful to be
> included in the main package. It's just that so far, no extensions
> have been proposed, so
On Sun, Jan 20, 2013 at 04:27:58PM +0100, Eelco Dolstra wrote:
> ---
> man/systemd.service.xml | 2 +-
> src/core/manager.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Applied.
> diff --git a/man/systemd.service.xml b/man/systemd.service.xml
> index f7cbbb4..891b347 100644
> -
On Tue, Jan 22, 2013 at 08:43:07AM -0600, George McCollister wrote:
> Are there plans (or desire) to expand the Python module included
> with systemd beyond Journal? Is there desire to replicate or wrap
> functionality provided by the DBUS API or is this beyond the design
> scope of this module?
Hi
Are there plans (or desire) to expand the Python module included with
systemd beyond Journal? Is there desire to replicate or wrap
functionality provided by the DBUS API or is this beyond the design
scope of this module?
Regards,
George McCollister
_
'Twas brillig, and Stef Bon at 21/01/13 18:31 did gyre and gimble:
> Lennart wrote here:
>
>
> http://0pointer.de/blog/projects/multi-seat.html
>
> (Later on we'll probably have a graphical setup utility for additional
> seats, but that's not a pressing issue we believe, as the plug-n-play
> mul
'Twas brillig, and Paul Wouters at 21/01/13 21:29 did gyre and gimble:
> On 01/16/2013 11:09 AM, Lennart Poettering wrote:
>> On Mon, 14.01.13 02:22, Zbigniew Jędrzejewski-Szmek
>> (zbys...@in.waw.pl) wrote:
>>
But I don't want to _stop_ the service. I want the running service
to not rest
Hello again,
I've worked around ruby's daemonize implementation by rewriting the
app to be of type simple. However, now I'm seeing the long delay on
stop after the application it executes has run once. The application is
a real time app utilizing RTAI. The real time application is started
43 matches
Mail list logo
