Re: [systemd-devel] [PATCH] firmware: wake all waiters

[Luis R. Rodriguez]

On Tue, Jun 27, 2017 at 02:25:53PM -0700, Jakub Kicinski wrote:
> On Tue, 27 Jun 2017 18:39:42 +0200, Luis R. Rodriguez wrote:
> > 
> > > The problem is that advanced NICs are quite programmable [1] and
> > > depending on use case one may want to load different firmware files.  
> > 
> > Right, so in the 802.11 world some devices might use different firmware for
> > different modes of operation, STA, AP, Mesh, but this is all very protocol
> > specific, so userspace could tickle the kernel about a mode.
> > 
> > Do your use cases have protocol definitions which can be exposed in 
> > userspace?
> > Or are these just fw variants with different bells and whistles? How man
> > different use cases are we talking about?
> 
> Right now we have three modes that come from Netronome itself, a "basic
> NIC" one, and two advanced for TC flower/Open vSwitch acceleration and
> for eBPF offload.  I was hoping some enumeration scheme could work here,
> but I really can't come up with one.

How about just supporting 3 firmware names, with the first two being optional,
but if found one of those two is found it would use that one. Then only if
both of these are not present would a default be looked for and used?

In terms of interface, a simple symlink / renaming scheme would suffice to
support this. No custom hooks at all.

> To be honest waiting for rootfs to be available is lower on my list of
> priorities, but it's definitely nice to have.  I also don't care about
> supporting more complex rootfs setups, simply trying whatever comes
> after initramfs covers 99.9% use cases.  0.1% can load the FW manually/
> rebind the driver IMHO.

Right, the only issue with firmwared is you'd expect folks would have
it deployed, and that's not the case today, but when you do control the
ecosystem you can certainly use it as an option. Let me know if you
do try it out.

> > Be careful how you do this as you'll have to support it in the driver 
> > forever
> > if you use something like sysfs I think, otherwise you will break some
> > userspace. However if you use debugfs I think its understood that's loose 
> > API.
> 
> Unfortunately the netdev community does not like debugfs.  I would
> prefer to extend the firmware subsystem if possible and use the
> existing sysfs interface, just in a new "mode".

I don't think this is required, you can simply use different filenames as
noted above.

> > > Current firmware subsystem doesn't seem to cater to this use case to
> > > well.  
> > 
> > Its a matter of asking and talking. I've provided references of things to
> > try to address the hacky -EPROBE_DEFER. It does however require a userspace
> > daemon used, so it does require use of the uevent fallback mechanism.
> 
> Do you know how systemd developers feel about the issue (CCed)?  Given
> that it seems to dominate in data center OSes now I'm slightly worried
> having to push Big Linux Vendors to package some seemingly
> embedded-centric software just to make advanced NICs run :(

firmwared was written by a systemd developer :)

I think it was first packaged into systemd, and then it was split out to
help those who want it external.

> > >  - how to make sure different cards, which request the same file name
> > >can be served different default firmwares...  
> > 
> > I believe your patch + the error path fix will handle this now, no?
> 
> I'm not sure.  I think it would work if I set FW_OPT_NOCACHE, though.
> I need to test that.

Why do you need FW_OPT_NOCACHE?

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

Re: [systemd-devel] ntpd stop job delays reboot up to 90s

[Lennart Poettering]

On Tue, 27.06.17 05:11, Felix Miata (mrma...@earthlink.net) wrote:

> Full message waiting to reboot:
> A stop job is running for NTP server Daemon (1min nns / 1min 30s).
> 
> This occurs on various installations here at various times, whether rebooting 
> or
> shutting down, most never, others routinely, yet not every time, or not a full
> 90s delay. Just tonight it's been happening on openSUSE 42.3beta with
> systemd-228. How is it that a shutdown delay like this can occur when there 
> was
> no problem with the startup?

Well, that's something you should really ping your distro's ntpd
maintainers about. if a daemon doesn't want to exit then that sounds
like a bug in the daemon.

Lennart

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

Re: [systemd-devel] Does systemd-stdio-bridge handle dbus UNIX_FD passing somehow?

[Lennart Poettering]

On Tue, 27.06.17 10:26, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> Hello,
> 
> I would like to make a method call on a remote machine with busctl
> where the method returns UNIX_FD (h), type unix domain socket.
> 
> I am guessing the FD stops on stdio-bridge without any other magic
> bridging the UDS to an another socket on the host. Is that the case?
> Can there be any magic to accomplish this?

Nope, this is not available and cannot be made available. passing fds
is a local concept, and does not apply to remote transfers. If you try
you should get a clean error back that the transport does not support
this concept.

Lennart

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

[systemd-devel] ntpd stop job delays reboot up to 90s

[Felix Miata]

Full message waiting to reboot:
A stop job is running for NTP server Daemon (1min nns / 1min 30s).

This occurs on various installations here at various times, whether rebooting or
shutting down, most never, others routinely, yet not every time, or not a full
90s delay. Just tonight it's been happening on openSUSE 42.3beta with
systemd-228. How is it that a shutdown delay like this can occur when there was
no problem with the startup?

# journalctl -b -1 | grep ntp
Failed to look up boot -1: No such boot ID in journal
# journalctl -b | grep ntp
Jun 27 04:50:53 hpg33 kernel: Mountpoint-cache hash table entries: 4096 (order:
3, 32768 bytes)
Jun 27 04:51:22 hpg33 ntpd[1177]: ntpd 4.2.8p10@1.3728-o Tue Jun 13 18:04:39 UTC
2017 (1): Starting
Jun 27 04:51:22 hpg33 ntpd[1177]: Command line: /usr/sbin/ntpd -p
/var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf
Jun 27 04:51:22 hpg33 ntpd[1181]: proto: precision = 0.060 usec (-24)
Jun 27 04:51:22 hpg33 ntpd[1181]: switching logging to file /var/log/ntp
Jun 27 04:51:22 hpg33 start-ntpd[1166]: Starting network time protocol daemon 
(NTPD)
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Does systemd-stdio-bridge handle dbus UNIX_FD passing somehow?

[Mantas Mikulėnas]

Afaik, the stdio bridge only supports a single dbus protocol stream and
nothing else.

Trying to pass file descriptors over the network might need magic in the
literal sense – just imagine emulating all the ioctls, socket operations,
etc. that a program may want to perform.

(I seem to remember a similar thread very recently on the dbus mailing
list?)

On Tue, Jun 27, 2017, 11:26 Umut Tezduyar Lindskog 
wrote:

> Hello,
>
> I would like to make a method call on a remote machine with busctl
> where the method returns UNIX_FD (h), type unix domain socket.
>
> I am guessing the FD stops on stdio-bridge without any other magic
> bridging the UDS to an another socket on the host. Is that the case?
> Can there be any magic to accomplish this?
>
> UMUT
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

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

[systemd-devel] Does systemd-stdio-bridge handle dbus UNIX_FD passing somehow?

[Umut Tezduyar Lindskog]

Hello,

I would like to make a method call on a remote machine with busctl
where the method returns UNIX_FD (h), type unix domain socket.

I am guessing the FD stops on stdio-bridge without any other magic
bridging the UDS to an another socket on the host. Is that the case?
Can there be any magic to accomplish this?

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

Re: [systemd-devel] Returning arrays from sd-bus methods

[Lennart Poettering]

On Mon, 26.06.17 12:19, guhan balasubramanian (guhan@gmail.com) wrote:

> > if you use sd_bus_reply_method_return() (or sd_bus_append()) the
> > arguments to pass for an array is the array's size followed by the
> > members. Hence, the following should do what you want:
> >
> > sd_bus_reply_method_return(m, "ay", 2, 0x01, 0x02);
> >
> 
> This worked for me. But I had the following three questions based on this:
> 
> 1. Would it be a good design to construct a va_list of the array elements
> and pass it as the last argument in sd_bus_reply_method_return?

C doesn't support that in a portable way. But there's really no need
to, if you want to add complex data structures to a bus message, you
can do so easily, by allocating a reply bus message object, and then
adding elements piecemeal. sd_bus_reply_method_return() is really just
a convencience wrapper around sd_bus_message_new_method_return(),
sd_bus_message_append(), sd_bus_send(), and you can invoke those
directly too.

If you want to add set of array entries, you need to invoke
sd_bus_message_open_container(), followed by repeated
sd_bus_message_append(), one for each entry, and then a final
sd_bus_message_close_container(). How to do this precisely is
unfortunately a bit underdocument, but you find tons of examples if
you grep through the systemd codebase.

> 2. I wasn't able to find the definition for sd_bus_append, I think you
> meant *sd_bus_message_append*() right?

Yes, sorry.

> 3. Is there an API to pass the entire container (array in this case) for a
>  method return?

See above. There are also a couple of other helpers, including
sd_bus_message_append_array(), which does the _open_container() +
_append() loop and _close_container() in one go for you.

Lennart

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

Re: [systemd-devel] systemctl can't execute stop actually, when service is started by other way

[Lennart Poettering]

On Tue, 27.06.17 13:48, 清辰 (624001...@qq.com) wrote:

> for example: service nscd
> 1.execute: systemctl stop nscd.service
>   stop nscd process actually
> 2.execute: /usr/bin/nscd
>   start nscd by shell command
> 3.execute: systemctl status nscd.service
>   inactive(dead)
>   systemctl can't know nscd is running
> 4.excute: systemctl stop nscd.service
>   nscd process still exist, it seems that systemctl does not execute stop 
> actually
> 
> 
> How can I stop nscd.service by systemctl when it is started not by
> systemctl?

You cannot. systemd is a service manager. When you tell it to manage
something that means it will start/stop/introspect/... it for you. But
if you manage the service on your own, outside of it, then it won't do
any of that.

Hence: either let systemd the service and then also stop it for you,
or do it yourself, but you cannot let it stop it for you but not start
it in the first place.

Sorry,

Lennart

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