Re: [systemd-devel] Please clarify osVersion in ELF package metadata

[Dave Howorth]

On Tue, 18 Jun 2024 11:24:22 +0200
Benjamin Drung  wrote:
> On Mon, 2024-06-17 at 11:19 -0500, Greg Oliver wrote:
> > On Mon, Jun 17, 2024 at 10:38 AM Benjamin Drung 
> > wrote:  
> > > On Mon, 2024-06-17 at 14:54 +0100, Luca Boccassi wrote:  
> > > > On Mon, 17 Jun 2024 at 14:45, Benjamin Drung
> > > >  wrote:  
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Ubuntu started to implement the ELF package metadata spec. It
> > > > > encodes the VERSION_ID from os-release in the osVersion
> > > > > field. Using VERSION_ID was objected to because the version
> > > > > is only set in stone once the release is done. It could
> > > > > change during the development cycle. See
> > > > > https://lists.ubuntu.com/archives/ubuntu-devel/2024-June/043027.html
> > > > > and
> > > > > https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2069599
> > > > > 
> > > > > The proposal is to use VERSION_CODENAME from os-release
> > > > > instead.
> > > > > 
> > > > > To me it is not clear enough what is the best approach
> > > > > regarding the spec https://systemd.io/ELF_PACKAGE_METADATA/
> > > > > here.
> > > > > 
> > > > > The key description says "typically"? So could we just use
> > > > > VERSION_CODENAME for osVersion?
> > > > > 
> > > > > Or should be use a different key like osVersionCodename to
> > > > > allow third- party users to still use VERSION_ID for
> > > > > osVersion? In that case osVersionCodename should probably
> > > > > added to the well-known keys.
> > > > > 
> > > > > What's your take on it?  
> > > > 
> > > > Hi,
> > > > 
> > > > I replied on ubuntu-devel but it's moderated, so the message
> > > > didn't make it through and is waiting for approval.
> > > > 
> > > > The gist of it is that this is supposed to be machine readable,
> > > > and be what is commonly understood as the version, which for
> > > > the next ubuntu version would be 23.10.
> > > > 
> > > > Given it's sourced from os-release, which is sourced from
> > > > base-files, ideally you'd do an archive-wide rebuild once it is
> > > > finalized (that also gives you builds with newer compiler
> > > > hardening and other niceties). If that's not possible or not
> > > > wanted, simply omit the osVersion field. Parsers need to expect
> > > > that to be optional, in order to avoid breaking on rolling
> > > > release distros like Arch that do not have a version.  
> > > 
> > > From that perspective Debian and Ubuntu are semi-rolling releases:
> > > Packages are copied over from one release to another. As long as
> > > there is no new upload happening for the package between two
> > > release, the identical binary package will be shipped. So
> > > osVersion would still be unchanged. So osVersion indicated which
> > > os version the package was introduced but not on which release it
> > > is running on. Do you suggest to omit osVersion due to that?
> > > 
> > > My initial question targets a different problem: The version
> > > number is finalized (set in stone) on release date. Ubuntu was
> > > released on time except for one case. In such case where we need
> > > more time and delay the release, we won't have time to start an
> > > archive wide rebuild of all package just to correct osVersion in
> > > the ELF objects. On the other hand the version codename is set in
> > > stone when the archive for that release is opened. That's why it
> > > was suggested to use the version codename instead of the version
> > > ID.  
> > 
> > IMHO, a rolling release is just that - it is self explanatory.
> > Debian and Ubuntu are definitely not that.  In your given scenario,
> > the packages should be rebuilt for the current OS Release with the
> > metadata bumped even if it is the same version o said package.
> > Also, you will definitely be bumping the c libraries with each OS
> > version bump, so you would always want to re-compile them with the
> > current libraries and keep them separate via the OS release based
> > repository directories - yes?  I think over-engineering is going on
> > here :)   
> 
> No, Debian and Ubuntu are much bigger than other distributions.
> Currently there are 38,579 source packages in Ubuntu. We will not
> rebuild them every six month for a new release. There will be new
> builds of the package in case it gets updated/changed or a used
> library transitions from one ABI to another.

It seems to me that the ELF package metadata spec is not designed for
your use case. It is designed for a simpler world. It seems you need to
record details of exactly what source version of everything a program
is built against and also details of exactly what binary version of
libraries it is linked against when run. You need both sets of
information to reliably debug problems. I'm not sure of the best way of
achieving that.

> -- 
> Benjamin Drung
> Debian & Ubuntu Developer

Re: [systemd-devel] How to chain services driven by a timer?

[Dave Howorth]

On Wed, 10 Apr 2024 17:07:36 -0400
Brian Reichert  wrote:

> Hopefully someone here can assure me this is just due to an artifact
> of bookkeeping. I'm specifically trying to avoid doing any work
> while logrotate is running.

I know it's a bodge, but put a short delay at the start of your
post-rotate job?

Re: [systemd-devel] Permissions problems with systemd-networkd and others.

[Dave Howorth]

On Wed, 7 Feb 2024 20:41:40 +
"Murrell, Robert A."  wrote:
> I finally got everything working.  Here is what I did to fix the
> problem:
> 
> adduser systemd-network root
> adduser systemd-resolve root
> adduser bind root
> find /etc -type d -exec chmod 755 {} +
> 
> I don’t know who does this on a full linux image.  I’m posting it
> here for the next person who has this problem. I would suggest that
> release testing include a minimal Linux image to support embedded and
> IoT devices.

I would have thought this is a question for your distro rather than for
systemd?
 
> Robert Murrell
> Embedded Software Engineer
> STANLEY Assembly Technologies
> 
> 2500 Meijer Dr., Troy, MI 48084
> T 248-677-9740
> robert.murr...@sbdinc.com |
> www.StanleyEngineeredFastening.com
> 
> [http://esignature.stanleyblackanddecker.com/images/stanleyengineeredfastening.png]
> 
> This email, including any attached files, is intended only for the
> person to whom or the entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance
> upon, this information by persons or entities other than the intended
> recipient is prohibited. If you received this in error, please
> contact the sender and delete the material from any computer.
> 
> 
> From: Murrell, Robert A. 
> Sent: Wednesday, February 7, 2024 11:43 AM
> To: systemd-devel@lists.freedesktop.org
> Subject: RE: Permissions problems with systemd-networkd and others.
> 
> I should have added that I am building a very stripped down image.
> These are the Debian packages that are being installed:
> 
> linux-image-6.2.0 - locally built
> firmware-imx-epdc - locally built
> firmware-imx-sdma - locally built
> firmware-imx-vpu - locally built
> firmware-realtek - locally built
> busybox
> locales
> u-boot-image-mspmb-2017.11 - locally built
> u-boot-tools-mspmb-2017.11 - locally built
> dosfstools
> openssl
> libmbedtls12
> gnutls-bin
> gdbserver
> socat
> fdisk
> nano
> ssh
> openvpn
> iwd
> iproute2
> nftables
> net-tools
> usbutils
> iputils-ping
> dnsutils
> isc-dhcp-server
> hostapd
> bind9
> wireless-tools
> wpasupplicant
> policykit-1
> weston
> kbd
> xwayland
> mesa-utils
> libdrm-etnaviv1
> chromium
> fonts-arphic-uming
> fonts-ipafont-mincho
> fonts-ipafont-gothic
> gstreamer1.0-plugins-good
> gstreamer1.0-plugins-bad
> gstreamer1.0-plugins-ugly
> v4l-utils
> kmod
> mono-runtime
> rng-tools
> cron
> 
> I installed policykit-1 after my first request, but it didn’t help.
> Also, here is an excerpt from the journal:
> 
> Jun 18 14:56:02 mspmbsat systemd[1]: systemd-networkd.service:
> Scheduled restart job, restart counter is at 4. Jun 18 14:56:02
> mspmbsat systemd[1]: Stopped Network Service. Jun 18 14:56:02
> mspmbsat systemd[1]: Starting Network Service... Jun 18 14:56:02
> mspmbsat systemd[241]: systemd-networkd.service: Failed to
> execute /lib/systemd/systemd-networkd: Permission denied Jun 18
> 14:56:02 mspmbsat systemd[241]: systemd-networkd.service: Failed at
> step EXEC spawning /lib/systemd/systemd-networkd: Permission denied
> Jun 18 14:56:02 mspmbsat systemd[1]: systemd-networkd.service: Main
> process exited, code=exited, status=203/EXEC Jun 18 14:56:02 mspmbsat
> systemd[1]: systemd-networkd.service: Failed with result 'exit-code'.
> 
> Jun 18 14:56:02 mspmbsat systemd[1]: Failed to start Network Service.
> 
> Is there some other package I need to install to get this to work?
> 
> Robert Murrell
> Embedded Software Engineer
> STANLEY Assembly Technologies
> 
> 2500 Meijer Dr., Troy, MI 48084
> T 248-677-9740
> robert.murr...@sbdinc.com |
> www.StanleyEngineeredFastening.com
> 
> [cid:image001.png@01DA59DB.CD6E9FE0]
> 
> This email, including any attached files, is intended only for the
> person to whom or the entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance
> upon, this information by persons or entities other than the intended
> recipient is prohibited. If you received this in error, please
> contact the sender and delete the material from any computer.
> 
> 
> From: Murrell, Robert A.
> mailto:robert.murr...@sbdinc.com>> Sent:
> Tuesday, February 6, 2024 4:44 PM To:
> systemd-devel@lists.freedesktop.org
> Subject: Permissions problems with systemd-networkd and others.
> 
> Greetings,
> 
> I’m attempting to update one of our products from Debian Stretch with
> Linux kernel 4.14 to Debian Bullseye with Linux kernel 6.2.0.  The
> target system is an ARM iMX6QP.  I’ve managed to build the kernel
> from the old .config file.  The image is built using ELBE builder and
> reprepro for local packages (not my 

Re: [systemd-devel] Why are the priorities of stdout and stderr the same

[Dave Howorth]

On Tue, 29 Aug 2023 23:05:28 +0200
Nils Kattenbeck  wrote:
> No, you can use systemd-cat to then invoke your script which applies
> to every output of it.
> 
> Also, you can just use reply-all in gmail (or even set it as the
> default in the settings) to have the correct behaviour of sending
> mails also the the mailing list.

That's not the correct behaviour! The correct behaviour is to reply
only to the list and not pollute posters' inboxes with extra copies.

The solution to problems with gmail is simple. Stop using gmail and
find another provider. There are many.

Re: [systemd-devel] Additional Locale Variables for Units and Number Format

[Dave Howorth]

On Wed, 30 Aug 2023 00:53:55 +
TJ Shipp  wrote:
> Thank you, I think LC_NUMERIC will work for the number formatting, my
> company is also looking for something along the lines of this, and
> hoping to use locale/systemd to handle it:
> 
> https://lists.freedesktop.org/archives/xdg/2023-August/014659.html
> 
> From: systemd-devel  on
> behalf of systemd-devel-requ...@lists.freedesktop.org
>  Sent: Tuesday, August
> 29, 2023 6:24 PM To: systemd-devel@lists.freedesktop.org
>  Subject: systemd-devel Digest,
> Vol 160, Issue 37
> 
> Send systemd-devel mailing list submissions to
> systemd-devel@lists.freedesktop.org

Please trim your replies, especially if replying to a digest!

What you're looking for sounds under-specified and potentially very
complex. I would recommend that you try to implement a freestanding
system that implements all the requirements you have, and only then
consider integrating it in whatever 'standard' you think is appropriate.

At present I don't think you'll find it easy to persuade people this is
something that is sensible to incorporate in some other system.

Re: [systemd-devel] Normal user can ask status of services

[Dave Howorth]

On Sat, 26 Aug 2023 16:17:46 +0300
Andrei Borzenkov  wrote:
> On 26.08.2023 15:46, Michael Biebl wrote:
> > 
> > Reading system logs is a privileged operation.
> 
> It is not about reading logs but about being able to "systemctl
> status some-system-unit"
> 
> > You can grant this privilege to individual users by adding them to
> > the systemd-journal (or adm) group.
> 
> The question was how to prevent normal users from seeing system unit
> status.

TBF, it wasn't really clear (to me at least) what the question was
about. Either what you surmised, or what Michael surmised or maybe
about which Debian releases have cron installed by default? I certainly
couldn't work it out.

Re: [systemd-devel] deprecating Forward-Secure Sealing (FSS) in the journal

[Dave Howorth]

On Sun, 30 Jul 2023 11:52:34 -0400
Demi Marie Obenour  wrote:
> On Thu, Jul 27, 2023 at 08:10:41AM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > Hi,
> > 
> > I'd like to start $subject. First, we'd just add an entry in NEWS
> > and make the key generation code print a warning, but then in a
> > release or few remove the code.
> > 
> > See
> > https://github.com/systemd/systemd/pull/28433/commits/1ecd1a994733d.
> > 
> > If you're using FSS, please speak up.
> > 
> > Zbyszek  
> 
> What is the reason for this change?

Does the comment in the commit not answer that?

> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

Re: [systemd-devel] systemd-devel Digest, Vol 157, Issue 8

[Dave Howorth]

On Tue, 9 May 2023 18:43:33 -0700
Benjamin Godfrey  wrote:
> I'm trying to be helpful,

breaking threading, top-posting and repeatedly using a gneneric subject
line doesn't seem to be be 'trying to be helpful'. It seems more like
'trying to irritate the people you'd like to help'.

PS please don't send me a personal copy of any reply.

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Dave Howorth]

On Wed, 23 Mar 2022 22:26:15 +0100
Michael Biebl  wrote:
> Am Mi., 23. März 2022 um 22:11 Uhr schrieb Zbigniew Jędrzejewski-Szmek
> :
> 
> > Or in other words: I'd prefer for such people to speak up for
> > themselves, rather than us trying to figure out what somebody else
> > *might* be planning to do.  
> 
> That's laudable but keep in mind that users typically don't follow
> systemd-devel actively. I'm pretty sure we don't even have
> *maintainers* of embedded Linux following this mailing list.

I'm just a user and I follow this list. That is to say, it doesn't
matter what typical users or maintainers do, it's enough if just one
relevant person is following. It would be nice though, if there are any
such people, if they would speak up and offer their opinion or say that
they are going to take it to whichever manager/committee they need to.

FWIW, I think Greg was a bit too outspoken calling long maintenance
attempts 'crazy'; that may have intimidated some. I'm thinking of
moving distro to one that provides longer term maintenance than my
present one. Although CIP is a completely different ball game; I hope
they succeed.

Cheers, Dave

Re: [systemd-devel] Syntax check for a new service?

[Dave Howorth]

On Sat, 26 Feb 2022 09:17:38 -0600
Tom Browder  wrote:
> Is there any way to get a plain syntax check of a potential new
> service file?

systemd-analyze verify FILE...

https://www.freedesktop.org/software/systemd/man/systemd-analyze.html

> I currently check it by installing, reloading, and enabling, and then
> getting a status check where I see the service isn't running and I see
> multiple messages:
> 
>  [in black text]*:N: Missing '='
>  [in red text]*:N: Failed to parse sec value, ignoring: always
> 
> I can include my current file if you'd like.
> 
> I'm running Debian Buster (10) fully updated.
> 
> Thanks.
> 
> -Tom

Re: [systemd-devel] [RFC] systemd-resolved: Send d-bus signal after DNS resolution

[Dave Howorth]

On Tue, 15 Feb 2022 22:37:41 +
Suraj Krishnan  wrote:
> Hello,
> 
> I'm reaching out to the community to gather feedback about a feature
> to broadcast a d-bus signal notification from systemd-resolved when a
> DNS query is completed. The message would contain information about
> the query and IP addresses received from the DNS server.

Sorry, I'm just an ignorant user but surely this woulkd have privacy
implications? If I make a DNS request from an application, I expect
that to be private, not shared with whatever other processes or users
might be on the system.
 
> This could be used by applications for auditing/logging services
> downstream of the resolver, or to update the firewall on the system.

Perhaps an example use case would help but I'm not clear how a DNS
resolution would usefully cause a state change in the firewall without
some further external guidance?

> I'm not familiar with how the code is written to be able to determine
> the feasibility of this approach, or if there is a better way to
> accomplish this. I welcome suggestions for this feature.
> 
> Thanks,
> Suraj

Re: [systemd-devel] asset failure that looks like it's coming from systemd/

[Dave Howorth]

On Sat, 25 Dec 2021 17:29:06 +1100
Jonathan Kelly  wrote:
> On 25/12/21 15:04, Scott Andrews wrote:
> > On Sat, 25 Dec 2021 07:43:14 +1100
> > Jonathan Kelly  wrote:
> >  
> >> On 25/12/21 01:23, Andy Pieters wrote:  
> >>>
> >>> On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly
> >>>   wrote:
> >>>
> >>>  On 24/12/21 19:45, Andy Pieters wrote:  
> 
>   On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly
> wrote:
> 
>   make[2]: Entering directory
>  '/usr/local/src/unicon/uni/lib' ../../bin/unicon -s -c gui.icn
>   Assertion '(size_t) r < n' failed at
>   src/basic/random-util.c:232,
>   function genuine_random_bytes(). Aborting.
>   make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted
>  (core dumped)
> 
> 
>   What points you to suspect systems?  
> >>>
> >>>  the line from the error
> >>>
> >>>  Assertion '(size_t) r < n' failed at
> >>> src/basic/random-util.c:232,
> >>>
> >>>  that's from systemd.
> >>>
> >>>
> >>>  https://github.com/systemd/systemd/blob/main/src/basic/random-util.c
> >>>
> >>>  look at line 232
> >>>
> >>> 
>   Have you looked at the coredump? (i.e. coredumpctl)  
> >>>  No. I'm in the middle here ... trying to compile unicon and
> >>> it borks ... the unicon people don't know anything about
> >>>  random-util.c ... it not part of their software.
> >>>
> >>>  If it comes to it, I can look at more technical sleuthing,
> >>> but I'd need some direction.
> >>>
> >>>
> >>>  Jonathan.
> >>>
> >>>
> >>> After googling this for 1 minute I came across this [1]
> >>>
> >>> Arch AUR package is out of date, use  the GIT version as
> >>> documented in [1]
> >>>
> >>> Not the fault of systemd, the fault of using an old package. They
> >>> explain that they stopped using svn in 2019, and having just
> >>> downloaded the Arch AUR package it shows svn checkout in the
> >>> prepare function...
> >>>
> >>> [1]
> >>> https://sourceforge.net/p/unicon/discussion/starters/thread/4ea4931e8e/?limit=25
> >>>   
> >>> 
> >>
> >> I'm not using the AUR, I'm cloning from GIT
> >>
> >>
> >>
> >> ./configure
> >> make
> >>
> >>
> >> I do know how to use google: that's how I found out
> >> src/basic/random-util.c was part of systemd
> >>
> >>
> >> Jonathan.  
> > I have been following this so I tried the following:
> >
> > cd /tmp
> > git clone git://git.code.sf.net/p/unicon/unicon
> > cd unicon
> > ./configure
> > make -j4
> > cd /tmp/unicon/bin/
> > ./unicon -version
> > Unicon Version 13.3.  December 23, 2021 (13.2-232-g3438a755
> > pre-release)
> >
> > ./unicon -features
> > Unicon Version 13.3.  December 23, 2021 (13.2-232-g3438a755
> > pre-release)
> > UNIX
> > POSIX
> > DBM
> > ASCII
> > co-expressions
> > native coswitch
> > concurrent threads
> > dynamic loading
> > environment variables
> > event monitoring
> > external functions
> > keyboard functions
> > large integers
> > multiple programs
> > pattern type
> > pipes
> > pseudo terminals
> > system function
> > messaging
> > libz file compression
> > CCompiler gcc 8.3.0
> > Physical memory: 3932356608 bytes
> > Revision 6306_3438a755
> > Arch arm_32
> > CPU cores 4
> > binaries at /tmp/unicon/bin/
> >
> > My platform is raspberry pi 4 with raspios 32 bit os
> > This has systemd version v247.  raspios is based on debian 10
> >
> > Is your platform/system failing as in out of memory or something
> > like that?
> >
> > Maybe some type of corruption?
> >
> > What compiler are you using?  
> 
> Arch linux 64 bit - AMD FX6300 6 core / 16G mem
> 
> jon@arch:/usr/local/src/unicon$ uname -a
> Linux arch 5.15.10-arch1-1 #1 SMP PREEMPT Fri, 17 Dec 2021 11:17:37 
> + x86_64 GNU/Linux
> 
> jon@arch:/usr/local/src/unicon$ bin/unicon -features
> Unicon Version 13.3.  December 14, 2021 (13.2-228-gf1990ae5
> pre-release) UNIX
> POSIX
> DBM
> ASCII
> co-expressions
> native coswitch
> concurrent threads
> dynamic loading
> environment variables
> event monitoring
> external functions
> keyboard functions
> large integers
> multiple programs
> pattern type
> pipes
> pseudo terminals
> system function
> messaging
> graphics
> X Windows
> libz file compression
> JPEG images
> PNG images
> SQL via ODBC
> secure sockets layer encryption
> CCompiler gcc 11.1.0
> Physical memory: 16806125568 bytes
> Revision 6305_f1990ae5
> Arch x86_64
> CPU cores 6
> Binaries at /usr/local/src/unicon/bin/

I'm confused now. Previously you showed make aborting and core dumping.
So how come you now have a compiled binary you can run? Albeit a
slightly earlier version than is current.

FWIW, I think Mike Gilbert's suggestion is sensible.

Re: [systemd-devel] early mounts in systemd

[Dave Howorth]

On Sat, 1 May 2021 18:08:55 +0200
Michael Biebl  wrote:
> Am Sa., 1. Mai 2021 um 18:07 Uhr schrieb Michael Biebl
> :
> >
> > Am Sa., 1. Mai 2021 um 17:46 Uhr schrieb Dave Howorth
> > :  
> > > If systemd removes (i.e. doesn't obey) a directive, I'd expect it
> > > to be polite and log that fact somewhere. No?  
> >
> > It should, yes.  
> 
> To be precise, it should log a message like here
> https://sources.debian.org/src/systemd/247.3-5/src/core/transaction.c/?hl=414#L414

Many thanks :) Rick and/or Luca should be able to find that if it is the
source of their problems!

PS however you sent your mail, it meant that my MUA didn't
automatically send a copy to the list when I hit reply. I'd much prefer
to keep everything on list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Dave Howorth]

On Fri, 30 Apr 2021 22:08:17 +0200
Michael Biebl  wrote:
> Am Fr., 30. Apr. 2021 um 20:27 Uhr schrieb Rick Winscot
> :
> 
> > At this point, flush is attempting to re-route /run/log/journal
> > to /var/log/journal ... and the /var partition is not yet mounted.
> > Units generated for fstab in /run/systemd/generator that manage the
> > mount have an After=local-fs-pre.target which is too late.
> >
> > Other dependency errors appear in the log; all with the same root
> > cause. By the time [ a specified service ] that uses /var is ready,
> > the partition has not yet been mounted. My solution resolves
> > the /var mount as soon as the block device is seen by udev - which
> > made all the dependency errors go away.  
> 
> Fwiw, I can't reproduce the problem. systemd-journal-flush.service is
> correctly started after /var has been mounted.
> In case you are interested, I attached a journalctl dump, /etc/fstab
> and systemd-analyze dump as well.
> As you can see, systemd-journal-flush.service has a proper
> After=var.mount ordering.
> 
> I wonder if you have a dependency loop somewhere and systemd resolves
> this by removing that ordering.

If systemd removes (i.e. doesn't obey) a directive, I'd expect it to be
polite and log that fact somewhere. No?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Guidance on automount/unmount for external powered devices

[Dave Howorth]

On Thu, 11 Mar 2021 11:00:04 +
Patrick O'Callaghan  wrote:
> Unfortunately a system reboot always leaves it in the 'powered up and
> present in /dev/md' state, so I have to manually run the power-down
> script every time I reboot. This is inelegant.

There may be better ways, but could you use an @reboot crontab entry
containing something like

sleep 30 && do-whatever-you-need-to-issue-the-power-down
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Q: Debugging missing requirements

[Dave Howorth]

On Fri, 12 Feb 2021 18:04:58 +0300
Andrei Borzenkov  wrote:
> 12.02.2021 10:04, Ulrich Windl пишет:
>  Andrei Borzenkov  schrieb am 11.02.2021 um
>  15:20 in  
> > Nachricht
> > :  
> >> On Thu, Feb 11, 2021 at 1:47 PM Ulrich Windl
> >>  wrote:  
> >>>
> >>> Hi!
> >>>
> >>> Suspecting systemd added some requirement that isn't fulfilled
> >>> after boot,   
> >> preventing my units from starting I wonder:  
> >>> How can I debug systemd's requirements checking for units that
> >>> are enabled,   
> >> but not started at boot (status "inactive (dead)"?
> >>
> >> Usual advice is - enable debug logging.  
> > 
> > Can I enable this for a specific unit, or just globally?
> 
> Not that I am aware of. It is all or nothing.

But you don't need to look at them all for other units. You can use
--priority to view just the levels you wish to. So there'll be more
information in the log files, but no need to look at it unless you wish
to.

> >>  
> >>> Or another way: Can I list the dependencies that systemd added   
> >> automatically?  
> >>>  
> >>
> >> If you mean implicit or default dependencies - no. They are listed
> >> in man pages, although there is no guarantee that list is
> >> complete. Your best bet is source code.  
> > 
> > 
> > 
> >   
> 
> ___
> 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] consider dropping defrag of journals on btrfs

[Dave Howorth]

On Fri, 5 Feb 2021 17:44:14 +0100
Lennart Poettering  wrote:
> On Fr, 05.02.21 16:06, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> > On Fri, 5 Feb 2021 16:23:02 +0100
> > Lennart Poettering  wrote:  
> > > I don't think that makes much sense: we rotate and start new
> > > files for a multitude of reasons, such as size overrun, time
> > > jumps, abnormal shutdown and so on. If we'd always leave a fully
> > > allocated file around people would hate us...  
> >
> > I'm not sure about that. The file is eventually going to grow to
> > 128 MB so if there isn't space for it, I might as well know right
> > now as later. And it's not like the space will be available for
> > anything else, it's left free for exactly this log file.  
> 
> let's say you assign 500M space to journald. If you allocate 128M at a
> time, this means the effective unused space is anything between 1M and
> 255M, leaving just 256M of logs around. it's probably surprising that
> you only end up with 255M of logs when you asked for 500M. I'd claim
> that's really shitty behaviour.

If you assign 500 MB for something that accommodates multiples of 128
MB then you're not very bright :) 512 MB by contrast can accommodate 4
128 MB files, and I might allocate an extra MB or two for overhead, I
don't know. So when it first starts there'll be 128 MB allocated and
384 MB free. In stable state there'll be 512 MB allocated and nothing
free. One 128 MB allocated and slowly being used. 384 MB full of
archive files. You always have between 384 MB and 512 MB of logs
stored. I don't understand where you're getting your numbers from.

BTW, I expect my linux systems to stay up from when they're booted
until I tell them to stop, and that's usually quite a while.

> > Or are you talking about left over files after some exceptional
> > event that are only part full? If so, then just deallocate the
> > unwanted empty space from them after you've recovered from the
> > exceptional event.  
> 
> Nah, it doesn't work like this: if a journal file isn't marked clean,
> i.e. was left in some half-written state we won't touch it, but just
> archive it and start a new one. We don't know how much was correctly
> written and how much was not, hence we can't sensibly truncate it. The
> kernel after all is entirely free to decide in which order it syncs
> writte blocks to disk, and hence it quite often happens that stuff at
> the end got synced while stuff in the middle didn't.

If you can't figure out which parts of an archived file are useful and
which aren't then why are you keeping them? Why not just delete them?
And if you can figure it out then why not do so and compact the useful
information into the minimum storage?

> > > Also, we vacuum old journals when allocating and the size
> > > constraints are hit. i.e. if we detect that adding 8M to journal
> > > file X would mean the space used by all journals together would
> > > be above the configure disk usage limits we'll delete the oldest
> > > journal files we can, until we can allocate 8M again. And we do
> > > this each time. If we'd allocate the full file all the time this
> > > means we'll likely remove ~256M of logs whenever we start a new
> > > file. And that's just shitty behaviour.  
> >
> > No it's not; it's exactly what happens most of the time, because all
> > the old log files are exactly the same size because that's why they
> > were rolled over. So freeing just one of those gives exactly the
> > right size space for the new log file. I don't understand why you
> > would want to free two?  
> 
> Because fs metadata, and because we don't always write files in
> full. I mean, we often do not, because we start a new file *before*
> the file would grow beyond the threshold. this typically means that
> it's typically not enough to delete a single file to get the space we
> need for a full new one, we usually need to delete two.

Why would you start a new file before the old one is full? Modulo truly
exceptional events. It's a genuine question - I don't think I've ever
seen it. And sure fs metadata - that just means allocate a bit extra
beyond the round number.

> actually it's even worse: btrfs lies in "df": it only updates counters
> with uncontrolled latency, hence we might actually delete more than
> necessary.

Sorry dunno much about btrfs. I'm planning to get rid of it here soon.

> Lennart

PS I'm subscribed to the list. I don't need a copy.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] consider dropping defrag of journals on btrfs

[Dave Howorth]

On Fri, 5 Feb 2021 16:23:02 +0100
Lennart Poettering  wrote:
> I don't think that makes much sense: we rotate and start new files for
> a multitude of reasons, such as size overrun, time jumps, abnormal
> shutdown and so on. If we'd always leave a fully allocated file around
> people would hate us...

I'm not sure about that. The file is eventually going to grow to 128 MB
so if there isn't space for it, I might as well know right now as
later. And it's not like the space will be available for anything else,
it's left free for exactly this log file.

Or are you talking about left over files after some exceptional event
that are only part full? If so, then just deallocate the unwanted empty
space from them after you've recovered from the exceptional event.

> Also, we vacuum old journals when allocating and the size constraints
> are hit. i.e. if we detect that adding 8M to journal file X would mean
> the space used by all journals together would be above the configure
> disk usage limits we'll delete the oldest journal files we can, until
> we can allocate 8M again. And we do this each time. If we'd allocate
> the full file all the time this means we'll likely remove ~256M of
> logs whenever we start a new file. And that's just shitty behaviour.

No it's not; it's exactly what happens most of the time, because all
the old log files are exactly the same size because that's why they
were rolled over. So freeing just one of those gives exactly the right
size space for the new log file. I don't understand why you would want
to free two?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] jio is an experimental systemd-journald journal file tool utilizing io_uring

[Dave Howorth]

On Wed, 25 Nov 2020 19:02:21 -0800
Vito Caputo  wrote:

> I've called this program jio, pronounced "jai-oh".

Silly question, but how is 'jai' pronounced?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to turn off the ntp time synchronization in default when power on

[Dave Howorth]

On Tue, 24 Nov 2020 21:54:22 +0200
Mantas Mikulėnas  wrote:
> On Tue, Nov 24, 2020, 21:43 An Liu  wrote:
> 
> > HI
> >
> > timedatectl set-ntp false
> >
> >
> > what is the diff between this and
> > systemctl disable ntp
> >  
> 
> The timedatectl command controls only systemd's own NTP client
> (systemd-timesyncd.service). It doesn't care about other NTP clients
> such as ntp.service or chrony.service.
> 
> Other than that, there is not much difference – they both just
> enable/disable services.

The man page says that timedatectl also stops the service if running?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing spam error messages in the system journal

[Dave Howorth]

On Thu, 22 Oct 2020 15:27:58 +0200
Reindl Harald  wrote:
> Am 22.10.20 um 12:59 schrieb Lennart Poettering:
> > On Do, 22.10.20 11:11, David C. Partridge
> > (david.partri...@perdrix.co.uk) wrote: 
>   1) Is there any way in journald.conf to perform a
>  message  
> >> suppression  
>  similar to the one I used for syslog? If not should there be
>  one?  
> >>  
> >>> No.  
> >>
> >> Does that mean no there isn't and also that there should not be,
> >> or are you open to considering allowing a suppression mechanism
> >> similar to that available in rsyslogd?  
> > 
> > Not a fan of such hacks. Fix the programs or filter during display,
> > don't suppress at time of collection.  
> 
> it's not a matter of fan or not
> 
> it just makes sense to filter out things one *never* want to see at
> all instead store it

I think Lennart's point is that whatever happened to cause something in
the system to make a log entry happened, and that should be recorded.
Even though you may never want to see such evidence somebody, somewhere
might want it as part of an investigation, so it's better that it's
captured and preserved. The space will eventually be reclaimed so
there's no harm done.

And as he suggests, if you never want to see it, then filter it out on
display.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: shutdown messages and the lack of such

[Dave Howorth]

On Thu, 8 Oct 2020 16:44:28 +0100
Dave Howorth  wrote:
> On Thu, 08 Oct 2020 14:29:24 +
> fox  wrote:
> > > I wonder: Shouldn't here be an infiormational message at least
> > > when the shutdown command is entered, and at least a notice
> > > message when the actual shutdown time has arrived?
> > > If you review syslog laternot at all obvious what had
> > > happened.
> > 
> > 
> > shutdown [OPTIONS...] [TIME] [WALL...]
> > 
> > Note that to specify a wall message you must specify a time
> > argument, too.
> > --no-wall #  Do not send wall message before halt, power-off,
> > reboot.
> > 
> > so, "shutdown now" # has an implicit   --no-wall
> > 
> > seems it acts according to specs.  
> 
> I think Ulrich's point was that the docs for previous versions of
> shutdown were consistent with its behaviour, which was to send a wall
> message and you could customise the message by supplying a command
> line argument.
> 
> It appears that the systemctl implementation has changed the
> behaviour, and the documentation. Whether there is a spec anywhere
> (POSIX or whatever) I do not know - but certainly a man page is not a
> spec. Nor do I know whether this was a deliberate and publically
> agreed change in behaviour or something else.

Just to add that a quick bit of searching has found only
https://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/shutdown.html
as a possible spec and it says the old way is correct and systemd's is
wrong.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: shutdown messages and the lack of such

[Dave Howorth]

On Thu, 08 Oct 2020 14:29:24 +
fox  wrote:
> > I wonder: Shouldn't here be an infiormational message at least when
> > the shutdown command is entered, and at least a notice message when
> > the actual shutdown time has arrived?
> > If you review syslog laternot at all obvious what had happened.  
> 
> 
> shutdown [OPTIONS...] [TIME] [WALL...]
> 
> Note that to specify a wall message you must specify a time argument, 
> too.
> --no-wall #  Do not send wall message before halt, power-off, reboot.
> 
> so, "shutdown now" # has an implicit   --no-wall
> 
> seems it acts according to specs.

I think Ulrich's point was that the docs for previous versions of
shutdown were consistent with its behaviour, which was to send a wall
message and you could customise the message by supplying a command line
argument.

It appears that the systemctl implementation has changed the behaviour,
and the documentation. Whether there is a spec anywhere (POSIX or
whatever) I do not know - but certainly a man page is not a spec. Nor
do I know whether this was a deliberate and publically agreed change
in behaviour or something else.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to reply to the list

[Dave Howorth]

On Wed, 30 Sep 2020 09:35:35 +0200
"Ulrich Windl"  wrote:
> >>> Dave Howorth  schrieb am 28.09.2020 um
> >>> 16:34 in  
> Nachricht <20200928153422.6bf6e...@acer-suse.lan>:
> > On Mon, 28 Sep 2020 14:10:38 +0200
> > Reindl Harald  wrote:  
> >> can you stop "reply‑all" and breaking threads when respond to
> >> lists?  
> > 
> > I can't answer for the reply‑all, that would annoy me as well.
> > But the thread isn't broken, my MUA is showing it nicely.  
> 
> Also: Some MUAs only have "reply" and "Reply to all"; the first one
> would only reply to the sender, and the last one would reply to list
> and sender. Interestingly for some lists a plain "Reply" works just
> right, but not for this list. Please do not assume everybody is using
> the same MUA than you do...

And, the relevance is ? ...

I can't help it if people use broken MUAs. They should either change to
a MUA that works properly, or edit the replies by hand.

And please do not send me private copies of mail to the list
If you do, I will put you in my bitbucket.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Memory in systemctl status

[Dave Howorth]

On Mon, 28 Sep 2020 16:39:05 +0200
Reindl Harald  wrote:
> Am 28.09.20 um 16:34 schrieb Dave Howorth:
> > On Mon, 28 Sep 2020 14:10:38 +0200
> > Reindl Harald  wrote:  
> >> can you stop "reply-all" and breaking threads when respond to
> >> lists?  
> > 
> > I can't answer for the reply-all, that would annoy me as well.
> > But the thread isn't broken, my MUA is showing it nicely.  
> 
> hardly when the off-list copy is faster (and contains no list-headers)
> and i need to reply-all and manually only keep the list because my
> "reply-list" button is gone
> 
> the far slower copy from the list-server is silently purged by
> intention to avoid receive ever ymessage twice on mailing lists where
> people can't handle a MUA

Well then, it's not Benjamin breaking the threading, it's you :P
You need to rewrite your processing rules to prefer the list copy.
Assuming Tbird is capable; else change your MUA.

> anyways, i am more shocked that the only people replyign don#t
> understand the simle fact that "Memory: 500 MB / 8.5 GB (with caches)"
> would make sense but not "Memory: 8.5 GB" as the only RAM dependent
> output ___
> 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] Memory in systemctl status

[Dave Howorth]

On Mon, 28 Sep 2020 14:10:38 +0200
Reindl Harald  wrote:
> can you stop "reply-all" and breaking threads when respond to lists?

I can't answer for the reply-all, that would annoy me as well.
But the thread isn't broken, my MUA is showing it nicely.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald on a system without real-time clock

[Dave Howorth]

On Mon, 21 Sep 2020 10:16:38 +0200
Magnus Berglund  wrote:
> Hello,
> 
> I have an embedded system that does not have a real-time clock. I was
> hoping to run journald on it, but have run into some problems.
> 
> My problem is that my system currently does not guarantee a
> monotonically increasing time, and that seems to confuse journald a
> bit.
> 
> Btw: I've tested this on v243-stable.
> 
> (The system syncs over NTP, but there are some issues with this as
> well, more on that later)
> 
> I originally found the problem since there were boots missing. E.g)
> 
> # journalctl --list-boots
> -4 44cabeed86e34d09a4eca0dbff43b19f Mon 2020-08-03 14:27:59 UTC—Tue
> 2020-09-15 09:13:52 UTC
> -3 71164e7d83a9448c9e70bb59b6190a45 Tue 2020-09-15 09:13:52 UTC—Tue
> 2020-09-15 09:14:48 UTC
> -2 2e565a1c8dc84d4e95055e4cb4d0cc25 Tue 2020-09-15 09:14:48 UTC—Tue
> 2020-09-15 09:16:11 UTC
> -1 3c672d6fb8084f5fa5923a1ae5e0e53d Tue 2020-09-15 09:16:11 UTC—Tue
> 2020-09-15 09:31:52 UTC
>  0 afc0d98f275e4999aa061c7bb61b85d2 Tue 2020-09-15 09:33:35 UTC—Tue
> 2020-09-15 09:56:12 UTC
> 
> # journalctl -F _BOOT_ID
> 44cabeed86e34d09a4eca0dbff43b19f
> 71164e7d83a9448c9e70bb59b6190a45
> 1465a36c753f43df92bcc0a76d8e763e
> 2e565a1c8dc84d4e95055e4cb4d0cc25
> 3c672d6fb8084f5fa5923a1ae5e0e53d
> afc0d98f275e4999aa061c7bb61b85d2
> 302cc41b146c4b3c88f06df102913c3f
> 
> I've poked around in the source code think I found the reason for
> this: journal_file_compare_locations() (in journal-file.c) compares
> seqnum if within the the same seqnum_id, but uses current_realtime if
> not within the same seqnum_id. Since my realtime can't be trusted I
> sometimes have journalfiles within the same seqnum_id which "jumps"
> back in time. That combined with the traversal in real_journal_next()
> gives a stochastic behaviour.
> 
> I have tried fixing my clock to give a monotonically increasing
> clock. But: I want my system to boot as fast as possible, even without
> a NTP-syncronized time. And I've noticed that if I shutdown before
> getting a NTP time timesyncd will not have touched the "clock" file,
> and I end up in the situation above.
> 
> Now to my question: What is the best practice in using journald on
> systems without RTC? It it even "supported"?
> 
> /Regards,
> Magnus Berglund

There was recently a long thread about some of these issues, but
specifically as they apply to Raspberry Pis. I think it's worth reading
as a first step, though. The thread starts at

https://lists.freedesktop.org/archives/systemd-devel/2020-August/045118.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal message timestamps

[Dave Howorth]

On Tue, 8 Sep 2020 07:18:15 -0400
"Kevin P. Fleming"  wrote:
> On Tue, Sep 8, 2020 at 7:12 AM Reindl Harald 
> wrote:
> 
> > your playground is in
> > /etc/systemd/system/fake-hwclock.service.d/myoverrides.conf
> >
> > and yes that is important so that you don#t have to redo your
> > changes after each and every update and way better than cloning the
> > whole unit-file in /etc/systemd/system/ so that reasonable upstream
> > changes get applied in teh future
> >
> > -
> >
> > /etc/systemd/system/fake-hwclock.service.d/myoverrides.conf:
> >
> > [Unit]
> > Before=systemd-journald.service  
> 
> ... and this is most easily done by using 'systemctl edit
> fake-hwclock.service', which will create the file in the proper
> location so you don't have to (and will handily cause a daemon reload
> as well).

Hi Mark, Reindl, Kevin, et al,

I have added

[Unit]
Before=systemd-journald.service

to a drop-in file in /etc/systemd/system/fake-hwclock.service.d/ so
hopefully it will get tested next time the machines reboot (they're
production data loggers so I don't want to reboot unnecessarily).

I had appreciated it should be done via an override file but thanks for
the warning. I'd forgotten about the edit command so I had done it the
hard way :) I don't think a daemon reload is necessary in this case,
since it only affects matters on the next and subsequent boots anyway.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal message timestamps

[Dave Howorth]

On Fri, 4 Sep 2020 17:59:02 +0200
Lennart Poettering  wrote:
> On Do, 27.08.20 11:33, Mark Corbin (m...@dibsco.co.uk) wrote:
> 
> > Hello
> >
> > I am working on time synchronisation issues at boot for systems
> > without an RTC (using balenaOS on a Raspberry Pi 3) and have some
> > questions about how journald assigns timestamps to log messages.
> >
> > When I boot my system and look at the journal I see an initial
> > date/time for kernel messages, e.g. '1 June 2020 10:00:00' followed
> > by messages with the 'correct' date/time once the system time has
> > been set from another source, e.g. build time, NTP, etc. This means
> > that over several reboots I have lots of sets of log messages from
> > 1 June 2020 which understandably confuses the 'journalctl
> > --list-boots' command. I found an issue that describes the problem
> > here https://github.com/systemd/systemd/issues/662 and had assumed
> > that there wasn't anything I could do about this.
> >
> > However, when running some tests on a board with Raspberry Pi OS I
> > found that it didn't suffer from the same problem. RPI OS uses a
> > 'fake-hwclock' service to restore the previous boot time from a
> > file and this time gets applied to all messages in the journal
> > prior to this point. I added the 'fake-hwclock' service to my
> > system which resulted in the timestamps being correct the majority
> > of the time, but I was still seeing some boots where the initial
> > messages were showing '1 June 2020'. I eventually tracked the
> > intermittent behaviour down to whether the 'fake-hwclock' time
> > setting occurred in the same system log file as the initial kernel
> > boot messages. On my RPI OS board the runtime journal was set to
> > 8MB, so the date/time setting always occurred in the first journal
> > file. On my system the runtime journal was set to 4MB, so the
> > date/time setting was sometimes happening in the second journal
> > file leaving the messages in the first file with a date of '1 June
> > 2020'.
> >
> > So my questions are...
> >
> > It seems that journald is using the date/time from the
> > 'fake-hwclock' service to update the timestamps of earlier log
> > messages within the same file. Is this correct?  
> 
> No. We do not retroactively change written out records.
> 
> However, when comparing log entries we prefer the record sequence
> number if two records come from the same system. And if that doesn't
> work, then we prefer monotonic clocks if two records cme from the same
> boot. Wallclock is only used for comparing two records if they are
> from different boots altogether.
> 
> > What would be the best technique for ensuring that my journal logs
> > always display the 'best' time for log messages (either
> > 'fake-hwclock' or NTP)? Do I always have to ensure that the journal
> > is large enough to capture my initial time setting event in the
> > first file?  
> 
> There's no nice answer for that. We do not patch written out journal
> records once they are written. They are considered immutable. This
> means, from the journal's PoV if you generated a bunch of records in
> the initrd or early boot (i.e. before /var/log/journal is available)
> and you have no usable wallclock time, and you power cycle 10 times
> in a row, then we have no indication about which of the 10 series of
> recrods came in which order before the others.
> 
> To fix that we'd have to keep a separate log of boot ids or so
> somewhere, which we could use as auxiliary source of truth if all we
> have are bootids+monotonic time which came first by comparing boot
> ids. But that would still not be perfect since we could write that out
> only late (i.e. after /var becomes writable), so the order before that
> could not be reconstructed either if the system doesn't get that far.
> 
> Also see:
> 
> https://github.com/systemd/systemd/issues/662
> 
> > Any general details about how journald applies timestamps would
> > also be greatly appreciated.  
> 
> (btw, systemd-timesyncd does what fake-hwclock does automatically, and
> also does SNTP. it should be fine for most usecases, no need to resort
> to fake-hwclock)
> 
> Lennart

This is a serious problem for anybody running a raspberry pi (i.e.
many, many thousands of people.) I suggest buying one for yourself and
actually experiencing the issues to understand what the problem is and
why people would like to see a solution.

I'll send you the dollars if that's really a problem.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using timedatectl on a readonly rootfile system using mender

[Dave Howorth]

On Fri, 4 Sep 2020 21:32:19 +0200
Lennart Poettering  wrote:
> On Fr, 04.09.20 14:10, Shravan Singh (shra...@bluesparq.com) wrote:
> 
> > Hello Lennart,
> >
> > Can you help me in understanding why this push was rejected?
> > *Make timedatectl nicely work with read-only filesystems #8277 *  
> 
> The explanation is in the PR comments.

Would either of you care to provide a link to the actual text you're
referring to, for people reading who are not intimately associated with
the code?

I can see why read-only rootfs might be desirable, and in an age of
mobile computing I can see why mutable timezones might also be
desirable.

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

Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

[Dave Howorth]

On Fri, 4 Sep 2020 17:44:23 +0200
Lennart Poettering  wrote:
> On Fr, 04.09.20 17:10, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
> > > No, that's not supported in sd-boot. A boot loader is a boot
> > > loader, it should contain a fragile storage stack. It's kinda
> > > what sd-boot is supposed to do better than grub.  
> >
> > well, a boot loader should just *load* and not write anything so
> > RAID1 is technically no problem and it shouldn't matter which of
> > the 1, 2, 3 or 4 disks is there unless one survived.  
> 
> Robust boot loaders typically want to write boot counters to disk, so
> that they can automatically revert back to older versions of the
> OS/kernel if it doesn't boot. Thus some form of write access is
> necessary if you care about robustness.

But surely a boot loader of all things should never try to write to the
place it is loading from? Booting should be idempotent (as long as it
works, for sure). The only sane policy would seem to be that the loader
had another path to a separate writable area?

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

Re: [systemd-devel] systemd unit timer

[Dave Howorth]

On Mon, 10 Aug 2020 20:21:51 +0200
Lennart Poettering  wrote:
> On So, 09.08.20 15:56, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> > Is there anywhere that explains the rationale for systemd timers?  
> 
> Probably somewhere in the git logs.

Thanks, Lennart. I'll happily poke through the logs to try to find it,
but I've no idea where to start. A starting point URL for the logs would
be helpful to me.
 
> > What's their USP? Why was it necessary to invent the facility?  
> 
> It kinda makes sense to invoke cronjobs the same way as any other
> piece of system code in userspace: as a service, so that you can take
> benefit of deps management, priv handling, logging, sandboxing and so
> on, so that you can run stuff either manually or by timers or by any
> other kind of activation, and so on, and it always ends up in exactly
> one instance. And there's tons of other stuff too.
> 
> i.e. it unifies how system programs are invoked, and that's a good
> thing. it turns time-based activation into "just another type of
> activation".

Most of that has gone over my head so some examples would probably help
me to understand. Perhaps they're in the git logs?

But I'm not normally running system code in cronjobs. I usually run
either scripts I have written myself, or backup commands and the like.

If I wanted to run a service, presumably I could just write a 'manual'
invocation as a cron or at job? I'm not seeing the big imperative to
create another new bunch of code to learn and maintain. I expect I'm
blind.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd unit timer

[Dave Howorth]

Sorry Jérémy ROSEN had munged the headers so a reply went only to
him :( :(

Here's a copy for the list.


Begin forwarded message:

Date: Sun, 9 Aug 2020 20:16:19 +0100
From: Dave Howorth 
To: Jérémy ROSEN 
Subject: Re: [systemd-devel] systemd unit timer


On Sun, 9 Aug 2020 18:42:36 +0200
Jérémy ROSEN  wrote:
> You could create a timer that starts another timer...  

Sorry, are you answering my question? (Top-posting makes it difficult
to understand without context)

If so, why might I want to do that and why couldn't I do it using cron?

If you're answering the OP's question then perhaps make that clear, but
again why couldn't that be done using cron?

Why invent yet another mechanism?

> Le dim. 9 août 2020 à 16:56, Dave Howorth  a
> écrit :
>   
> > On Sun, 9 Aug 2020 15:54:55 +0300
> > Andrei Borzenkov  wrote:
> > > 09.08.2020 13:40, Vini Harimoorthy пишет:
> > > > In that case, it will run only in Oct,Nov, & Dec. But, I want to
> > > > run the timer unit weekly after a specific calendar date & time.
> > > > How to specify if I want to run some task on every 12 hours
> > > > after Jan'2021 (start from future date & time)
> > > >
> > >
> > > That's not possible using systemd timer as of now. There was
> > > similar discussion just recently (a week or two ago).
> >
> > Is there anywhere that explains the rationale for systemd timers?
> >
> > What's their USP? Why was it necessary to invent the facility?
> > ___
> > 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] systemd unit timer

[Dave Howorth]

On Sun, 9 Aug 2020 15:54:55 +0300
Andrei Borzenkov  wrote:
> 09.08.2020 13:40, Vini Harimoorthy пишет:
> > In that case, it will run only in Oct,Nov, & Dec. But, I want to
> > run the timer unit weekly after a specific calendar date & time.
> > How to specify if I want to run some task on every 12 hours after
> > Jan'2021 (start from future date & time)
> >   
> 
> That's not possible using systemd timer as of now. There was similar
> discussion just recently (a week or two ago).

Is there anywhere that explains the rationale for systemd timers?

What's their USP? Why was it necessary to invent the facility?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: vt220 default for serial console still relevant?

[Dave Howorth]

On Tue, 21 Jul 2020 11:44:08 +0200
"Ulrich Windl"  wrote:
> >>> Lennart Poettering  schrieb am 21.07.2020
> >>> um 09:09  
> in
> Nachricht <20200721070910.GB187495@gardel-login>:
> > On Mo, 20.07.20 10:13, Bruce A. Johnson
> > (bjohn...@blueridgenetworks.com) wrote:
> >   
> >> Reading this discussion about VT220, I'm wondering why that was the
> >> choice and not VT100 (which was also monochrome). And I'm
> >> straining my memory to recall what it was that we had back then
> >> that made the VT100 seem so slick and futuristic.  
> > 
> > Our default used to be vt100 originally, but that can't do
> > pgup/pgdown, which people found quite annyoing. vt220 adds support
> > for that, and is apparently as widely supported, so we changed to
> > that.  
> 
> If you view images of a vt100, it's simply because vt100 had no
> PgUp/PgDown key ;-)
> So I cannot send the sequence.

It appears they may have been introduced in 1986:
http://xahlee.info/kbd/keyboard_page_key.html

and they may be disappearing again now !!! ;)

> (when I was a student we weren't allowed to use vi, because CBREAK
> mode would create an IRQ for every key pressed, and that was
> considered to be too much load for the system... Only after 6pm, so
> we came late just to be able to try vi...)
> 
> > 
> > Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ensuring that a unit starts before any networking

[Dave Howorth]

On Sat, 27 Jun 2020 11:42:00 +0100
Mark Rogers  wrote:
> On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > You should use Before=network-pre.target,
> > Wants=network-pre.target.  
> 
> Thanks, tried that but still not working:
> 
> $ journalctl -b | grep -Ei '(db2config|dhcpcd)'
> Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all
> interfaces... Feb 14 10:12:03 localhost dhcpcd[341]: read_config:
> fopen `/etc/dhcpcd.conf': No such file or directory
> [...]
> Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf
> does not exist
> [...]
> Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen
> `/etc/dhcpcd.conf': No such file or directory
> [...]
> Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router
> Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease
> Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config
> Creating /tmp/sys//etc/dhcpcd.conf
> Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config
> Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf
> 
> (Comments about that extract: the jump from Feb to Jun I assume is the
> clock getting updated from RTC, it's all from the same boot obviously;

A Pi doesn't normally have an RTC, so the mixup usually takes place
when the time is updated via NTP I believe. Do you have an RTC?

> also note my db2config script doesn't run until after hostname is set
> which I would assume is set by the network startup?)

Well that depends how you've set the Pi up, so you tell us, don't
assume. If your script doesn't start until hostname is set and hostname
is set by dhcp then you have a fundamental problem.

> Unit file is currently:
> 
> [Unit]
> Description=Config generation from DB
> Before=network-pre.target
> Wants=network-pre.target
> 
> [Service]
> Type=oneshot
> ExecStart=/home/mark/bin/db2config.py
> 
> [Install]
> RequiredBy=network.target
> 
> After any changes I'm using
> $ sudo systemctl daemon-reload
> $ sudo systemctl reenable db2config.service
> 
> ... although that's another area I'm not entirely clear about what
> exactly is required after a unit file change.
> 
> PS: Is list etiquette around here to CC on reply? Some love it, some
> hate it, others don't care...
> 
> 
> --
> Mark Rogers
> ___
> 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] Some issues about compiling systemd on linux

[Dave Howorth]

On Thu, 28 May 2020 17:35:05 +0800
"黄桂丰" <670915...@qq.com> wrote:
> Hello ,
> 
>   I have a project that needs to use the journald
> module in systemd. My initial idea was to compile journald
> separately, but then I found that this would not work.
> 
>   So I started to try to compile systemd, but I
> encountered many problems during the compilation process, and now I
> have been unable to solve this problem.   
> 
> 
>  How can I solve this problem?
> 
>   My ultimate goal is to run the journald module on ARM.
> I can transplant the systemd. Of course, it is better to be able to
> compile the journald separately. But I don't know how to
> cross-compile systemd yet, can you give me some help?  
> 
>   I look forward to receiving your reply！

You don't say what distro you are using (or where else you got linux)
nor what version of systemd you are using. 

journald and journalctl etc are normally included with systemd. They
are for example with Raspbian, which is an ARM version of Debian.

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

Re: [systemd-devel] --Reboot-- lines in journal

[Dave Howorth]

On Thu, 14 May 2020 16:12:49 +0300
Mantas Mikulėnas  wrote:
> On Thu, May 14, 2020 at 3:55 PM Dave Howorth 
> wrote:
> 
> > What do --Reboot-- lines in the journal mean and how do they get
> > there?
> >
> > I can't find any explanation on
> > https://www.freedesktop.org/software/systemd/man/journalctl.html or
> > related pages I've tried.
> >
> > I should explain why I'm interested. On my openSUSE box, I can see
> > for example:
> >
> > # journalctl --list-boots
> > -1 3c9ab70ade084dfab277efe733e18949 Mon 2020-03-02 23:44:11 GMT—Sun
> > 2020-03-29 08:54:38 BST
> >  0 c56183ea7877444a8252dd89a32b31f3 Sun 2020-03-29 09:15:30 BST—Thu
> > 2020-05-14 13:16:49 BST
> > # journalctl | grep Reboot
> > -- Reboot --
> > #
> >
> > Which looks fairly sane with what I think I should expect. But on
> > two Raspberry pis that I have with persistent logging enabled they
> > both have a huge excess of --Reboot-- lines. For example:
> >
> > $ sudo journalctl --list-boots
> > -3 a9346655ca5d4700ab470bfd1b94d5da Thu 2019-02-14 10:11:59 GMT—Wed
> > 2020-05-13 18:31:22 BST
> > -2 c4f8ab5ec73b40818b1607b3436b90b5 Wed 2020-05-13 18:32:51 BST—Wed
> > 2020-05-13 18:46:29 BST
> > -1 0af9c854355f4a12a64dd00e6d3d98c1 Wed 2020-05-13 19:32:57 BST—Wed
> > 2020-05-13 22:33:24 BST
> >  0 fc5b35dbb3604dfbb4e2cdc99e117a75 Wed 2020-05-13 22:33:24 BST—Thu
> > 2020-05-14 12:46:07 BST
> > $ sudo journalctl | grep Reboot | wc
> >16675047   22095
> > $
> >
> > What do the apparently excess 1664 --Reboot-- messages mean?
> >  
> 
> The "--Reboot--" line is simply shown every time the _BOOT_ID field
> changes between two entries -- even if it changes to a previously
> seen boot ID (which shouldn't happen normally, but *might* be caused
> by lack of a RTC?).
> 
> Meanwhile --list-boots has a bit more complex logic for discovering
> the boots, and it also stops the search completely if it finds a boot
> ID that it has already seen.
> 
> (What do you get from, let's say, `journalctl -o json | jq -r
> "._BOOT_ID" | uniq -c`? Does it show several distinct ranges for each
> boot ID?)

Thanks for the reply. A lot of lines similar to this (from start):

  2 4449e609d5144646b1bf70028bf8f1d0
 59 bc489744282a46ffbc28fd31de4c6aa9
 62 3164d610039145b4a1f7bc964eaaa85b
450 a9346655ca5d4700ab470bfd1b94d5da
  1 4449e609d5144646b1bf70028bf8f1d0
 27 4e807f1301de45dfb4e13551ae10a287
  1 bc489744282a46ffbc28fd31de4c6aa9
  2 4e807f1301de45dfb4e13551ae10a287
  1 4449e609d5144646b1bf70028bf8f1d0
  2 4e807f1301de45dfb4e13551ae10a287

I've attached the complete list, FWIW

I've never even heard of a _BOOT_ID before, so it seems I'll need to do
some reading to answer my original questions. Where's a good place to
start?

> -- 
> Mantas Mikulėnas


boot.file
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] --Reboot-- lines in journal

[Dave Howorth]

What do --Reboot-- lines in the journal mean and how do they get there?

I can't find any explanation on
https://www.freedesktop.org/software/systemd/man/journalctl.html or
related pages I've tried.

I should explain why I'm interested. On my openSUSE box, I can see for
example:

# journalctl --list-boots
-1 3c9ab70ade084dfab277efe733e18949 Mon 2020-03-02 23:44:11 GMT—Sun 2020-03-29 
08:54:38 BST
 0 c56183ea7877444a8252dd89a32b31f3 Sun 2020-03-29 09:15:30 BST—Thu 2020-05-14 
13:16:49 BST
# journalctl | grep Reboot
-- Reboot --
# 

Which looks fairly sane with what I think I should expect. But on two
Raspberry pis that I have with persistent logging enabled they both
have a huge excess of --Reboot-- lines. For example:

$ sudo journalctl --list-boots
-3 a9346655ca5d4700ab470bfd1b94d5da Thu 2019-02-14 10:11:59 GMT—Wed 2020-05-13 
18:31:22 BST
-2 c4f8ab5ec73b40818b1607b3436b90b5 Wed 2020-05-13 18:32:51 BST—Wed 2020-05-13 
18:46:29 BST
-1 0af9c854355f4a12a64dd00e6d3d98c1 Wed 2020-05-13 19:32:57 BST—Wed 2020-05-13 
22:33:24 BST
 0 fc5b35dbb3604dfbb4e2cdc99e117a75 Wed 2020-05-13 22:33:24 BST—Thu 2020-05-14 
12:46:07 BST
$ sudo journalctl | grep Reboot | wc
   16675047   22095
$

What do the apparently excess 1664 --Reboot-- messages mean?

I can post more journal content if required.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] your are happier but without become static some service I can't loggin by console-getty et getty@tty1 services

[Dave Howorth]

I'm not sure why Lennart hasn't stepped in to moderate yet, but this
discussion is going in my bit bucket.

On Tue, 7 Apr 2020 22:03:25 +
Dorian ROSSE  wrote:
> I explain again the problem juice
> 
> I can't use my monitor foe edit script
> 
> Because console-getty et getty@tty1 service are disabled,
> 
> I can start but I want both service become static,
> 
> How to become both service as static ?
> 
> Envoyé d’Outlook Mobile
> 
> From: Dorian ROSSE
> Sent: Tuesday, April 7, 2020 7:47:53 PM
> To: systemd-devel@lists.freedesktop.org
>  Subject: your are happier but
> without become static some service I can't loggin by console-getty et
> getty@tty1 services
> 
> Hello,
> 
> 
> your are happier but without become static some service I can't
> loggin by console-getty et getty@tty1 services on my monitor...
> 
> I have tried too ssh access but ssh mailing list has never answer my
> e-mail...
> 
> thank you in advance to help me become static some services,
> 
> Regards.
> 
> 
> Dorian ROSSE.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] making journald logs persistent on raspberry pi

[Dave Howorth]

On Tue, 31 Mar 2020 14:48:48 +0200
Lennart Poettering  wrote:
> On Fr, 24.01.20 15:32, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> > It's quite common on the Raspberry Pi to make /var/log a tmpfs, in
> > order to reduce the number of writes to the SD card that is the pi's
> > main storage. That's quite acceptable for most logs but I'd like to
> > make journald's logs persistent so I'll be able to investigate any
> > problems that occur whilst booting or shutting down more easily.  
> 
> Hmm, if you want volatile logging, use /run/log/...

I suppose you have some time now to revisit this old thread :)
But thanks for answering.
 
> It sounds strange to me, first making /var/log/... volatile, which is
> kinda where the stuff goes that is supposed to be persistent and then
> tryng to exclude stuff there again...

The problem is that almost all existing systems, services, whatever
send their logs by default to /var/log and each may or may not have a
different mechanism to redirect their logs to /run/log/. Plus each
individual user's machines may have a variety of different software
installed.

So if one wants a general means to guarantee reducing writes to the SD
card, it's easier to change how /var/log is stored than to provide a
facility that changes the log locations of every application on every
person's machine, where one doesn't even know what all those
applications are.

> i.e. journald's Storage= setting most just allows you to choose
> between /var/log/… and /run/log/… as data store.

Indeed, but that doesn't help in this scenario. Fortunately Mantas
provided a nice answer back in January :)

Cheers, Dave

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

Re: [systemd-devel] Cannot find a way to get time read from RTC during boot

[Dave Howorth]

On Thu, 12 Mar 2020 17:35:16 -0400
"Kevin P. Fleming"  wrote:
> Thanks, I agree. I could some up with something which ran timedatectl
> to set the system time from the RTC, but the hwclock tool is already
> there for that purpose.
> 
> I'll need to investigate why this script exits without making any
> changes when systemd is running; either the authors expected some part
> of systemd to read the RTC, or they expect some other service/tool to
> do it.
> 
> On Thu, Mar 12, 2020 at 2:02 PM Mike Gilbert 
> wrote:
> >
> > On Thu, Mar 12, 2020 at 7:13 AM Kevin P. Fleming 
> > wrote:  
> > > Prior to systemd, with the 'hwclock' package installed, a udev
> > > rule would trigger reading of the RTC and setting the system
> > > clock when /dev/rtc0 appeared. With systemd running, the script
> > > run by that udev rule is suppressed, it doesn't do anything.
> > >
> > > With a system using solely systemd-provided services, what's the
> > > proper mechanism to get the time read from an RTC whose driver is
> > > loaded by systemd-modules-load.service?  
> >
> > Your use case is likely not covered by "systemd-provided" services.
> >
> > I think your best bet would be to "un-supress" that hwclock udev
> > rule.  

I'm not sure but you might be interested to read
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] detect_container() for recent(?) docker

[Dave Howorth]

On Tue, 28 Jan 2020 15:28:08 +0300
"Matwey V. Kornilov"  wrote:
> вт, 28 янв. 2020 г. в 15:25, Lennart Poettering
> :

> > We document the requirements and expectations to run systemd in
> > containers very explicitly here:
> >
> > https://systemd.io/CONTAINER_INTERFACE  
> 
> If I could google this page, it would save lot of my time. Thanks a
> lot!

The order of hits in google is google's choice, of course, and not
systemd. Having said that, when I google for 'systemd container
interface' (without the quotes), the first hit is
https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
and the first thing that says is 'This page moved to
https://systemd.io/CONTAINER_INTERFACE '
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] making journald logs persistent on raspberry pi

[Dave Howorth]

On Fri, 24 Jan 2020 18:36:49 +0200
Mantas Mikulėnas  wrote:
> On Fri, Jan 24, 2020 at 5:32 PM Dave Howorth 
> wrote:
> 
> > It's quite common on the Raspberry Pi to make /var/log a tmpfs, in
> > order to reduce the number of writes to the SD card that is the pi's
> > main storage. That's quite acceptable for most logs but I'd like to
> > make journald's logs persistent so I'll be able to investigate any
> > problems that occur whilst booting or shutting down more easily.
> >
> > My first thought was to configure journald to write the log
> > somewhere else, but it seems there's no possibility to do that?
> > (why not?)
> >
> > So I think I will need to create /var/log/journal as a symlink to a
> > directory in a permanent filesystem. The symlink needs to be created
> > after the tmpfs is created but before journald starts (or else
> > journald will need to be told to notice the change).
> >
> > My systemd foo isn't up to that and a web search hasn't found an
> > answer. What's the best way to do it please?
> >  
> 
> Mount --bind a persistent directory on top of /var/log/journal, using
> the same method that you currently use for mounting the tmpfs.

Many thanks for that. Obvious with the benefit of hindsight, but wasn't
to me at the time:)

I've come to realize that an equally interesting question is where to
put the logs? Somewhere under /var/lib seems closest but FHS 3
specifically says; "This hierarchy holds state information pertaining
to an application or the system. ... should not be logging output ...".
Does anybody here have any thoughts? I'll ask on the fhs list as well.

Thanks, Dave

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

[systemd-devel] making journald logs persistent on raspberry pi

[Dave Howorth]

It's quite common on the Raspberry Pi to make /var/log a tmpfs, in
order to reduce the number of writes to the SD card that is the pi's
main storage. That's quite acceptable for most logs but I'd like to
make journald's logs persistent so I'll be able to investigate any
problems that occur whilst booting or shutting down more easily.

My first thought was to configure journald to write the log somewhere
else, but it seems there's no possibility to do that? (why not?)

So I think I will need to create /var/log/journal as a symlink to a
directory in a permanent filesystem. The symlink needs to be created
after the tmpfs is created but before journald starts (or else journald
will need to be told to notice the change).

My systemd foo isn't up to that and a web search hasn't found an answer.
What's the best way to do it please?

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

Re: [systemd-devel] Shutdown behavior

[Dave Howorth]

On Mon, 13 Jan 2020 11:32:37 +0100
Lennart Poettering  wrote:
> On Fr, 10.01.20 10:56, Jay Burger (jay.bur...@us.fujitsu.com) wrote:
> 
> > I made the same type of change in the emergency_action() function
> > in v232.
> >
> > Question 1: Would this be considered a problem with the design,
> > needing an upstream fix? Or would this be considered a particular
> > user issue, to be fixed with an isolated patch, like we have done?
> > If the latter is the answer to this then would
> > this be considered a legit fix for our purposes? Or is there a
> > better way to handle this use case? I know fixing my user services
> > to not fail on the shutdown would be preferable, but pulling teeth
> > is not in my skillset.  
> 
> Hmm, so what is the expected behaviour here? If one service requires a
> reboot and another a poweroff, and one is triggered first and the
> other second, then I can at least think of four policies that make
> sense:
> 
> 1. first requested always wins
> 
> 2. last requested always wins
> 
> 3. reboot is the positive outlook, and thus always wins
> 
> 4. poweorff is the positive outlook, and thus always wins.
> 
> Unless I am mistaken we currently implement policy 2. Which one would
> you prefer? Can you make a good case why it would be better in the
> general case?
> 
> I have the suspicion we should just adopt the best possible policy
> here and stick to it and not make things needlessly configurable. But
> it's a matter of discussion which one that is...

Surely this is application-dependent? I can conceive of applications
that require reboot (or at least best efforts at it), and others that
require shutdown.

For the first, consider a system controlling something dangerous. If
the system is forced down by some watchdog, it most likely should
reboot and try again.

For the second, consider a system whose power is supplied via a UPS and
has just been informed the UPS is about to run out of power. Whatever
it does, it's going down and its best policy is likely to
shutdown/hibernate such that it can restart when power returns.

Is there not a case to at least provide a hook so that some
application-specific code can make the decision?

But certainly, I think that a service failing during shutdown should
not affect the outcome of that shutdown. Having some broken service
decide whether or not I can shut my machine down is ridiculous.

> > Question 2: I recently found a case where a poweroff shutdown was
> > triggered while the system was in the "starting" state and a
> > service failure occurred during the shutdown. In this case my logic
> > change did not prevent the shutdown from changing to a reboot. This
> > check of the manager_state found the state was still "starting" and
> > the poweroff was again changed to a reboot. Is there a different
> > logic path taken when in the starting state as opposed to the
> > running state?  
> 
> Not really, no.
> 
> 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] Service fails to start with no log messages

[Dave Howorth]

On Mon, 6 Jan 2020 21:47:37 -0500
Jeffrey Walton  wrote:
> On Mon, Jan 6, 2020 at 9:35 PM Reindl Harald 
> wrote:
> >
> > Am 07.01.20 um 02:57 schrieb Jeffrey Walton:  
> > > To fix my ordering problem I need Systemd to stop lying about
> > > when the network is ready.  
> >
> > one last comment:
> >
> > whatever crap you did ending in the ordering cycle did not solve
> > your wrong ordering after network, it just burried it by slow down
> > something else and so by luck
> >
> > systemd does not lie here - you just need to do the ordering proper
> > based on how your network is configured at all which you refuse to
> > tell
> >
> > so your better options would have been report thate network ordering
> > problem here before touch anything else
> >
> > "There are absolutely 0 entires about my monitor service" is because
> > it's thrown out of the startup transaction cause dby your other
> > config screwup  
> 
> And there we have it. Systemd is not logging the problem. And then you
> wonder why users like me go down rabbit holes.
> 
> Perhaps Systemd should hire someone who understands usability and
> design. Maybe they can explain why throwing important information away
> is a bad idea.
> 
> Jeff

I can't tell whether you're deliberately trolling Reindl, which helps
nobody and certainly doesn't help solve your problem, or whether you
simply have a lot of prejudice about systemd that you're keen to talk
about. Either way, it's counterproductive; please stop it. Just write
about your technical issues.

I'd suggest you start again, and try to post complete information - such
as you have - about your services and problems with them. But first
please reread all Reindl and Paul's comments and try to apply the
useful information that is contained within them.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

[Dave Howorth]

On Mon, 14 Oct 2019 16:27:47 +0200
Jonas Meurer  wrote:
> Yeah, something like that was my hope as well: use plymouth and
> framebuffer or something alike for spawning the passphrase prompt.

FWIW, I'm just a user but I taboo plymouth on all my systems. I prefer
to see the traditional scrolling messages. So I hope the mechanism
would fall back to a simple password prompt.

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

Re: [systemd-devel] Bad accelerometer values cause incorrect screen rotation

[Dave Howorth]

On Thu, 5 Sep 2019 17:05:11 +0800
Daniel Drake  wrote:
> Hi,
> 
> Over the years we've seen a bunch of reports of systems that
> automatically rotate the display to some incorrect orientation, based
> on trusting some accelerometer data values which were not interpreted
> correctly. I have another affected system in hand here.
> 
> When this unfortunate situation happens, the user experience is really
> terrible. Except for workarounds that involve going to the command
> line, the best workaround under GNOME seems to be to physically rotate
> the device into a position that causes the screen orientation to be
> normal/unrotated, then while maintaining and holding the device in
> that highly awkward position with one hand, try your very best to
> manipulate the mouse cursor with your other hand and navigate the menu
> to enable Orientation Lock.
> 
> Since the effects of this issue when it bites are so bad, and because
> it seems like we aren't winning the "quirk the accelerometer" game
> here, I'm wondering if it's time for us to restrict this default
> setting of automatic rotation based on accelerometer data to only
> situations where:
>  1. The product is actually designed to be usable when rotated, and
>  2. We have a higher degree of confidence that we're actually
> interpreting the accelerometer data correctly
> 
> 
> Why are we not winning? Why can't we fix this properly?
> 
> I think we're suffering largely through applying this auto-rotation
> behaviour to all accelerometer data, from setups where previously
> nobody really cared if the data was misinterpreted, or the data was
> specifically interpreted for a different context (we're specifically
> interested in measuring the physical orientation of the screen, but
> accelerometers have other uses too).
> 
> Windows 10 (and presumably 8) does have the automatic screen rotation
> feature based on accelerometer data, but it seems to apply to fewer
> products. For example it does not apply automatic rotation to the
> Quanta NL3 classmate nor to the HP EliteBook 840 G3, two systems that
> I have in hand that both required specific engineering on Linux after
> real users had already run into the horrible
> automatic-incorrect-rotation described above:
> https://github.com/systemd/systemd/commit/ebf482e7cdabfc1266a86ec8a5f92a964ce08afe
> hp_accel: fix accelerometer orientation for EliteBook 840 (patch
> posted today, no link yet)
> 
> The challenge here is a lack of standardization of how accelerometers
> are installed relative to the screen, and a lack of a standard way of
> accessing model-specific data that gives us this info. Without any
> better options we've been trying to create and maintain our own
> databases, for example systemds 60-sensor.hwdb and Linux kernel's
> hp_accel.c, but that's turning out to be problematic because:
>  1. The databases entries are mostly created retroactively - usually,
> entries are created when a tech-savvy user steps forward to share the
> required data, after one or more users have already been bitten by the
> issue. This is sub-standard.
>  2. We estimate the right way to distinguish models for different
> quirks by hoping that DMI data will serve this purpose, but we also
> don't know how to do that reliably, so sometimes we even apply the
> wrong quirks. Two recent examples:
> https://bugzilla.redhat.com/show_bug.cgi?id=1717712 (more on this
> case below) hp_accel: fix accelerometer orientation for EliteBook 840
> (patch posted today, no link yet)
> 
> Bastien once made the suggestion that we could fish the model-to-quirk
> mapping from the Windows drivers, but I can't find anything in the HP
> driver. On HP EliteBook 840 the device is not even exposed as a sensor
> under Windows and I can't find any way of accessing the data or making
> it auto-rotate - maybe they don't even have such a mapping? The only
> Windows application of this sensor seems to be automatic hard disk
> head parking, which presumably just detects sudden movements in any
> direction.
> 
> We did recently work with some Acer all-in-one PCs which had an
> accelerometer which also provided working auto-rotation under windows
> out of the box, while again producing the wrong and awkward behaviour
> on Linux. Thanks to vendor contacts we did discover the scheme used,
> and now automatically detect the accelerometer orientation on such
> products.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f38ab20b749da84e3df1f8c9240ddc791b0d5983
> However, we then found DSDTs with this orientation data that far
> predated this patch's existence. So not a great win; our solution was
> not made in timely fashion.
> 
> ACPI offers something that might help - PLD can be used to describe
> the physical orientation of product components. But I don't think
> we've seen any examples of this data being provided by vendors for
> accelerometers.
> 
> I see the latest development of having the hwdb specify whether the
> accelerometer 

Re: [systemd-devel] Antw: Re: Antw: Re: /etc/fstab obsolete?

[Dave Howorth]

On Thu, 29 Aug 2019 15:57:37 +0200
Lennart Poettering  wrote:
> On Do, 29.08.19 07:46, Ulrich Windl
> (ulrich.wi...@rz.uni-regensburg.de) wrote:
> 
> > Hi!
> >
> > I agree to almost everything, except:
> >
> > The handling of /etc/fstab is a true mess. Maybe other config files
> > are handles similarly, but I haven't discovered.  For some reason
> > SLES does not set up a German keyboard in the mergency shell (just
> > to make things worse). I had opened a service request for that as
> > well.  Systemd "over-reacts" in most cases, like when being unable
> > to find some mount that root unmounted. Bringing the system to
> > emergency mode is clearly over-reacting.  
> 
> We do this for safety reasons. Please declare all your mounts as
> "nofail" and then systemd will boot up even without them being
> around. But of course things will fall apart badly then as soon as a
> device goes missing as all services will assume the file systems they
> need are there but potentially are just reading or writing to the file
> system undearneath.

There's an easy way around that. Change the permissions of the mount
directory to be very restrictive, such that whatever normally writes in
the mounted filesystem/directory can't. Then it's up to applications to
deal with read or write failures appropriately.

> "nofail" is an option that existed before systemd too, btw. It's how
> you declare that you want an /etc/fstab line not to cause failure.
> 
> > I have always been a fan of UNIX because of ist conceptual
> > simplicity, meaning it was easy to understand what's going on and
> > how things work (very much opposed to MS Windows, for example).  For
> > me systemd simply isn't UNIX.  
> 
> I can live with that.
> 
> 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 ?

[Dave Howorth]

On Wed, 14 Aug 2019 12:04:03 -0400
Brian Reichert  wrote:
> On Wed, Aug 14, 2019 at 04:19:46PM +0100, Simon McVittie wrote:
> > On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote:
> > Doesn't daemonize(1) make stdin, stdout and stderr point
> > to /dev/null, instead of closing them?  
> 
> Looking at the source, yes, it does.
> 
> > Expecting arbitrary subprocesses to cope gracefully with being
> > invoked without the three standard fds seems likely to be a losing
> > battle. I've implemented this myself, in dbus; it isn't a whole lot
> > of code, but it also isn't something that I would expect the
> > authors of all CLI tools to get right.  
> 
> I concede that reopening FD 0,1,2 is a good practice to insulate
> against the issues you cite.
> 
> I agree with your points; I code aggressively, and sometimes forget
> others don't.

I didn't know what you meant by this. Do you mean 'Aggressive
Programming'? Is
https://www.apharmony.com/software-sagacity/2014/10/principles-of-aggressive-programming/
a reasonable summary?

> > smcv
> > 
> > [1] I'm sure there are lots of other executables named daemon or
> > daemonize in other OSs, and perhaps some of them get this wrong?
> 
> -- 
> 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] Antw: /bin/systemctl vs /usr/bin/systemctl

[Dave Howorth]

On Wed, 07 Aug 2019 07:38:47 +0200
"Ulrich Windl"  wrote:
> >>> Thomas Güttler  schrieb am
> >>> 06.08.2019 um  
> 16:37 in
> Nachricht <3243dc34-4eec-e3a0-c6fd-491fdfcaf...@thomas-guettler.de>:
> > I just realized that the location of systemctl varies across linux 
> > distributions.
> > 
> > Ubuntu: /bin/systemctl
> > SuSE: /usr/bin/systemctl  
> 
> I guess it should be /sbin/systemctl ;-)

$ systemctl status 

is not a privileged command.
___
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

[Dave Howorth]

On Thu, 18 Jul 2019 09:55:51 -0600
Chris Murphy  wrote:
> 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...

I'm not a fedora user, but I don't think it's that difficult to run
strace.

To run it once, start your live image and type:

# yum install strace

You will need to reinstall it if you reboot.

To permanently install it apparently you need to configure your USB
with persistent storage. I haven't looked up how to do that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logging in RAM and journald configuration issue

[Dave Howorth]

On 2019-03-20 Lennart Poettering wrote:

> On Mi, 20.03.19 18:08, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> >
> > At present AFAICT the log2ram.service runs
> > Before=systemd-journald.service and various other services, so I
> > think that aspect is covered.  
> 
> I am not sure what this service does, but if all you want to do is
> make changes to /var/log/journal before journald writes there it
> should be sufficient to order it before systemd-journal-flush.service
> which is nowadays the clear boundary when journald starts writing to
> /var.

Sorry for the late reply, but I'm just trying to understand this
better. Is systemd-journal-flush.service documented anywhere?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logging in RAM and journald configuration issue

[Dave Howorth]

This message was caught up in what looks like a freedesktop server
crash so I'm reposting it slightly edited after other responses.
Hopefully it will now reach the list and thread somewhat sensibly.

> Lennart Poettering wrote on 20/03/2019 13:37:
> > On Mi, 20.03.19 09:57, Dave Howorth (syst...@howorth.org.uk) wrote:
> >   
> >>> On Di, 19.03.19 20:45, Dave Howorth (syst...@howorth.org.uk)
> >>> wrote: 
> >>>> In the case of a machine that uses an SD card as its primary
> >>>> backing store, it is desirable to reduce the number of write
> >>>> operations to the card in order to prolong its life. journald is
> >>>> quite well-behaved in this regard since it offers the choice of a
> >>>> temporary or permanent journal and limits the frequency of its
> >>>> writes, except in emergencies.
> >>>>
> >>>> However, its permanent journal is written under /var/log/journal
> >>>> and there is no way to configure the path as far as I am aware.
> >>>> I think this is a problem.
> >>>>
> >>>> The reason is that on this type of machine people sometimes map
> >>>>  /var/log to RAM using tmpfs and then perhaps persist the logs
> >>>> using a program like log2ram. When this is done, journald's
> >>>> emergency writing capability is lost and crash analysis becomes
> >>>> more difficult.
> >>>>
> >>>> Of course it is possible instead to redirect the log files of
> >>>> programs individually to temporary memory using systemd-tmpfiles
> >>>> wherever needed. But this involves reconfiguring each and every
> >>>> program that uses /var/log both initially and whenever new
> >>>> programs are installed. This is tedious not only in quantity but
> >>>> because each program has a different detailed format of
> >>>> configuration file.
> >>>>
> >>>> So making /var/log into a tmpfs is a more attractive option. But
> >>>> ideally the journal would be placed somewhere else in persistent
> >>>> storage so its contents are available after a crash. This does
> >>>> not seem to be possible through lack of a config option.
> >>>>
> >>>> Is my analysis correct? Are there any other ways to resolve this
> >>>> difficulty? Otherwise, is it possible to consider a log location
> >>>> config option for journald?  
> >>>
> >>> Right now, when persistent mode is enabled journald will store
> >>> its log data in /var/log. When it is disabled it will store
> >>> things in /run/log instead.
> >>>
> >>> It has been requested that we add a hybrid mode that makes
> >>> journald log to both locations at the same time, but filter by
> >>> log priority so that log msgs higher than some priority go to one
> >>> location and the ones below it go to the other. A patch like that
> >>> would probably be relatively straight-forward and short. Would be
> >>> happy to review/merge a patch for that.
> >>>
> >>> I think if that's implemented the log location should really stay
> >>> unmodified: /var should be persistant and /run not, and there
> >>> would be no need to remount any of those paths in a different
> >>> way.  
> >>
> >> Many thanks for the quick reply. I'm not clear how that resolves
> >> the situation I explained, since it neither provides an alternative
> >> persistent log location nor provides an alternative means of
> >> arranging the logs of other programs. It doesn't seem to address my
> >> issue at all?  
> > 
> > I don't understand the problem then?
> > 
> > The journal only collects logs on stdout/stderr, syslog and its
> > native protocol. Nothing else. It's not a tool that can collect
> > arbitrary per-app logs that don't go via these transport hence. And
> > it really shouldn't be.
> > 
> > Also: /var is generally understood to be persistent, and /run to be
> > volatile. If you want to redefine that you are welcome to, but of
> > course you have to patch through all kinds of software then.  
>
> As I understand it, you want /var/log to be tmpfs but /var/log/journal
> to be persistent (as journald's write behaviour is considerate enough
> for you not to worry about backing store fatigue etc)?

Yes, a very good summary.

> Just as a less complex suggestion, you're presumably bootstrapping
> /var/l

Re: [systemd-devel] logging in RAM and journald configuration issue

[Dave Howorth]

> On Di, 19.03.19 20:45, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> > In the case of a machine that uses an SD card as its primary backing
> > store, it is desirable to reduce the number of write operations to
> > the card in order to prolong its life. journald is quite
> > well-behaved in this regard since it offers the choice of a
> > temporary or permanent journal and limits the frequency of its
> > writes, except in emergencies.
> >
> > However, its permanent journal is written under /var/log/journal and
> > there is no way to configure the path as far as I am aware. I think
> > this is a problem.
> >
> > The reason is that on this type of machine people sometimes map
> >  /var/log to RAM using tmpfs and then perhaps persist the logs
> > using a program like log2ram. When this is done, journald's
> > emergency writing capability is lost and crash analysis becomes
> > more difficult.
> >
> > Of course it is possible instead to redirect the log files of
> > programs individually to temporary memory using systemd-tmpfiles
> > wherever needed. But this involves reconfiguring each and every
> > program that uses /var/log both initially and whenever new programs
> > are installed. This is tedious not only in quantity but because
> > each program has a different detailed format of configuration file.
> >
> > So making /var/log into a tmpfs is a more attractive option. But
> > ideally the journal would be placed somewhere else in persistent
> > storage so its contents are available after a crash. This does not
> > seem to be possible through lack of a config option.
> >
> > Is my analysis correct? Are there any other ways to resolve this
> > difficulty? Otherwise, is it possible to consider a log location
> > config option for journald?  
> 
> Right now, when persistent mode is enabled journald will store its log
> data in /var/log. When it is disabled it will store things in /run/log
> instead.
> 
> It has been requested that we add a hybrid mode that makes journald
> log to both locations at the same time, but filter by log priority so
> that log msgs higher than some priority go to one location and the
> ones below it go to the other. A patch like that would probably be
> relatively straight-forward and short. Would be happy to review/merge
> a patch for that.
> 
> I think if that's implemented the log location should really stay
> unmodified: /var should be persistant and /run not, and there would be
> no need to remount any of those paths in a different way.

Many thanks for the quick reply. I'm not clear how that resolves the
situation I explained, since it neither provides an alternative
persistent log location nor provides an alternative means of
arranging the logs of other programs. It doesn't seem to address my
issue at all?

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

[systemd-devel] logging in RAM and journald configuration issue

[Dave Howorth]

In the case of a machine that uses an SD card as its primary backing
store, it is desirable to reduce the number of write operations to the
card in order to prolong its life. journald is quite well-behaved in
this regard since it offers the choice of a temporary or permanent
journal and limits the frequency of its writes, except in emergencies.

However, its permanent journal is written under /var/log/journal and
there is no way to configure the path as far as I am aware. I think
this is a problem.

The reason is that on this type of machine people sometimes map
 /var/log to RAM using tmpfs and then perhaps persist the logs using a
program like log2ram. When this is done, journald's emergency writing
capability is lost and crash analysis becomes more difficult.

Of course it is possible instead to redirect the log files of programs
individually to temporary memory using systemd-tmpfiles wherever
needed. But this involves reconfiguring each and every program that
uses /var/log both initially and whenever new programs are installed.
This is tedious not only in quantity but because each program has a
different detailed format of configuration file.

So making /var/log into a tmpfs is a more attractive option. But
ideally the journal would be placed somewhere else in persistent
storage so its contents are available after a crash. This does not seem
to be possible through lack of a config option.

Is my analysis correct? Are there any other ways to resolve this
difficulty? Otherwise, is it possible to consider a log location config
option for journald?

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