[systemd-devel] Antw: Re: Antw: sd_journal_send non-blocking call
>>> Lennart Poettering schrieb am 23.07.2019 um 17:43
in
Nachricht <20190723154358.GA9178@gardel-login>:
> On Do, 18.07.19 11:06, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
>> On Thu, Jul 18, 2019 at 10:32 AM Ulrich Windl <
>> ulrich.wi...@rz.uni-regensburg.de> wrote:
>>
>> > >>> Vaibhav Dahiya schrieb am 18.07.2019 um 02:53 in
>> > Nachricht
>> > <5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>:
>> > > Hello,
>> > >
>> > > I am using sd_journal_send api() api call to log messages on syslog
>> > server.
>> > > I see that this uses
>> > > sendmsg(fd, &mh, MSG_NOSIGNAL) call.
>> >
>> > Aren't syslog messages UDP anyway? When would an UDP send block?
>> >
>>
>> No, program APIs use Unix sockets (/dev/log, /run/systemd/journal/socket).
>> You only get UDP when your local syslog daemon is configured to forward
>> elsewhere.
>>
>> That said, both are datagram sockets, I'm not sure whether sending to Unix
>> dgram sockets can block or not?
>
> Local AF_UNIX/SOCK_DGRAM sockets may block and are reliable.
Out of curiosity, what would be the condition for the datagram socket to block
when it's being written to? Is it due to being "reliable" that all received
packets have to be buffered? ("man 7 unix" does not contain the phrase "block"
here)
>
> Lennart
>
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Portable services hub?
Random side note, I've always felt like it would be neat if there were some system for updating portable services, maybe built on Flatpak or vanilla ostree or OCI containers / podman... On Tue, Jul 23, 2019, 11:00 AM Lennart Poettering wrote: > On Mo, 15.07.19 22:45, Thomas Meyer (tho...@m3y3r.de) wrote: > > > Hi, > > > > Is there an directory/list of available portable services? > > I am not aware of any. Would be excelent though if someone would set > something like that up! > > Lennart > > -- > Lennart Poettering, Berlin > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald deleting logs on LiveOS boots
On Sun, Jul 21, 2019 at 11:48 PM Ulrich Windl wrote: > > >>> Chris Murphy schrieb am 18.07.2019 um 17:55 in > Nachricht > : > > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala wrote: > >> > >> On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote: > >> > So far nothing I've tried gets me access to information that would > >> > give a hint why systemd-journald thinks there's no free space and yet > >> > it still decides to create a single 8MB system journal, which then > >> > almost immediately gets deleted, including all the evidence up to that > >> > point. > >> > >> Run journald under strace and check the results of the system calls > >> used to query space? (One way to run it under strace would be to change > >> the unit file to use "strace -D -o /run/output systemd-journald" as the > >> process to start.) > > > > It's a good idea but strace isn't available on Fedora live media. So I > > either have to learn how to create a custom live media locally (it's a > > really complicated process) or convince Fedora to add strace to live > > media... > > Wouldn't it be easer to scp the binary from a compatible system? What binary? The problem with the strace idea is that /run/output is 0 length. There's nothing to scp. For whatever reason strace creates /run/output but isn't writing anything to it. But based on this PR it looks like some aspect of this problem is understood by systemd developers. https://github.com/systemd/systemd/pull/13120 -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald deleting logs on LiveOS boots
On Fri, Jul 19, 2019 at 8:45 AM Uoti Urpala wrote: > > On Thu, 2019-07-18 at 21:52 -0600, Chris Murphy wrote: > > # df -h > > ... > > /dev/mapper/live-rw 6.4G 5.7G 648M 91% / > > > > And in the log: > > 47,19636,16754831,-;systemd-journald[905]: Fixed min_use=1.0M > > max_use=648.7M max_size=81.0M min_size=512.0K keep_free=973.1M > > n_max_files=100 > > > > Why is keep_free bigger than available free space? Is that the cause > > of the vacuuming? > > The default value for keep_free is the smaller of 4 GiB or 15% of total > filesystem size. Since the filesystem is small and has less than 15% > free, it's already over the default limit. Those defaults are defined > in src/journal/journal_file.c. When over the limit, journald still uses > at least DEFAULT_MIN_USE (increased to the initial size of journals on > disk if any). But it looks suspicious that this is 1 MiB while > FILE_SIZE_INCREASE is 8 MiB - doesn't this imply that any use at all > immediately goes over 1 MiB? > > You can probably work around the issue by setting a smaller > SystemKeepFree in journald.conf. I don't really need a work around, this is live media and that file will be read only. What I need is to understand exactly why the journal vacuuming is being triggered. Either that's simply not being recorded in the journal in the first place, and must be inferred by esoteric knowledge, or the reason is in the journal that has been vacuum, and is thus lost. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Verify only single file
On Mo, 01.07.19 16:00, Dennis Ljungmark (spi...@modio.se) wrote: > Hi, > on my current Fedora (30) system, I'm trying to hook a test to > validate systemd unit files via `systemd-analyze verify` > > this however has a problem that it analyzes & verifies the entire > chain, reporting errors if _any_ of the system units has an error. > > Is there a way to limit `verify` to only run on the targetted units, > while maintaining the dependency tracking (units should exist) but > not causing errors just because one of the system active units has a > PIDFile set in /var/run, or similar. This does not exist currently. Consider filing an RFE github issue about this, and we might look into it. Even better file a PR implementing this. Sorry, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem in understanding container permissions
On Mi, 03.07.19 12:24, Kai Bojens (k...@kbojens.de) wrote: > Ubuntu 18.04, HWE kernel 4.18.0-25-generic, systemd 237-3ubuntu10.23 > > I have created a nspawn container with a minimal Ubuntu and booted the > container > without any problems. There were no problems and I used the default settings. > Now I see some strange permission errors which I can't explain: > > Inside the container: > > root@container:/var/log# ls -alt > total 356 > -rw-r--r-- 1 root root203203 Jul 3 09:17 dpkg.log > drwxr-xr-x 1 root root60 Jul 3 09:17 apt > -rw-r--r-- 1 root root 9046 Jul 2 15:04 alternatives.log > -rw--- 1 root root 6784 Jul 2 15:04 tallylog > -rw-r--r-- 1 root root 3392 Jul 2 15:04 faillog > -rw-r- 1 nobody nogroup 40658 Jul 2 10:14 syslog > -rw-rw-r-- 1 nobody nogroup 16128 Jul 2 10:14 wtmp > -rw-r- 1 nobody nogroup 6234 Jul 2 10:14 auth.log > -rw-rw-r-- 1 nobody nogroup 30660 Jul 2 10:06 lastlog > -rw-rw 1 nobody nogroup384 Jul 1 14:02 btmp > drwxrwxr-x 1 nobody nogroup182 Jul 1 14:02 . > drwxr-sr-x+ 1 nobody nogroup 64 Jul 1 14:02 journal > -rw-r--r-- 1 root root 60952 Jul 1 13:59 bootstrap.log > drwxr-xr-x 1 root root90 Jul 1 13:56 .. > root@container:/var/log# whoami > root > root@container:/var/log# tail syslog > tail: cannot open 'syslog' for reading: Permission denied > > > Outside the container: > > root@container:/var/lib/machines/xy-test/var/log# ls -alt > total 356 > -rw-r--r-- 1 198180864 198180864 203203 Jul 3 09:17 dpkg.log > drwxr-xr-x 1 198180864 198180864 60 Jul 3 09:17 apt > -rw-r--r-- 1 198180864 198180864 9046 Jul 2 15:04 alternatives.log > -rw--- 1 198180864 198180864 6784 Jul 2 15:04 tallylog > -rw-r--r-- 1 198180864 198180864 3392 Jul 2 15:04 faillog > -rw-r- 1 syslogadm 40658 Jul 2 10:14 syslog > -rw-rw-r-- 1 root utmp 16128 Jul 2 10:14 wtmp > -rw-r- 1 syslogadm 6234 Jul 2 10:14 auth.log > -rw-rw-r-- 1 root utmp 30660 Jul 2 10:06 lastlog > -rw-rw 1 root utmp 384 Jul 1 14:02 btmp > drwxrwxr-x 1 root syslog 182 Jul 1 14:02 . > drwxr-sr-x+ 1 root systemd-journal 64 Jul 1 14:02 journal > -rw-r--r-- 1 198180864 198180864 60952 Jul 1 13:59 bootstrap.log > drwxr-xr-x 1 198180864 198180864 90 Jul 1 13:56 .. > > I have not touched any of these files from outside of the container. Is there > anything obvious I have failed to see? Why would the ownership of these file > change? This is caused by user namespacing, i.e. the -U option of systemd-nspawn (which is default in systemd-nspawn@.service, but not in systemd-nspawn when invoked directly). it means the container runs under its own UID range that is somewhere above the 65536 boundary when looking from the outside of the container, but looks like the normal 0…65536 inside of it. Except that some system files are always owned by the special nobody user, because they are system files. It appears you ran your container once with and once without user namespacing. You can fix that without loss, see documentation: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-U Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Portable services hub?
On Mo, 15.07.19 22:45, Thomas Meyer (tho...@m3y3r.de) wrote: > Hi, > > Is there an directory/list of available portable services? I am not aware of any. Would be excelent though if someone would set something like that up! Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] device enumeration by systemd user instances
On Mi, 17.07.19 17:46, Pawel Szewczyk (p.szewc...@samsung.com) wrote: > Dear all > > I was recently working on reducing booting time and I see one issue that > I think is worth discussing. > > The problem is the device units enumeration seems to take a long time > (>100ms in our case) before any units are beginning to start. I think > there is some potential for improvement there. Do you have some profiler results about this? i.e. what exactly is the time spent on? Note that systemd generally uses udev "tags" for filtering, which means we should only processes that are actually supposed to show up as .device units, and nothing else. Before optimizing this, pleas find out though what the time is actually spent on. > I see that on the system I use for testing the user instance of > systemd is doing an enumeration of devices as well. Since no matter > if the systemd is pid 1 or user instance, it loads the same set of > units which are tagged 'systemd' in udev, if I understand > correctly. In user session, however, no unit seems to depend on > device units, so the whole effort of creating them is for > nothing. My guess is that for many use cases the device units are > not needed by session services. Hmm, so some people appear to use this, since we recently fixed a bug in this area that people noticed while making us of this... > So here is the question: is this a safe thing to do? I wonder if trying > to start units without having device units created would break something > in systemd. Well, the work needs to be done anyway, so what do you gain if you do it a bit later? What specifically do you try to optimize? latency until the first process is started by systemd --user? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_journal_send non-blocking call
On Mi, 17.07.19 17:53, Vaibhav Dahiya (vdah...@ncsu.edu) wrote: > Hello, > > I am using sd_journal_send api() api call to log messages on syslog server. I > see that this uses > sendmsg(fd, &mh, MSG_NOSIGNAL) call. > Is there a provision of passing MSG_DONTWAIT flag to this. > or else have a separate api like sd_journal_send_non_blocking(). > I want to use this call in an application where I cant make a blocking call > for logging. So the calls are blocking, but the socket buffers in use should be very large, so IRL it takes a while to make things block. Making them non-blocking is currently not supported. If this is useful to you we'd be happy to review and merge a patch adding that. Doing non-blocking sockets means dropping messages though, which we#d have to count client side and eventually mention when we can log again. i.e. it's not done to se MSG_DONTWAIT/O_NONBLOCK on the socket, we'd also have to account for dropped msgs and synthesize implicit messages. (I figure it would probably make sense to support controlling SO_SNDTIMEO on the socket btw, which would allow us to take a time we'd like to block for at most, and then treat the current synchronous behaviour and the requested MSG_DONTWAIT behaviour just as two special cases of that where the time is 0 or infinity...) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: sd_journal_send non-blocking call
On Do, 18.07.19 11:06, Mantas Mikulėnas (graw...@gmail.com) wrote: > On Thu, Jul 18, 2019 at 10:32 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > > > >>> Vaibhav Dahiya schrieb am 18.07.2019 um 02:53 in > > Nachricht > > <5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>: > > > Hello, > > > > > > I am using sd_journal_send api() api call to log messages on syslog > > server. > > > I see that this uses > > > sendmsg(fd, &mh, MSG_NOSIGNAL) call. > > > > Aren't syslog messages UDP anyway? When would an UDP send block? > > > > No, program APIs use Unix sockets (/dev/log, /run/systemd/journal/socket). > You only get UDP when your local syslog daemon is configured to forward > elsewhere. > > That said, both are datagram sockets, I'm not sure whether sending to Unix > dgram sockets can block or not? Local AF_UNIX/SOCK_DGRAM sockets may block and are reliable. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd Zeroconf address
On Mo, 22.07.19 20:28, Ratan Gupta (ratag...@linux.vnet.ibm.com) wrote: > Hi Team, > > I came across a requirement why the link local address exist with other IP > addresses for IPv4. > > Suppose if I enable the link local address through systemd-networkd then as > per the existing > > behavior, link local address(169.254.*.*) will always exist on the interface > irrespective of whether > > static/dynamic address exist or not. > > The expectation is if either static/dhcp address exist then zeroconfig > address should not come even > > if the zeroconf functionality is enabled. > > Is it correct expectation? is it aligned with other operating system which > is not using systemd-networkd > > as the network manager? In recent networkd you can configure the precise semantics of IPv4LL configuration with the LinkLocalAddressing= setting in .network files. It has a number of different modes to choose from: https://github.com/systemd/systemd/blob/master/man/systemd.network.xml#L340 Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: pci card network interfaces incorrectly named as onboard
On Mo, 22.07.19 14:09, Stuart Hayes (stuart.w.ha...@gmail.com) wrote: > I've got a system on which systemd is incorrectly naming plug-in PCIe > network card interfaces as onboard (eg, eno33) instead of with the PCI slot > number (eg, ens2f0). > > Looking at the source, it looks like the network device naming will, by > default, generate an onboard network name for any device that has an > acpi_index in sysfs. However, acpi_index is present for any network device > which has a _DSM in ACPI for naming the PCI/PCIe device (as described in > section 4.6.7 of the PCI Firmware Spec v3.2)--and this _DSM is not intended > to be used only for onboard network interfaces. (The implementation note > for this _DSM in the firmware spec shows, as an example, what this _DSM > might return for a network card plugged into a PCIe slot.) > > The best solution that I've thought of so far is to make systemd prefer the > naming for the slot (ID_NET_NAME_SLOT) over the naming for an onboard > device (ID_NET_NAME_ONBOARD), if both exist. Does that sound like a > reasonable solution? Well, are you suggesting to make such a change upstream? Isn't this mostly a documentation issue? i.e. that we should say in the docs, that the onboard slot might apply to more than strictly just onboard? I am very conservative with changing the order here, since doing so defeats the whole purpose of the thing: stable names. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Notify type service as non-root user fails
On Mo, 15.07.19 13:33, KIESEL, BRIAN S (bk9...@att.com) wrote: > I have a simple example of a service unit and bash script on rhel7 > using Type=notify that I was trying to get working. When the > service unit is configured to start the script as root things work > as expected. When adding User=testuser it fails. While the script > initially starts (as seen on process list), Journalct -xe reports > many lines like the following and the service eventually timesout. > I am not even clear what these referenced PIDs are associated with > as they don't exist in the process list. So this is messy: sd_notify() messages always originate from a process identified by a PID. The kernel will implicitly attach this info to all messages, but privileged userspace can override it if it likes. The originating PID of a message is then used by systemd to find the cgroup of the process and with that the unit the message belongs to. This is racy for processes down the tree that send a message and die quickly, because systemd doesn't directly watch such processes (it directly watches only the "main" process of a service) and can only use the cgroup of the PID to make sense of it. If by the time systemd tries to figure this out the process already died the data from /proc/$PID/cgroup is already gone, and you get the message you are seeing. Now, the "systemd-notify" binary knows this, and tries to override the sending PID for its messages to be its immediate parent's PID instead, so that systemd sees the program systemd-notify is invoked from as originator, and not systemd-notify itself. That kind of overriding only works if systemd-notify itself is privileged however. If it isn't, then it won't work, and the actual systemd-notify PID is used as originator. There's little we can do about this. Ideally the kernel would just pass the cgroup of the orignator directly to us. If we'd get that the problem would be gone (and a couple of others too): https://github.com/systemd/systemd/issues/2913 Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vconsole for handicapped or older people
Am Montag, den 22.07.2019, 18:49 +0200 schrieb hp hpf: > > Silvio Knizek schrieb am Mo., 22. Juli 2019, > 13:55: > > > Am Montag, den 22.07.2019, 13:20 +0200 schrieb hp4everything: > > > Hi, > > > > > > getting older I'm nearly not able to read the text on a virtual > > > console. > > > I'm working with opensuse tumbleweed on a laptop and was able to > > > configure the KDE screen for my needs, but not the vconsole. > > > > > > Google told me that probably systemd is responsible for vconsole- > > > configuration, but in vconsole.conf there seem to be options for > > > me > > > to make the text readable: > > > > > > - the preconfigured font "eurlatgr" has no fontsize-option > > > - vconsole.conf has no fontsize-parameter > > > - vconsole.conf has no screen-resolution parameter > > > - vconsole.conf has no parameter to select a framebuffer, e.g > > > 1052x768 > > > > > > > > > can anybody help with links to more detailed documentation or > > > with > > > hints > > > how to configure vconsole in systemd/Opensuse Tumbleweed? > > > > > > Thanks > > > Hans-Peter > > > > Hi, > > > > I think your best try would by kmscon [1], which replaces your > > normal > > TTY with something using proper font scaling and such. > > > > HTH > > Silvio > > > > [1]: https://www.freedesktop.org/wiki/Software/kmscon/ > Hi Silvio, > > Thanks for youre recommendation. > > Do you also have a link to more detailed instructions or did > I miss it on the kmscon-homepage? > > Is simple installation in tumbleweed sufficient to replace all > F1-F6-terminals or do I have to configure every single terminal > in systemd-files? > > Tanks in Advanced > Hans-Peter > Hi Hans-Peter, please follow the instructions in the wonderfull Arch Linux wiki [1]. Also please don't answer off-list. BR Silvio [1]: https://wiki.archlinux.org/index.php/KMSCON ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
