Re: [systemd-devel] I have lots of sockets tied to pid 1 (systemd) in CLOSE-WAIT, anyway to get rid of these?

[Christopher Cox]

On 06/19/2018 05:21 PM, Christopher Cox wrote:
Not sure what happened, but on one of our CentOS 7 host we had like 64 
socket connects owned by pid 1 (systemd) in CLOSE-WAIT state.  And 
systemctl -a shows a bunch of lines like:


check_mk@11305-10.32.50.31:6556-10.32.3.10:55106.service  (corresponding 
to the 64 CLOSE-WAIT connections)


Ultimately this is being caused by a failure on running "df", like one 
of those "stale mount" like conditions (though our one NFS mount seems 
fine, but somebody else may have done something).


I've scheduled the host for a reboot, but still, I believe that more 
"bad things" happen (e.g. too many connections) as a result of something 
like this than what would have happened prior to systemd.  But you can 
tell me...


Nothing in /etc/mtab leaps out at me as something to solve with regards 
to a stale mount.

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

Re: [systemd-devel] Authenticating "sd bus" fails with Invalid argument

[Simon McVittie]

On Tue, 19 Jun 2018 at 12:32:19 +, mag...@minimum.se wrote:
> The system is on a quite old kernel (3.18.44)
...
> At this point, things go wrong when
> recvmsg() is called on bus->input_fd with flags MSG_DONTWAIT|MSG_NOSIGNAL|
> MSG_CMSG_CLOEXEC. This syscall returns -22 (Invalid argument) which propagates
> all the way up to the user.

(I hate the way kernel/syscall/libc error-reporting isn't accompanied
by a human-readable message that could tell you *which* argument is
invalid... compare with GLib/D-Bus errors)

MSG_NOSIGNAL is meaningless for recvmsg()
 so it's possible
that your older kernel doesn't allow it, but newer kernels allow and
ignore it? sd-bus should probably only use that flag for sendmsg()
and the rest of the send(2) family.

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

[systemd-devel] Authenticating "sd bus" fails with Invalid argument

[magnus]

Hi,
I'm trying to migrate a sys V-based system to systemd. At the moment, I'm using 
systemd 232. The system is on a quite old kernel (3.18.44), but I have enabled 
the kernel configs listed in the systemd README. Things are mostly working 
except systemd-logind.service fails to start. When I check systemctl status 
systemd-logind.service, it says:
Failed to get properties: Invalid argument
In addition, once I start playing around with systemd commands from the shell, 
I see similar errors ("Invalid argument"). For example, running busctl (or 
busctl --list) gives:
Failed to list names: Invalid argument
I've enabled systemd debug by putting systemd.log_level=debug on the kernel 
cmdline. If I review the bootlog, journalctl -b, I notice the following 
additional errors:
* systemd-gpt-auto-generator fails with out of memory errors. I found a bug in 
the systemd issue tracker (https://bugs.freedesktop.org/show_bug.cgi?id=76058 
(https://bugs.freedesktop.org/show_bug.cgi?id=76058)), and its fix is included 
in my build. Still getting the OOM. My device is NAND based with UBIFS, so it 
does not even use GPT. I don't know if this is relevant to my "main" issue.
* dbus seem to start OK but systemd emits a few errors just after:

[  OK  ] Started D-Bus System Message Bus.
[6.115125] systemd[1]: Failed to subscribe to NameOwnerChanged signal for 
'org.freedesktop.login1': Invalid argument
[6.160342] systemd[1]: Failed to register name: Invalid argument
[6.170734] systemd[1]: Failed to set up API bus: Invalid argument
* My dbus seem to be OK. busctl --list fails but I can do it manually using 
dbus-send:
root@chihuahua:~# dbus-send --system
>   --dest=org.freedesktop.DBus 
>   --type=method_call  
>   --print-reply   
>   /org/freedesktop/DBus   
>   org.freedesktop.DBus.ListNames
method return time=1529311428.695165 sender=org.freedesktop.DBus -> 
destination=:1.0 serial=3 reply_serial=2
   array [
  string "org.freedesktop.DBus"
  string ":1.0"
   ]
When I dive deeper into the systemd source code, I find that the issue is that 
my "sd bus" is not in running state when it should be. Here's a trace of whats 
going on when I call busctl --list:
1) sd_bus_list_names()
2) bus_list_names_dbus1()
3) sd_bus_call_method()
4) sd_bus_call()
sd_bus_call() fails because my bus is not in running state. 
bus_ensure_running() tries to put my bus into running state by the following 
sequence:
1) sd_bus_process()
2) bus_process_internal()
.. where it detects that my bus is in "authenticating" state and tries to 
authenticate by bus_socket_write_auth() (which is successfull) and then read 
the auth using bus_socket_read_auth(). At this point, things go wrong when 
recvmsg() is called on bus->input_fd with flags 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC. This syscall returns -22 (Invalid 
argument) which propagates all the way up to the user.
Any ideas why I'm getting Invalid argument error here? This error is reoccuring 
all over systemd where when it tries to authenticate on the bus and put it into 
running state. 
Any ideas on what might be wrong? Since this system never ran systemd before, I 
suspect it could be missing libs and/or additional kernel configs. My limited 
knowledge in systemd internals make this very difficult to debug.
Thanks in advance, Magnus.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a service *just* before unmounting filesystems

[Hans de Goede]

Hi,

On 13-06-18 17:05, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jun 13, 2018 at 04:55:27PM +0200, Hans de Goede wrote:

Hi,

On 12-06-18 19:11, Lennart Poettering wrote:

On Di, 12.06.18 11:33, Hans de Goede (hdego...@redhat.com) wrote:

AFAIK the service actually doing the updates is supposed to call
systemctl reboot --force when it is done, so any targets after
system-update.target won't get started ?


True, the service in question could split the reboot call of course,
if it wanted, so that you can plug things in between.


Since in this case we want to increment a boot_indeterminate counter
to indicate the last boot was not a normal boot, so no clear
success status is available I'm fine with the service doing the
increment before the updates run.

So I was thinking about adding a system-update-pre.target
and then in system-update.target add:

Wants=system-update-pre.target
After=system-update-pre.target

Yep, that sounds reasonable.


Ok, so as you've already seen I've just send a pull-req with
this change:

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

Given that we're going to need system-update-pre.target for Fedora 29:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

It would be great if this could still make the upcoming 239
release. But I guess it is too late for that?

Assuming this is too late, I would like to request to carry
this as a downstream patch in the Fedora pkgs for now.

Regards,

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