Re: [systemd-devel] ruby bindings

2016-10-04 Thread Nathan Williams 
yes, i think it would be great to have a single library supporting all the
systemd features, and perhaps at some point i can donate the dbus-systemd
code to such a project (not that there's much to it, just a thin
systemd-specific layer on top of the great ruby-dbus work), but so far as
i'm aware, there's not a lot out there right now. at present the
systemd-journal gem is the best thing going for journald, and dbus support
is clearly out of scope. as i understand (from a brief comment in one of
the conf videos i saw), there's currently deadlocking concerns preventing a
journald dbus interface (?), but if one's ever implemented, i'd be happy to
add support for it to dbus-systemd.

in general, i'm not aware of many system services being written in ruby
(unless you count rack & friends), so perhaps there's just no real call for
it. journald obviously has broad appeal for application developers, and an
ecosystem of log aggregation tooling driving adoption with ops folks, but
up to now i think the dbus APIs have been under-utilized. my intention with
the dbus-systemd gem is to fill that need; selfishly, so i can scratch my
own itch to stop using shellout in the systemd Chef cookbook when there's
an API available to do what i want without all the contortions :). for the
cfg mgmt use case, i think something that just handles dbus interfaces is
right on target, and installing systemd-journal if i need it is no big deal.

cheers,

nathan

p.s. Pantheon's comments re: daemon-reload performance (great talks btw)
are also a big motivation for this; the systemd-cookbook is hopefully
headed toward needing far fewer reloads if we can swap in calls to
SetProperties instead.

On Tue, Oct 4, 2016 at 7:30 PM David Timothy Strauss 
wrote:

> For what it's worth, I try to encourage projects to identify their
> bindings as simply for systemd, even if the journal support is the first
> (and only) set of APIs available. It's just so easy to support the other
> APIs once the journal is already supported, and daemons that want to use
> the journal should consider using the notify API as well for
> startup/shutdown status -- and other APIs offered for daemons by systemd.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-222 mount issues on CentOS 7

2016-10-04 Thread Lokesh Mandvekar 
On Tue, Oct 04, 2016 at 10:28:25AM +0200, Michal Sekletar wrote:
> On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar
>  wrote:
> > Now, I can mount these partitions with:
> >
> > # lvm vgchange -ay
> >
> > but this still doesn't automount succesfully on a reboot.
> >
> > Did I miss something here?
> 
> I'd check from emergency shell whether lvm2-pvscan@.service was run.
> This instantiated systemd service is responsible for scaning LVM PVs
> and auto-activating LVs on them. Note that it is spawned from udev
> rules in case when certain conditions are met, e.g. block device is
> identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0
> property set.

Michal, thanks for the reply.

What's the correct way to check if lvm2-pvscan@.service was run?

I tried:

# systemctl status lvm2-pvscan@.service
Failed to get properties: Unit name lvm2-pvscan@.service is not valid.

> 
> Also, there has been couple of bugfixes since systemd-222 that are
> maybe related. We backported them to RHEL/CentOS 7 (systemd-219).

Could you please link me to these patches if that's doable?
I see the rpm source contains tons of patches.

Thanks,
-- 
Lokesh
Freenode: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help with boot time debugging

2016-10-04 Thread Andrei Borzenkov 
04.10.2016 23:55, Manuel Amador (Rudd-O) пишет:
> Hello folks!
> 
> I'm developing a Dracut module and I need to know how to go about
> showing what processes run by systemd during boot are saying.  This is
> for https://github.com/Rudd-O/zfs-fedora-installer .
> 
> For example, I have this one that happens during boot:
> 
> "Starting dracut cmdline hook"
> 
> I want to show on the console what the cmdline hook might have spat to
> standard output.  I  want every single process that produces
> stdout/stderr/logging output to show me that output on the console.
> 
> The boot time option systemd.journald.forward_to_console simply did not
> work (my console is a ttyS0).
> 
> What gives?
> 

Are you sure there is any output in the first place? Is anything in
journal that is not present on console?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] ruby bindings

2016-10-04 Thread David Timothy Strauss 
For what it's worth, I try to encourage projects to identify their bindings
as simply for systemd, even if the journal support is the first (and only)
set of APIs available. It's just so easy to support the other APIs once the
journal is already supported, and daemons that want to use the journal
should consider using the notify API as well for startup/shutdown status --
and other APIs offered for daemons by systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Help with boot time debugging

2016-10-04 Thread Manuel Amador (Rudd-O) 
Hello folks!

I'm developing a Dracut module and I need to know how to go about
showing what processes run by systemd during boot are saying.  This is
for https://github.com/Rudd-O/zfs-fedora-installer .

For example, I have this one that happens during boot:

"Starting dracut cmdline hook"

I want to show on the console what the cmdline hook might have spat to
standard output.  I  want every single process that produces
stdout/stderr/logging output to show me that output on the console.

The boot time option systemd.journald.forward_to_console simply did not
work (my console is a ttyS0).

What gives?

Thanks in advance.

-- 
Rudd-O
http://rudd-o.com/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] tomcat start up script wait for message

2016-10-04 Thread Tomasz Torcz 
On Tue, Oct 04, 2016 at 08:57:09PM +0300, Mantas Mikulėnas wrote:
> On Tue, Oct 4, 2016 at 8:32 PM, Tyler Couto  wrote:
> 
> > Hi all,
> >
> > We have a tomcat application that requires some initialization after
> > tomcat starts up. That is, we run an initialize script after catalina.out
> > says ?'Server startup in:'. Currently we do this in a number of ways:
> > manually, through a custom tail script, or through logstash. But I¹m
> > thinking it might be best to let the init system do it. Is this a good
> > idea? And if so, how best to implement it?
> >
> 
> systemd will not react to stdout messages, but it does have Type=notify
> which will react to a "READY=1" message sent via Unix socket – ideally
> directly by the program (see sd_notify, $NOTIFY_SOCKET) but also possibly
> via the `systemd-notify` tool:
> 
> sd_notify(0, "READY=1");
> 
> systemd-notify --ready
> 


  In other words, Tyler, you have to:

1) implement above sd_notify support int Tomcat, for which many users
   would be thankful;

2) use some waiting mechanism; I know that Spacewalk project has some
   Tomcat-waiting implemented, you can check their units.

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] tomcat start up script wait for message

2016-10-04 Thread Mantas Mikulėnas 
On Tue, Oct 4, 2016 at 8:32 PM, Tyler Couto  wrote:

> Hi all,
>
> We have a tomcat application that requires some initialization after
> tomcat starts up. That is, we run an initialize script after catalina.out
> says ?'Server startup in:'. Currently we do this in a number of ways:
> manually, through a custom tail script, or through logstash. But I¹m
> thinking it might be best to let the init system do it. Is this a good
> idea? And if so, how best to implement it?
>

systemd will not react to stdout messages, but it does have Type=notify
which will react to a "READY=1" message sent via Unix socket – ideally
directly by the program (see sd_notify, $NOTIFY_SOCKET) but also possibly
via the `systemd-notify` tool:

sd_notify(0, "READY=1");

systemd-notify --ready

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] tomcat start up script wait for message

2016-10-04 Thread Tyler Couto 
Hi all,

We have a tomcat application that requires some initialization after
tomcat starts up. That is, we run an initialize script after catalina.out
says ?'Server startup in:'. Currently we do this in a number of ways:
manually, through a custom tail script, or through logstash. But I¹m
thinking it might be best to let the init system do it. Is this a good
idea? And if so, how best to implement it?

Thanks!
Tyler

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] ruby bindings

2016-10-04 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Oct 04, 2016 at 02:48:07PM +, Nathan Williams wrote:
> Hello Zbyszek,
> 
> Thanks for your reply :)
> 
> From looking at the systemd-journal gem, I'd say they're complementary:
> systemd-journal is entirely about interacting with the journal, and
> dbus-systemd is focused squarely on systemd dbus APIs (hostnamed,
> timedated, systemd manager/unit, etc). i think for either gem to start
> adding code related to the other's primary purpose would be out of scope.

OK. I now added a link under the phrase "Ruby bindings for the systemd
D-Bus APIs".

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] architecture: Add support for the RISC-V architecture.

2016-10-04 Thread Richard W.M. Jones 
On Tue, Oct 04, 2016 at 03:36:48PM +0200, Lennart Poettering wrote:
> I created a github PR from this:
> 
> https://github.com/systemd/systemd/pull/4282
> 
> Would be good to follow up discussion there.

Thanks for the feedback Lennart.  Just FYI we are still building and
testing this package.  It's very painful and slow to compile, so
everything takes 10x longer than normal.  I'll follow up at the link
above when we have verified that it all or at least mostly works.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] architecture: Add support for the RISC-V architecture.

2016-10-04 Thread Lennart Poettering 
On Fri, 30.09.16 16:45, Richard W.M. Jones (rjo...@redhat.com) wrote:

> [This is only compile-tested, as our kernel doesn't (yet) have
> enough configured features to run systemd, but I'll report back
> when I get it running.]
> 
> RISC-V is an open source ISA in development since 2010 at UCB.
> For more information, see https://riscv.org/
> 
> I am adding RISC-V support to Fedora:
> https://fedoraproject.org/wiki/Architectures/RISC-V
> 
> There are three major variants of the architecture (32-, 64- and
> 128-bit).  The 128-bit variant is a paper exercise, but the other two
> really exist in silicon.  RISC-V is always little endian.
> 
> On Linux, the default kernel uname(2) can return "riscv" for all
> variants.  However a patch was added recently which makes the kernel
> return one of "riscv32" or "riscv64" (or in future "riscv128").  So
> systemd should be prepared to handle any of "riscv", "riscv32",
> "riscv64" or "riscv128".  If the kernel returns "riscv" then you
> need to use the pointer size in order to know the real variant.
> 
> The Fedora/RISC-V kernel only ever returns "riscv64" since we're only
> doing Fedora for 64 bit at the moment, and we've patched the kernel so
> it doesn't return "riscv".
> 
> As well as the major bitsize variants, there are also architecture
> extensions.  However I'm trying to ensure that uname(2) does *not*
> return any other information about those in utsname.machine, so that
> we don't end up with "riscv64abcde" nonsense.  Instead those
> extensions will be exposed in /proc/cpuinfo similar to how flags work
> in x86.
> 
> I should also note that __SIZEOF_POINTER__ is a GCC extension, but it
> appears to be used already in systemd so I guess that's OK.

Any chance you can move this cover letter (or at least most of it into
the commit itself? I think it would be great to have all of this in
the commit).

Also, if riscv128 is a paper excercise for now, then I'd prefer if
this was left out of the current patch for now.

I created a github PR from this:

https://github.com/systemd/systemd/pull/4282

Would be good to follow up discussion there.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] ruby bindings

2016-10-04 Thread Zbigniew Jędrzejewski-Szmek 
You asked on irc about adding https://github.com/nathwill/ruby-dbus-systemd
to the wiki. We can do that, but I'd like to clarify first the relationship
to https://github.com/ledbettj/systemd-journal. Is it a replacement,
complement, etc? What is the development status of your package: stable,
experimental, etc?

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-222 mount issues on CentOS 7

2016-10-04 Thread Michal Sekletar 
On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar
 wrote:
> Now, I can mount these partitions with:
>
> # lvm vgchange -ay
>
> but this still doesn't automount succesfully on a reboot.
>
> Did I miss something here?

I'd check from emergency shell whether lvm2-pvscan@.service was run.
This instantiated systemd service is responsible for scaning LVM PVs
and auto-activating LVs on them. Note that it is spawned from udev
rules in case when certain conditions are met, e.g. block device is
identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0
property set.

Also, there has been couple of bugfixes since systemd-222 that are
maybe related. We backported them to RHEL/CentOS 7 (systemd-219).

Michal
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel