Re: [systemd-devel] Stateless System Presets
Could you use systemd-tmpfiles to set up the symlinks? I know OSTree-based distros often use it to initialize symlinks on the rootfs. On Thu, Aug 1, 2019, 12:05 PM Quinn Mikelson wrote: > I work at a company who develops a number of semi-stateless systems. My > current challenge is integrating out growing number of vendor-specific > applications and services into a system with persistent /etc and /usr > directories. > > These images are generated using Buildroot with initramfs filesystems; I'm > using the term semi-stateless, because their /etc and /usr directories can > be "patched" during runtime, but are otherwise refreshed upon each reboot. > > The specific services that get enabled on boot change from image to image, > so I'd ideally like a single file to describe each image for ease of > management. > > The system-preset mechanism seems like it was designed for this > application, unfortunately it seems geared toward volatile systems, and > only operates from within the running system after executing something like > systemctl preset-all. > > Is there an accepted method of maintaining and applying a preset service > during image packaging or upon system boot for stateless systems? My > current solution is manually parsing the preset files with a custom script > and creating or deleting symlinks accordingly. > > -Quinn > > > This e-mail message and any attachments are intended solely for the > specified addressee(s) and may be confidential, proprietary, privileged, > and/or U.S. export controlled. If you are not the intended recipient, you > are hereby notified that any use, disclosure, distribution, copying, or > storage of this message or its attachments is strictly prohibited. Please > immediately notify the sender by return e-mail and delete this message and > any attachments. > ___ > 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] Antw: failing unmounts during reboot
29.07.2019 9:38, Ulrich Windl пишет: Ulrich Windl schrieb am 29.07.2019 um 08:23 in Nachricht <5D3E90D1.4EC : 161 : > 60728>: > Frank Steiner schrieb am 25.07.2019 um > 14:14 in >> Nachricht <913a3c04-a666-b44b-c6ec-fe3d8a7fe...@bio.ifi.lmu.de>: >>> Ulrich Windl wrote: >>> *1: I have a support call open with SUSE: Before systemd (almost) all processes were killed before unmounting. With systemd I'm seeing excessive reboot delays due to unmount timing out. >>> For example if you have a process started from NFS that has a log file on >> NFS >>> open, too. It seems the order is roughly like this: 1) Shutdown the network 2) Try unmounting filesystems, including NFS 3) Kill remaining processes >>> >>> I cannot confirm that, at least not for SLES/D 15. All mount units >>> for NFS filesystems created from fstab get "Before=remote-fs.target", >>> so they are shutdown before the network goes down. Check in >>> /run/systemd/generator to see if this entry is missing in your units. >> >> In SLES12 SP4 (originally reported for SP3) I have: >> # Automatically generated by systemd-fstab-generator >> >> [Unit] >> SourcePath=/etc/fstab >> Documentation=man:fstab(5) man:systemd-fstab-generator(8) >> Before=remote-fs.target >> >> [Mount] >> What=server:/exports/home >> Where=/home >> Type=nfs > > Sorry I hit "send" too quickly: > That would mean the problem of not being unable to umnount /home is not that > the network is down, but that some process still has open files on /home. > > However from the original problem report: > > [ OK ] Stopped target Host and Network Name Lookups. >Stopping Name Service Cache Daemon... > [ OK ] Stopped target Network. >Stopping wicked managed network interfaces... > [ OK ] Stopped Name Service Cache Daemon. > [ OK ] Stopped wicked managed network interfaces. >Stopping wicked network nanny service... > [ OK ] Stopped Check if the profile matches the system. > [ OK ] Stopped wicked network nanny service. >Stopping wicked network management service daemon... > [ OK ] Stopped wicked network management service daemon. >Stopping wicked DHCPv4 supplicant service... >Stopping wicked AutoIPv4 supplicant service... >Stopping wicked DHCPv6 supplicant service... > [ OK ] Stopped wicked DHCPv4 supplicant service. > [ OK ] Stopped wicked DHCPv6 supplicant service. > [ OK ] Stopped wicked AutoIPv4 supplicant service. >Stopping D-Bus System Message Bus... > [ OK ] Stopped SuSEfirewall2 phase 1. > [ OK ] Stopped D-Bus System Message Bus. > [ OK ] Stopped target Basic System. > [ OK ] Stopped target Sockets. Stopping (or at least attempt to stop) /home should have happened before these lines. > ... I would call that a "network shutdown"... > [ OK ] Stopped target Host and Network Name Lookups. >Stopping Name Service Cache Daemon... > [ OK ] Stopped target Network. >Stopping wicked managed network interfaces... > [ OK ] Stopped Name Service Cache Daemon. > [ OK ] Stopped wicked managed network interfaces. >Stopping wicked network nanny service... > [ OK ] Stopped Check if the profile matches the system. > [ OK ] Stopped wicked network nanny service. >Stopping wicked network management service daemon... > [ OK ] Stopped wicked network management service daemon. >Stopping wicked DHCPv4 supplicant service... >Stopping wicked AutoIPv4 supplicant service... >Stopping wicked DHCPv6 supplicant service... > [ OK ] Stopped wicked DHCPv4 supplicant service. > [ OK ] Stopped wicked DHCPv6 supplicant service. > [ OK ] Stopped wicked AutoIPv4 supplicant service. >Stopping D-Bus System Message Bus... > [ OK ] Stopped SuSEfirewall2 phase 1. > [ OK ] Stopped D-Bus System Message Bus. > [ OK ] Stopped target Basic System. > [ OK ] Stopped target Sockets. Do you really have identical lines second time in your log? You need to provide full "systemctl show home.mount" and complete log from boot to shutdown. > ... > I don't see unmounting of /home at all. The unmount errors reported were: > ... > [ OK ] Unmounted Lock Directory. > [FAILED] Failed unmounting Runtime Directory. >Unmounting /var... > [ OK ] Unmounted /opt. > [ OK ] Stopped File System Check on /dev/v04/opt. > [FAILED] Failed unmounting /var. > [ OK ] Stopped File System Check on /dev/v04/var. > (The /var thing has different reasons) > ... > [ OK ] Stopped Remount Root and Kernel File Systems. > [ OK ] Reached target Shutdown. > ...At this point nothing more happened... > Shutdown did not complete within two and a half minute. > And what evidence you have that it is related to /home not being unmounted?
Re: [systemd-devel] Antw: failing unmounts during reboot
25.07.2019 15:14, Frank Steiner пишет: > All mount units > for NFS filesystems created from fstab get "Before=remote-fs.target", > so they are shutdown before the network goes down. > This conslusion is absolutely wrong. Before=remote-fs.target does not (and cannot) order unit shutdown *before* network goes down. You probably misunderstand how systemd ordering works. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Stateless System Presets
I work at a company who develops a number of semi-stateless systems. My current challenge is integrating out growing number of vendor-specific applications and services into a system with persistent /etc and /usr directories. These images are generated using Buildroot with initramfs filesystems; I'm using the term semi-stateless, because their /etc and /usr directories can be "patched" during runtime, but are otherwise refreshed upon each reboot. The specific services that get enabled on boot change from image to image, so I'd ideally like a single file to describe each image for ease of management. The system-preset mechanism seems like it was designed for this application, unfortunately it seems geared toward volatile systems, and only operates from within the running system after executing something like systemctl preset-all. Is there an accepted method of maintaining and applying a preset service during image packaging or upon system boot for stateless systems? My current solution is manually parsing the preset files with a custom script and creating or deleting symlinks accordingly. -Quinn This e-mail message and any attachments are intended solely for the specified addressee(s) and may be confidential, proprietary, privileged, and/or U.S. export controlled. If you are not the intended recipient, you are hereby notified that any use, disclosure, distribution, copying, or storage of this message or its attachments is strictly prohibited. Please immediately notify the sender by return e-mail and delete this message and any attachments. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Thu, Aug 01, 2019 at 08:46:58AM -0400, Brian Reichert wrote: > On Thu, Aug 01, 2019 at 08:17:01AM +, Zbigniew J??drzejewski-Szmek wrote: > > The kernel will use the lower-numbered available fd, so there's lot of > > "reuse" of the same numbers happening. This strace means that between > > each of those close()s here, some other function call returned fd 19. > > Until we know what those calls are, we cannot say why fd19 remains > > open. (In fact, the only thing we can say for sure, is that the > > accept4() call shown above is not relevant.) > > So, what I propose at this step: > > - Restart my strace, this time using '-e trace=desc' (Trace all > file descriptor related system calls.) > > - Choose to focus on a single descriptor; when I passively notice > that '19' has been reused a couple of time, stop the trace. Well, no. If you notice that '19' has STOPPED being reused, then stop the trace. If it is being reused, then it's it's not "leaked". Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Thu, Aug 01, 2019 at 08:17:01AM +, Zbigniew J??drzejewski-Szmek wrote: > The kernel will use the lower-numbered available fd, so there's lot of > "reuse" of the same numbers happening. This strace means that between > each of those close()s here, some other function call returned fd 19. > Until we know what those calls are, we cannot say why fd19 remains > open. (In fact, the only thing we can say for sure, is that the > accept4() call shown above is not relevant.) So, what I propose at this step: - Restart my strace, this time using '-e trace=desc' (Trace all file descriptor related system calls.) - Choose to focus on a single descriptor; when I passively notice that '19' has been reused a couple of time, stop the trace. That should give me a smaller trace to analyze. > Zbyszek -- Brian Reichert BSD admin/developer at large ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd prerelease 243-rc1
On Mi, 31.07.19 13:52, Stefan Tatschner (ste...@rumpelsepp.org) wrote: > On Wed, 2019-07-31 at 13:47 +0200, Lennart Poettering wrote: > > > What is this “strict” mode exactly? > > > > It just means resolved will insist on DNS-over-TLS to talk to the > > configured DNS servers, instead of trying to use it and falling back > > automatically if it's not available. > > Ahh. Thanks for the explanation. I was just wondering if certificate > checks have been implemented. IIRC resolved does not check/validate the > certificate (chain) of the DNS server. Certificate checks have been implemented as well. And they are controlled by the same setting. If strict mode is on, only verifiable certificates are accepted. See: 4310bfc20b84127e19bed68701caa3820c844682 Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 01, 2019 at 10:52:07AM +0200, Francis Moreau wrote: > On Thu, Aug 1, 2019 at 10:36 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Aug 01, 2019 at 10:26:50AM +0200, Francis Moreau wrote: > > > On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > > > > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > you can export and write to a journal file with: > > > > > > journalctl -o export ... | > > > > > > /usr/lib/systemd/systemd-journal-remote -o /tmp/foo.journal - > > > > > > This has the advantage that you can apply any journalctl filter > > > > > > where > > > > > > the dots are, e.g. '-b'. > > > > > > > > > > This doesn't look to work correctly: > > > > > > > > > > $ journalctl -b | head > > > > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > > > > > 08:51:39 CEST. -- > > > > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > > > > > revision 0x25, date = 2018-04-02 > > > > > > > > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > > > > > /tmp/foo.journal - > > > > > $ journalctl -b --file=/tmp/foo.journal | head > > > > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > > > > > 08:45:45 CEST. -- > > > > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > > > > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > > > > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > > > > > en_US.UTF-8) (disconnected from bus) > > > > > > > > > > As you can see, the start is not the same. > > > > > > > > > > Also are foo.journal data compressed ? > > > > > > > > What does "ls /tmp/foo*" say? > > > > > > > > > > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal > > > /tmp/foo.journal > > > > systemd-journal-remote will "rotate" files when they grow above certain > > size. > > (The same as systemd-journald). 'journalctl --file=/tmp/foo*.journal' should > > do the trick. > > Indeed that did the trick, thanks ! > > It's a bit counterintuitive because I asked the journal to be saved in > /tmp/foo.journal only. Can this "rotation" be disabled somehow ? Unfortunately not. That's because of the heritage of those programs which were written in mind with continuous reception of logs in mind, and "conversions" like the one above were just a fortunate side-effect. I guess it'd be nice to make it possible to disable rotation. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 1, 2019 at 10:36 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Aug 01, 2019 at 10:26:50AM +0200, Francis Moreau wrote: > > On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > > > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > you can export and write to a journal file with: > > > > > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote > > > > > -o /tmp/foo.journal - > > > > > This has the advantage that you can apply any journalctl filter where > > > > > the dots are, e.g. '-b'. > > > > > > > > This doesn't look to work correctly: > > > > > > > > $ journalctl -b | head > > > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > > > > 08:51:39 CEST. -- > > > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > > > > revision 0x25, date = 2018-04-02 > > > > > > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > > > > /tmp/foo.journal - > > > > $ journalctl -b --file=/tmp/foo.journal | head > > > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > > > > 08:45:45 CEST. -- > > > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > > > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > > > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > > > > en_US.UTF-8) (disconnected from bus) > > > > > > > > As you can see, the start is not the same. > > > > > > > > Also are foo.journal data compressed ? > > > > > > What does "ls /tmp/foo*" say? > > > > > > > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal > > /tmp/foo.journal > > systemd-journal-remote will "rotate" files when they grow above certain size. > (The same as systemd-journald). 'journalctl --file=/tmp/foo*.journal' should > do the trick. Indeed that did the trick, thanks ! It's a bit counterintuitive because I asked the journal to be saved in /tmp/foo.journal only. Can this "rotation" be disabled somehow ? -- Francis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 01, 2019 at 10:26:50AM +0200, Francis Moreau wrote: > On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > you can export and write to a journal file with: > > > > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o > > > > /tmp/foo.journal - > > > > This has the advantage that you can apply any journalctl filter where > > > > the dots are, e.g. '-b'. > > > > > > This doesn't look to work correctly: > > > > > > $ journalctl -b | head > > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > > > 08:51:39 CEST. -- > > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > > > revision 0x25, date = 2018-04-02 > > > > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > > > /tmp/foo.journal - > > > $ journalctl -b --file=/tmp/foo.journal | head > > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > > > 08:45:45 CEST. -- > > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > > > en_US.UTF-8) (disconnected from bus) > > > > > > As you can see, the start is not the same. > > > > > > Also are foo.journal data compressed ? > > > > What does "ls /tmp/foo*" say? > > > > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal > /tmp/foo.journal systemd-journal-remote will "rotate" files when they grow above certain size. (The same as systemd-journald). 'journalctl --file=/tmp/foo*.journal' should do the trick. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > you can export and write to a journal file with: > > > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o > > > /tmp/foo.journal - > > > This has the advantage that you can apply any journalctl filter where > > > the dots are, e.g. '-b'. > > > > This doesn't look to work correctly: > > > > $ journalctl -b | head > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > > 08:51:39 CEST. -- > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > > revision 0x25, date = 2018-04-02 > > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > > /tmp/foo.journal - > > $ journalctl -b --file=/tmp/foo.journal | head > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > > 08:45:45 CEST. -- > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > > en_US.UTF-8) (disconnected from bus) > > > > As you can see, the start is not the same. > > > > Also are foo.journal data compressed ? > > What does "ls /tmp/foo*" say? > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal /tmp/foo.journal -- Francis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vconsole.conf, systemd-localed and the console keymap in the initrd
On Mi, 31.07.19 14:28, Hans de Goede (hdego...@redhat.com) wrote: > Hi Lennart, > > On 31-07-19 14:07, Lennart Poettering wrote: > > On Di, 30.07.19 10:49, Hans de Goede (hdego...@redhat.com) wrote: > > > > > I believe that the best way to fix is this is probably to specify the > > > keymap on the kernel commandline using vconsole.keymap= on the kernel > > > commandline. > > > > As you found out, our current logic is to let kernel cmdline settings > > override everything else. > > > > To implement what you are looking for we probably should add a new > > setting vconsole.default_keymap= or so which can set the default which > > is used when there's no vconsole.conf or so defined. > > Hmm, that would fix the silverblue case, but not the regular Fedora > case unless we patch dracut to omit vconsole.conf. I was thinking > myself about maybe making systemd-vconsole-setup recognize > rd.vconsole.keymap but only when it is running from the initrd (*). There's actually generic support in our kernel cmdline parser that stuff prefixed with "rd." is only applied in the initrd. you don't have to do any work whatsoever to get this beaviour hence. > *) This requires systemd-vconsole-setup being able to reliable tell > it is running from the initrd, I'm not 100% sure if that is > possible. We have a helper call already in place that is used at various places. It's called in_initrd() and it ultimately checks for the existance of /etc/initrd-release which is supposed to exist only in the initrd. > Sorry, and EFI only solution is not going to cut it, there are still > a lot of users out there using classic BIOS boot and we still support > systems which only support BIOS boot (not to mention non x86 archs). Then say good bye to SecureBoot... > > Note that on secureboot envs you cannot really change the kernel > > cmdline options though, can you? i mean if you could, then you could > > add any rubbish you'd like too, no? > > Actually the grubenv and grub.cfg are not protected in anyway ATM, > which is an area where out secureboot story needs to improve. But since > the kernel cmdline typically includes a root= argument which may well > be a UUID or something else system specific, if we start signing these > files we need a way to locally sign them and which point we can also > update the keymap settings on the kernel cmdline. shudder... > See above for the secureboot part of your question. Yes > vconsole.default_keymap= would work, but I would prefer > rd.vconsole.keymap also for it being backward compat with older > (pre systemd in initrd) initrds. pre-systemd? I mean, knock yourself out, but that's like 10y ago... Anyway, the rd. thing is supported by our parser anyway, as mentioned. 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's connections to /run/systemd/private ?
On Wed, Jul 31, 2019 at 11:37:31AM -0400, Brian Reichert wrote:
> On Wed, Jul 31, 2019 at 12:36:41AM +0300, Uoti Urpala wrote:
> > On Tue, 2019-07-30 at 14:56 -0400, Brian Reichert wrote:
> > > I see, between 13:49:30 and 13:50:01, I see 25 'successful' calls
> > > for close(), e.g.:
> > >
> > > 13:50:01 close(19) = 0
> > >
> > > Followed by getsockopt(), and a received message on the supposedly-closed
> > > file descriptor:
> > >
> > > 13:50:01 getsockopt(19, SOL_SOCKET, SO_PEERCRED, {pid=3323, uid=0,
> > > gid=0}, [12]) = 0
> >
> > Are you sure it's the same file descriptor? You don't explicitly say
> > anything about there not being any relevant lines between those. Does
> > systemd really just call getsockopt() on fd 19 after closing it, with
> > nothing to trigger that? Obvious candidates to check in the strace
> > would be an accept call returning a new fd 19, or epoll indicating
> > activity on the fd (though I'd expect systemd to remove the fd from the
> > epoll set after closing it).
>
> My analysis is naive.
>
> There was an earlier suggestion to use strace, limiting it to a
> limited number of system calls.
>
> I then used a simple RE to look for the string '(19', to see calls where
> '19' was used as an initial argument to system calls. That's way too
> simplistic.
>
> To address some of your questions/points.
>
> - No, I don't know if it's the same file descriptor. I could not
> start strace early enough to catch the creation of several dozen
> file descriptors.
This shouldn't really matter. We care about descriptors which are
created while the process is running, so it is not a problem if we
"miss" some that are created early.
> 13:50:01 accept4(13, 0, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK) = 19
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_PEERCRED, {pid=3323, uid=0, gid=0},
> [12]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_RCVBUF, [4194304], [4]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_SNDBUF, [262144], [4]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_PEERCRED, {pid=3323, uid=0, gid=0},
> [12]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0 13:50:01
> getsockname(19, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, [23])
> = 0 13:50:01 recvmsg(19, {msg_name(0)=NULL, msg_iov(1)=[{"\0AUTH EXTERNAL
> 30\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 256}], msg_controllen=0,
> msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 45
> 13:50:01 sendmsg(19, {msg_name(0)=NULL, msg_iov(3)=[{"OK
> 9fcf621ece0a4fe897586e28058cd2fb\r\nAGREE_UNIX_FD\r\n", 52}, {NULL, 0},
> {NULL, 0}], msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 52
> 13:50:01 sendmsg(19, {msg_name(0)=NULL,
> msg_iov(2)=[{"l\4\1\1P\0\0\0\1\0\0\0p\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\2\1s\0
>
> \0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\7\0\0\0UnitNew\0\10\1g\0\2so\0",
> 128},
> {"\20\0\0\0session-11.scope\0\0\0\0003\0\0\0/org/freedesktop/systemd1/unit/session_2d11_2escope\0",
> 80}], msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = -1 EPIPE
> (Broken pipe)
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
The kernel will use the lower-numbered available fd, so there's lot of
"reuse" of the same numbers happening. This strace means that between
each of those close()s here, some other function call returned fd 19.
Until we know what those calls are, we cannot say why fd19 remains
open. (In fact, the only thing we can say for sure, is that the
accept4() call shown above is not relevant.)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > wrote: > > you can export and write to a journal file with: > > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o > > /tmp/foo.journal - > > This has the advantage that you can apply any journalctl filter where > > the dots are, e.g. '-b'. > > This doesn't look to work correctly: > > $ journalctl -b | head > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > 08:51:39 CEST. -- > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > revision 0x25, date = 2018-04-02 > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > /tmp/foo.journal - > $ journalctl -b --file=/tmp/foo.journal | head > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > 08:45:45 CEST. -- > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > en_US.UTF-8) (disconnected from bus) > > As you can see, the start is not the same. > > Also are foo.journal data compressed ? What does "ls /tmp/foo*" say? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek wrote: > you can export and write to a journal file with: > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o > /tmp/foo.journal - > This has the advantage that you can apply any journalctl filter where > the dots are, e.g. '-b'. This doesn't look to work correctly: $ journalctl -b | head -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 08:51:39 CEST. -- Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to revision 0x25, date = 2018-04-02 $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o /tmp/foo.journal - $ journalctl -b --file=/tmp/foo.journal | head -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 08:45:45 CEST. -- Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication Agent for unix-process:7300:772806437 (system bus name :1.4562, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) As you can see, the start is not the same. Also are foo.journal data compressed ? Thank you. -- Francis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
