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

[Michael Biebl]

Am Sa., 26. Aug. 2023 um 15:25 Uhr schrieb Andrei Borzenkov
:
>
> 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"

I was referring to the part
"Warning: some journal files were not opened due to insufficient
permissions."
of the systemctl status output.

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

[Michael Biebl]

Am Sa., 26. Aug. 2023 um 09:44 Uhr schrieb Cecil Westerhof
:
>
> I am at last implementing systemd timers. The service I created can have its 
> status queried by a normal user. I thought I must have made a mistake. But 
> when I do:
> systemctl status cron
>
> I get:
> ● cron.service - Regular background program processing daemon
>  Loaded: loaded (/lib/systemd/system/cron.service; enabled; preset: 
> enabled)
>  Active: active (running) since Sat 2023-08-19 18:12:04 CEST; 6 days 
> ago
>Docs: man:cron(8)
>Main PID: 790 (cron)
>   Tasks: 1 (limit: 17837)
>  Memory: 91.0M
> CPU: 14min 3.110s
>  CGroup: /system.slice/cron.service
>  └─790 /usr/sbin/cron -f
>
> Warning: some journal files were not opened due to insufficient 
> permissions.
>
> Is this the expected behaviour?
> If not: what could be wrong with my system?
>
> This is on Debian 11.

Reading system logs is a privileged operation.

You can grant this privilege to individual users by adding them to the
systemd-journal (or adm) group.

Adding users to the adm will grant them additional privileges, so be careful.

Re: [systemd-devel] Splitting large message written to stdout, explanation?

[Michael Biebl]

Am So., 21. Mai 2023 um 18:26 Uhr schrieb Stephen Hemminger
:
> Syslog was never really intended for large size messages. It is not Windows 
> event log.
> If you are sending large complex things then using dbus to communicate 
> directly
> is a better option.

dbus is not a suitable protocol for large amounts of data  and high
frequency of events.

Re: [systemd-devel] systemctl daemon-reexec forgets running services and starts everything new

[Michael Biebl]

Am Mo., 10. Apr. 2023 um 09:46 Uhr schrieb Mantas Mikulėnas :
>
> On Tue, Apr 4, 2023 at 11:33 AM Wasser, Erik  wrote:
>>
>> # Some details to the hardware #
>>
>> Our metal runs OpenVZ/Virtuozzo with this kernel (without any problems):
>>
>> > Linux FQDN_REDACTED 3.10.0-1127.18.2.vz7.163.46 #1 SMP Fri Nov 20 21:47:55 
>> > MSK 2020 x86_64 x86_64 x86_64 GNU/Linux
>>
>> The container with the `systemctl daemon-reexec` problem reports the
>> following kernel:
>>
>> Linux FQDN_REDACTED 5.4.0 #1 SMP Thu Apr 22 16:18:59 MSK 2021 x86_64
>> x86_64 x86_64 GNU/Linux
>
>
> Hold on a moment – if it is actually an *OpenVZ container*, not a VM, how/why 
> is it even reporting a different kernel than the host OS? Isn't the entire 
> point of OpenVZ to share a single kernel with the guest containers? Is it 
> actually 3.10 *pretending* to be 5.4 just to make it pass systemd's kernel 
> version checks?

Re: [systemd-devel] Smooth upgrades for socket activated services

[Michael Biebl]

Am Mo., 20. Feb. 2023 um 11:06 Uhr schrieb Mike Hearn :
>
> Hi,
>
> I'm exploring socket activation as part of work on a tool that makes
> systemd-controlled servers easier to deploy and use. Given a config
> file the tool builds a package that contains the app and systemd
> units, uploads it, installs it with dependency resolution, the
> postinst scripts start the service etc. It's sort of a Docker
> alternative that's more classically Linux-y, designed for a world
> where really big machines are really cheap and thus many apps don't
> need to be cattle-ized. Pets are sometimes OK.
>
> As part of this I'm looking at how to make upgrades smooth. Socket
> activation already allows you to shut down, upgrade and restart a
> service without dropping connections because systemd will hold the
> connections until the service comes back but there are a couple of
> aspects that weren't really clear to me from reading the excellent
> "pid eins" blog post series. Could we maybe get a new blog post
> exploring these issues?
>
> 1. How exactly should you stop a service that's socket activated so it
> won't be re-activated during the upgrade but new connections won't be
> lost, e.g. in package scripts that are executed across upgrades.
> Currently the scripts stop the service before the upgrade happens,
> then restart afterwards.

Currently, there is no way to "freeze" the execution of a socket
activated service.
A feature I'm missing as well, fwiw.

Re: [systemd-devel] systemd-stable and Debian's systemd release strategy

[Michael Biebl]

And as always: help is more then welcome. If you want to get involved,
please contact us at #debian-systemd on OFTC

Am Mi., 18. Jan. 2023 um 16:57 Uhr schrieb Michael Biebl :
>
> Quite simple:
> stable releases: Debian policy is rather strict regarding stable
> uploads and some of the changes that landed in systemd-stable are not
> really considered suitable for a stable upload to Debian. That's why
> we only cherry-pick select fixes.
> If the Debian policy was more lax in that regard, uploading
> system-stable releases would be an option (and initially I had planned
> to do that, but backed away seeing that the diff between 247.3 and
> 237.13 was rather large)
>
> backports: mostly me lacking time. I didn't get around to do a bpo
> upload of v252. One significant issue was the split of
> systemd-resolved into a separate package. We discussed that internally
> if it would be too disruptive for a bpo upload or not and whether this
> should be rolled back for a bpo upload, which would mean additional
> work.
> We mostly agreed after internal discussion to upload the changes as-is
> to bpo and I've been looking into this recently but ran into issues
> with autopkgtest failing for v252 which needs further investigation.
> Some of the issues I could fix, some might need more work.
>
> Am Mi., 18. Jan. 2023 um 10:52 Uhr schrieb tok :
> >
> > Apologies, was not subscribed previously but would also seek the input
> > of systemd-devel on the matter below.
> >
> > Regards, tok
> >
> >
> > On 18.01.23 10:05, tok wrote:
> > > Hi,
> > >
> > > This is not meant as blame but I sincerely would like to understand the 
> > > mechanisms/approach and apparent complexities behind it: I was wondering 
> > > if anyone could shed some light on Debian's strategy of releasing systemd 
> > > packages?
> > >
> > > Commendably, the systemd project maintains a dedicated repository 
> > > (systemd-stable) for stable branches with backported patches available to 
> > > all distros, but apparently the Debian project is not leveraging this to 
> > > its advantage:
> > >
> > > Current version in Debian stable:
> > > 247.3-7+deb11u1 (March 2022)
> > > Latest version of this major release in systemd-stable:
> > > 247.13 (Dec 2022, 10 minor versions ahead)
> > >
> > > Current version in Debian backports:
> > > 251.3-1~bpo11+1 (Aug 2022)
> > > Latest version of this major release in systemd-stable:
> > > 251.10 (Dec 2022, 7 minor versions ahead)
> > >
> > >
> > > What is the reason for this gap? I understand package maintaining is a 
> > > challenging task, especially for something complex like systemd. But 
> > > would the systemd-stable repo not provide already a lot of groundwork (as 
> > > in: backporting bugfixes) for this, to reduce the effort?
> > >
> > > Thanks for insights, regards,
> > > tok

Re: [systemd-devel] systemd-stable and Debian's systemd release strategy

[Michael Biebl]

Quite simple:
stable releases: Debian policy is rather strict regarding stable
uploads and some of the changes that landed in systemd-stable are not
really considered suitable for a stable upload to Debian. That's why
we only cherry-pick select fixes.
If the Debian policy was more lax in that regard, uploading
system-stable releases would be an option (and initially I had planned
to do that, but backed away seeing that the diff between 247.3 and
237.13 was rather large)

backports: mostly me lacking time. I didn't get around to do a bpo
upload of v252. One significant issue was the split of
systemd-resolved into a separate package. We discussed that internally
if it would be too disruptive for a bpo upload or not and whether this
should be rolled back for a bpo upload, which would mean additional
work.
We mostly agreed after internal discussion to upload the changes as-is
to bpo and I've been looking into this recently but ran into issues
with autopkgtest failing for v252 which needs further investigation.
Some of the issues I could fix, some might need more work.

Am Mi., 18. Jan. 2023 um 10:52 Uhr schrieb tok :
>
> Apologies, was not subscribed previously but would also seek the input
> of systemd-devel on the matter below.
>
> Regards, tok
>
>
> On 18.01.23 10:05, tok wrote:
> > Hi,
> >
> > This is not meant as blame but I sincerely would like to understand the 
> > mechanisms/approach and apparent complexities behind it: I was wondering if 
> > anyone could shed some light on Debian's strategy of releasing systemd 
> > packages?
> >
> > Commendably, the systemd project maintains a dedicated repository 
> > (systemd-stable) for stable branches with backported patches available to 
> > all distros, but apparently the Debian project is not leveraging this to 
> > its advantage:
> >
> > Current version in Debian stable:
> > 247.3-7+deb11u1 (March 2022)
> > Latest version of this major release in systemd-stable:
> > 247.13 (Dec 2022, 10 minor versions ahead)
> >
> > Current version in Debian backports:
> > 251.3-1~bpo11+1 (Aug 2022)
> > Latest version of this major release in systemd-stable:
> > 251.10 (Dec 2022, 7 minor versions ahead)
> >
> >
> > What is the reason for this gap? I understand package maintaining is a 
> > challenging task, especially for something complex like systemd. But would 
> > the systemd-stable repo not provide already a lot of groundwork (as in: 
> > backporting bugfixes) for this, to reduce the effort?
> >
> > Thanks for insights, regards,
> > tok

Re: [systemd-devel] Antw: [EXT] [systemd???devel] starting networking from within single user mode?

[Michael Biebl]

Yeah, can we please block this Ulrich Windl guy.
He's been more of a nuisance than a benefit to this community.

Am Mo., 14. Nov. 2022 um 09:17 Uhr schrieb Mantas Mikulėnas :
>
> On Mon, Nov 14, 2022 at 9:00 AM Ulrich Windl 
>  wrote:
>>
>> >>> Mantas Mikulenas  schrieb am 11.11.2022 um 15:49 in
>> Nachricht
>> :
>> > On Fri, Nov 11, 2022 at 4:19 PM Brian Reichert  
>> > wrote:
>> >
>> >> On Fri, Nov 11, 2022 at 08:02:00AM +0100, Ulrich Windl wrote:
>> >> > >>> Brian Reichert  schrieb am 10.11.2022 um
>> >> 23:04 in
>> >> > Nachricht <20221110220426.ga17...@numachi.com>:
>> >> > > I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.
>> >> >
>> >> > And what did you do to mess it up? And what do the boot messages say?
>> >>
>> >> A good question, and not specific to systemd, so I don't want to
>> >> pollute the list archives too much on this matter.
>> >>
>> >> 'All' I did was remove many RPMs that I arbitrarily deemed
>> >> unnecessary.
>> >>
>> >> I came up with a heavily trimmed-down list of SLES RPM for my SLES12
>> >> Sp5 environment.
>> >>
>> >> I successfully installed a server using just that trimmed-down list;
>> >> yay me!
>> >>
>> >> I then explored 'upgrading' a running (slight older) SP5 box, using
>> >> this trimmed-down list.  A purposeful side effect was to uninstall
>> >> RPMs not in that trimmed-down list.
>> >>
>> >> This latter box begins to boot, and gets at least as far as loading
>> >> the initrd image, before hanging.
>> >>
>> >
>> > Boot with "systemd.debug-shell" and use tty9 to investigate from the 
>> > inside.
>>
>> Wow! never heard of that option. Is that a kind of target, or what is the 
>> mechanism?
>> Which of the 196 (man -k systemd | wc -l) systemd-related manual pages would 
>> describe it? ;-)
>
>
> The more I read your smartass sarcastic comments here, the less I feel like 
> staying on this list and helping *other* people with finding stuff in those 
> 196 systemd-related manual pages. But I suppose that's what you want to 
> achieve, so that you can snark even more about how "systemd is so complex 
> that nobody's bothering to reply to the list anymore"?
>
> For those who have *actually* never heard of that option, it is documented in 
> systemd-debug-generator(8).
>
> --
> Mantas Mikulėnas

Re: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Michael Biebl]

Host system: Debian bookworm, systemd v241 (default-hierarchy=hybrid)

container (systemd compiled with default-hierarchy=unified)

v247: works
v248: works
v249: works
v250: fails, with the aforementioned error

So something apparently regressed between v249 and v250.

Am Mo., 17. Okt. 2022 um 01:38 Uhr schrieb Michael Biebl :
>
> What are you Missing?
>
> Lennart Poettering  schrieb am So., 16. Okt. 2022, 
> 23:45:
>>
>> On So, 16.10.22 21:02, Michael Biebl (mbi...@gmail.com) wrote:
>>
>> > Am So., 16. Okt. 2022 um 16:23 Uhr schrieb Lennart Poettering
>> > :
>> > >
>> > > On Fr, 14.10.22 22:57, Michael Biebl (mbi...@gmail.com) wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > since the issue came up on the Debian bug tracker at
>> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019147 , I figured
>> > > > I ask here:
>> > >
>> > > Do you have any MACs in effect?
>> >
>> > No SELinux or Apparmor active
>> >
>> > > Does the host use cgroupsv2 or cgroupsv2 or hybrid? What is mounted to
>> > > /sys/fs/cgroup and below?
>> >
>> > The host system uses systemd v241, compiled with default-hierarchy=hybrid
>> >
>> >
>> > > Was the container configured to use either?
>> >
>> > The container uses systemd v251 with default-hierarchy=unified
>> >
>> > Trying to boot this container v251 container via systemd-nspawn leads to
>> >
>> > Welcome to Debian GNU/Linux bookworm/sid!
>> >
>> > Hostname set to .
>> > Failed to create /init.scope control group: Operation not permitted
>> > Failed to allocate manager object: Operation not permitted
>> > [!!] Failed to allocate manager object.
>> > Exiting PID 1...
>> > Container test-bookworm failed with error code 255.
>>
>> Please answer the questions I asked, otherwise not actionable...
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin

Re: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Michael Biebl]

What are you Missing?

Lennart Poettering  schrieb am So., 16. Okt. 2022,
23:45:

> On So, 16.10.22 21:02, Michael Biebl (mbi...@gmail.com) wrote:
>
> > Am So., 16. Okt. 2022 um 16:23 Uhr schrieb Lennart Poettering
> > :
> > >
> > > On Fr, 14.10.22 22:57, Michael Biebl (mbi...@gmail.com) wrote:
> > >
> > > > Hi,
> > > >
> > > > since the issue came up on the Debian bug tracker at
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019147 , I
> figured
> > > > I ask here:
> > >
> > > Do you have any MACs in effect?
> >
> > No SELinux or Apparmor active
> >
> > > Does the host use cgroupsv2 or cgroupsv2 or hybrid? What is mounted to
> > > /sys/fs/cgroup and below?
> >
> > The host system uses systemd v241, compiled with default-hierarchy=hybrid
> >
> >
> > > Was the container configured to use either?
> >
> > The container uses systemd v251 with default-hierarchy=unified
> >
> > Trying to boot this container v251 container via systemd-nspawn leads to
> >
> > Welcome to Debian GNU/Linux bookworm/sid!
> >
> > Hostname set to .
> > Failed to create /init.scope control group: Operation not permitted
> > Failed to allocate manager object: Operation not permitted
> > [!!] Failed to allocate manager object.
> > Exiting PID 1...
> > Container test-bookworm failed with error code 255.
>
> Please answer the questions I asked, otherwise not actionable...
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

Re: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Michael Biebl]

Am So., 16. Okt. 2022 um 16:23 Uhr schrieb Lennart Poettering
:
>
> On Fr, 14.10.22 22:57, Michael Biebl (mbi...@gmail.com) wrote:
>
> > Hi,
> >
> > since the issue came up on the Debian bug tracker at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019147 , I figured
> > I ask here:
>
> Do you have any MACs in effect?

No SELinux or Apparmor active

> Does the host use cgroupsv2 or cgroupsv2 or hybrid? What is mounted to
> /sys/fs/cgroup and below?

The host system uses systemd v241, compiled with default-hierarchy=hybrid


> Was the container configured to use either?

The container uses systemd v251 with default-hierarchy=unified

Trying to boot this container v251 container via systemd-nspawn leads to

Welcome to Debian GNU/Linux bookworm/sid!

Hostname set to .
Failed to create /init.scope control group: Operation not permitted
Failed to allocate manager object: Operation not permitted
[!!] Failed to allocate manager object.
Exiting PID 1...
Container test-bookworm failed with error code 255.

[systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Michael Biebl]

Hi,

since the issue came up on the Debian bug tracker at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019147 , I figured
I ask here:

Am 04.09.22 um 18:40 schrieb Bernhard Übelacker:
>
> Package: systemd-container
> Severity: wishlist
> X-Debbugs-Cc: bernha...@mailbox.org
>
>
> Dear Maintainer,
> I tried to run on top of a buster system
> with systemd-container 241-7~deb10u8 to start a container
> with a current bookworm chroot with systemd-container 251.4-3.
> This buster system was running linux-image 4.19.0-21-amd64.
>
> This failed with following error:
>
>  root@debian:~# systemd-nspawn
> --directory=/var/lib/machines/test-bookworm --boot --network-veth
>  Spawning container test-bookworm on /var/lib/machines/test-bookworm.
>  Press ^] three times within 1s to kill container.
>  systemd 251.4-3 running in system mode (+PAM +AUDIT +SELINUX
> +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID
> +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK
> +PCRE2 -PWQUALITY -P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD
> -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
>  Detected virtualization systemd-nspawn.
>  Detected architecture x86-64.
>
>  Welcome to Debian GNU/Linux bookworm/sid!
>
>  Hostname set to .
>  Failed to create /init.scope control group: Operation not permitted
>  Failed to allocate manager object: Operation not permitted
>  [!!] Failed to allocate manager object.
>  Exiting PID 1...
>  Container test-bookworm failed with error code 255.
>
>
> So this report is mostly to ask if this expected or desired to work?

Good question. Maybe raise that on the systemd-devel mailing list?
Keep in mind, that in bullseye we switched to cgroupv2, i.e. we build
systemd with -Ddefault-hierarchy=unified

I'm honestly not sure which combination of versions (and cgroup layouts)
are supported.

Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

[Michael Biebl]

Am Fr., 7. Okt. 2022 um 09:24 Uhr schrieb Klaus Ebbe Grue :
> QUESTION: Is it possible to let systemd create a listening socket and yet be 
> able to have that socket activate nothing, at least temporarily?

Unfortunately not. You'd need some kind of "maintenance" mode you
could put a service in, where systemd would keep the socket open but
just queues the requests until the service is put out of maintenance
mode again. There is no such feature atm although I would have found
that useful for Debian as well (during package upgrades).
The best you can currently do is probably to stop the .socket to avoid
accidental activation during the upgrade.

Re: [systemd-devel] *****SPAM***** Re: problem understanding why I am 'forced' to run systemd-journald

[Michael Biebl]

Am Mi., 5. Okt. 2022 um 13:28 Uhr schrieb František Šumšal
:
>
> On 10/5/22 11:56, Marc wrote:
> > I have seen that, but is that not something like 'accepting log entries and 
> > sending data to /dev/null'? I am looking for an option that does not 
> > process anything.
>
> Not really, as the man page (that Michael already linked) states [0] using 
> Storage=volatile will cause the journals to be stored only in memory (under 
> /run/log/journal) without any disk writes. You can also disable journal 
> completely using Storage=none, in which case journald would work only as a 
> forwarder to syslog/kmsg and other configured services (if present). Again, 
> I'd recommend going through the Storage= docs in the respective man page[0].

Storage=none has the downside, that `systemctl status` etc become less
useful. So if you have a bit of RAM to spare, I'd recommend
Storage=volatile for your particular use case.
You will have a bit of CPU overhead for journald doing the message
multiplexing but disabling it completely is not really recommended.

And personally, journalctl is just so useful. I wouldn't want to miss it.

Re: [systemd-devel] problem understanding why I am 'forced' to run systemd-journald

[Michael Biebl]

https://www.freedesktop.org/software/systemd/man/journald.conf.html#Storage=

→ volatile

Am Mi., 5. Okt. 2022 um 11:40 Uhr schrieb Marc :
>
>
> Hello,
>
> I have started to upgrade a few machines from CentOS7 to recent versions of 
> CentOS/Rocky. However I don't really get why there is a systemd-journald 
> process writing stuff to disk while I have explicitly configured that logs 
> should go to a remote syslog server.
>
> Reading such pages [1] does not really explain the design idea behind wanting 
> to generated 2x the amount iops. One would think with all this environmental 
> co2 global warming stuff, design would be aimed at being more efficient.
>
> 1. why do I need system-journald?
>
> 2. why is it not a service that can be disabled?
>
> 3. How can I make sure that none of the logs I have, are not having a 
> duplicate somewhere?
>
> I have 'slower' distributed storage, so it is important to minimize the 
> amount of useless io being generated.
> I was already complaining to Bill Gates, he should shut up about the 
> environment. If he did not hire 'lazy' people and spend a few billion more on 
> development we would have a lot less energy consumption, because windows is 
> using quite a lot of resources compared to linux. Now upgrading, I have ~2x 
> iops then before.
>
> Can anyone help me with my 3 questions?

Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target

[Michael Biebl]

Am Fr., 9. Sept. 2022 um 14:12 Uhr schrieb Michael Biebl :
>
> Am Fr., 9. Sept. 2022 um 14:01 Uhr schrieb Ulrich Windl
> :
> >
> > >>> Andrei Borzenkov  schrieb am 09.09.2022 um 13:41 in
> > Nachricht
> > :
> > > On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
> > >  wrote:
> > > ...
> > >> >
> > >> > If you are interested in services that pull in e.g. time-sync.target
> > >> > via Wants (or Requires) and order themselves before the target, you
> > >> > can use something like
> > >> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
> > >> > RequiredBy=
> > >> > WantedBy=chrony.service
> > >> > After=chrony.service time-set.target
> > >>
> > >> It seems what I wanted to know is output by
> > >> # systemctl show -p After time-set.target
> > >> After=systemd-timesyncd.service
> > >> # systemctl show -p After time-sync.target
> > >> After=time-set.target ntp-wait.service
> > >>
> > >> However the "After=" is somewhat unexpected.
> > >
> > > This is exactly what targets are about. The only usage for targets is
> > > to wait until something else becomes active and to do it they must
> > > come After something.
> > >
> > >> And "-p WantedBy" is definitely
> > >> wrong (it will output units that "require the target", not the units
> > > "providing
> > >> the target").
> > >>
> > >
> > > There is no such thing as "units providing the target". Systemd
> > > documentation makes distinction between targets that Want other units
> > > ("active") and targets that are WantedBy other units ("passive"). It
> > > is expected that services "providing" passive targets have
> > > WantedBy=this-passive.target, otherwise passive targets will not be
> > > activated at all. So WantedBy is exactly correct in this case.
> >
> > Hi!
> >
> > But when I include it (as suggested) I get:
> > # systemctl show  -p WantedBy -p RequiredBy -p After time-sync.target
> > RequiredBy=
> > WantedBy=iotwatch@ROOT.service iotwatch@VPM.service 
> > iotwatch-generator.service ntp-wait.service systemd-timesyncd.service
> > After=time-set.target ntp-wait.service
> > ---
> >
> > Those iotwatch* units use "Before="; so is the WantedBy= incorrect for 
> > those?
> >
> > Those units use:
> > Wants=nss-user-lookup.target time-sync.target paths.target
> > After=nss-user-lookup.target time-sync.target paths.target
>
>
> See man systemd.special, passive and active targets (as Andrei already
> hinted at).
> Quoting the relevant parts
> "   Special Passive System Units
>A number of special system targets are defined that can be used
> to properly order boot-up of optional services. These targets are
> generally not part of the initial boot transaction, unless they are
> explicitly pulled in by one of the implementing
>services. Note specifically that these passive target units are
> generally not pulled in by the consumer of a service, but by the
> provider of the service.
> "
>  iotwatch* does appear to be a consumer of the time-sync.target, so it
> should merely have an ordering but not pull in the target.

Quoting the rest of the man page section:
"
This means: a consuming service should order itself after these
targets (as appropriate), but not
 pull it in. A providing service should order itself before these
targets (as appropriate) and pull it in (via a Wants= type
dependency).
"

Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target

[Michael Biebl]

Am Fr., 9. Sept. 2022 um 14:01 Uhr schrieb Ulrich Windl
:
>
> >>> Andrei Borzenkov  schrieb am 09.09.2022 um 13:41 in
> Nachricht
> :
> > On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
> >  wrote:
> > ...
> >> >
> >> > If you are interested in services that pull in e.g. time-sync.target
> >> > via Wants (or Requires) and order themselves before the target, you
> >> > can use something like
> >> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
> >> > RequiredBy=
> >> > WantedBy=chrony.service
> >> > After=chrony.service time-set.target
> >>
> >> It seems what I wanted to know is output by
> >> # systemctl show -p After time-set.target
> >> After=systemd-timesyncd.service
> >> # systemctl show -p After time-sync.target
> >> After=time-set.target ntp-wait.service
> >>
> >> However the "After=" is somewhat unexpected.
> >
> > This is exactly what targets are about. The only usage for targets is
> > to wait until something else becomes active and to do it they must
> > come After something.
> >
> >> And "-p WantedBy" is definitely
> >> wrong (it will output units that "require the target", not the units
> > "providing
> >> the target").
> >>
> >
> > There is no such thing as "units providing the target". Systemd
> > documentation makes distinction between targets that Want other units
> > ("active") and targets that are WantedBy other units ("passive"). It
> > is expected that services "providing" passive targets have
> > WantedBy=this-passive.target, otherwise passive targets will not be
> > activated at all. So WantedBy is exactly correct in this case.
>
> Hi!
>
> But when I include it (as suggested) I get:
> # systemctl show  -p WantedBy -p RequiredBy -p After time-sync.target
> RequiredBy=
> WantedBy=iotwatch@ROOT.service iotwatch@VPM.service 
> iotwatch-generator.service ntp-wait.service systemd-timesyncd.service
> After=time-set.target ntp-wait.service
> ---
>
> Those iotwatch* units use "Before="; so is the WantedBy= incorrect for those?
>
> Those units use:
> Wants=nss-user-lookup.target time-sync.target paths.target
> After=nss-user-lookup.target time-sync.target paths.target


See man systemd.special, passive and active targets (as Andrei already
hinted at).
Quoting the relevant parts
"   Special Passive System Units
   A number of special system targets are defined that can be used
to properly order boot-up of optional services. These targets are
generally not part of the initial boot transaction, unless they are
explicitly pulled in by one of the implementing
   services. Note specifically that these passive target units are
generally not pulled in by the consumer of a service, but by the
provider of the service.
"
 iotwatch* does appear to be a consumer of the time-sync.target, so it
should merely have an ordering but not pull in the target.

Re: [systemd-devel] [EXT] Re: Q: Querying units for "what provides" a target

[Michael Biebl]

Am Fr., 9. Sept. 2022 um 12:31 Uhr schrieb Michael Biebl :
>
> Am Fr., 9. Sept. 2022 um 12:08 Uhr schrieb Ulrich Windl
> :
> >
> > >>> Michael Biebl  schrieb am 09.09.2022 um 10:55 in
> > Nachricht
> > :
> > > Example: syslog.service
> > >
> > > $ systemctl status syslog.service
> > > ● rsyslog.service - System Logging Service
> > >  Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled;
> > > preset: enabled)
> > >  Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h
> > > ago
> > > TriggeredBy: ● syslog.socket
> > >Docs: man:rsyslogd(8)
> > >  man:rsyslog.conf(5)
> > >  https://www.rsyslog.com/doc/
> > >Main PID: 624 (rsyslogd)
> > >   Tasks: 4 (limit: 19002)
> > >  Memory: 3.8M
> > > CPU: 1.341s
> > >  CGroup: /system.slice/rsyslog.service
> > >  └─624 /usr/sbin/rsyslogd -n -iNONE
> > >
> > > You'll see that syslog.service is provided by  provided by
> > > rsyslog.service (and the actual name of the file on the disk)
> > > Isn't this what you wanted? If not, I must have misunderstood what you
> > > are looking for.
> >
> > Hi!
> >
> > I'm afraid that does not help:
> > # systemctl status time-set.target
> > ● time-set.target - System Time Set
> >  Loaded: loaded (/usr/lib/systemd/system/time-set.target; static)
> >  Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago
> >Docs: man:systemd.special(7)
> >
> > Now what is actually providing "time-set" (if any)?
> > Does that mean "nothing provides time-set"?
> >
> > Likewise:
> > # systemctl status time-sync.target
> > ● time-sync.target - System Time Synchronized
> >  Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static)
> >  Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago
> >Docs: man:systemd.special(7)
> >
> > Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized.
> >
> > Clear now?
>
> Not really.
> Are you interested in what services hook into time-sync.target (and
> are ordered before it)?

If you are interested in services that pull in e.g. time-sync.target
via Wants (or Requires) and order themselves before the target, you
can use something like
$ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
RequiredBy=
WantedBy=chrony.service
After=chrony.service time-set.target

Re: [systemd-devel] [EXT] Re: Q: Querying units for "what provides" a target

[Michael Biebl]

Am Fr., 9. Sept. 2022 um 12:08 Uhr schrieb Ulrich Windl
:
>
> >>> Michael Biebl  schrieb am 09.09.2022 um 10:55 in
> Nachricht
> :
> > Example: syslog.service
> >
> > $ systemctl status syslog.service
> > ● rsyslog.service - System Logging Service
> >  Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled;
> > preset: enabled)
> >  Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h
> > ago
> > TriggeredBy: ● syslog.socket
> >Docs: man:rsyslogd(8)
> >  man:rsyslog.conf(5)
> >  https://www.rsyslog.com/doc/
> >Main PID: 624 (rsyslogd)
> >   Tasks: 4 (limit: 19002)
> >  Memory: 3.8M
> > CPU: 1.341s
> >  CGroup: /system.slice/rsyslog.service
> >  └─624 /usr/sbin/rsyslogd -n -iNONE
> >
> > You'll see that syslog.service is provided by  provided by
> > rsyslog.service (and the actual name of the file on the disk)
> > Isn't this what you wanted? If not, I must have misunderstood what you
> > are looking for.
>
> Hi!
>
> I'm afraid that does not help:
> # systemctl status time-set.target
> ● time-set.target - System Time Set
>  Loaded: loaded (/usr/lib/systemd/system/time-set.target; static)
>  Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago
>Docs: man:systemd.special(7)
>
> Now what is actually providing "time-set" (if any)?
> Does that mean "nothing provides time-set"?
>
> Likewise:
> # systemctl status time-sync.target
> ● time-sync.target - System Time Synchronized
>  Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static)
>  Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago
>Docs: man:systemd.special(7)
>
> Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized.
>
> Clear now?

Not really.
Are you interested in what services hook into time-sync.target (and
are ordered before it)?

Re: [systemd-devel] [EXT] Re: Q: Querying units for "what provides" a target

[Michael Biebl]

Example: syslog.service

$ systemctl status syslog.service
● rsyslog.service - System Logging Service
 Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled;
preset: enabled)
 Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h ago
TriggeredBy: ● syslog.socket
   Docs: man:rsyslogd(8)
 man:rsyslog.conf(5)
 https://www.rsyslog.com/doc/
   Main PID: 624 (rsyslogd)
  Tasks: 4 (limit: 19002)
 Memory: 3.8M
CPU: 1.341s
 CGroup: /system.slice/rsyslog.service
 └─624 /usr/sbin/rsyslogd -n -iNONE

You'll see that syslog.service is provided by  provided by
rsyslog.service (and the actual name of the file on the disk)
Isn't this what you wanted? If not, I must have misunderstood what you
are looking for.

Am Fr., 9. Sept. 2022 um 10:52 Uhr schrieb Ulrich Windl
:
>
> >>> Michael Biebl  schrieb am 09.09.2022 um 10:30 in 
> >>> Nachricht
> :
> > I'd probably just use `systemctl status`
>
> Can you give some details? I don't see what I'm expecting to see.
>
> Regards,
> Ulrich
>
>
> >
> > Am Fr., 9. Sept. 2022 um 10:18 Uhr schrieb Ulrich Windl
> > :
> >>
> >> Hi!
> >>
> >> I'm wondering: having some specific target, e.g. time-set.target, how can I
> > find out what actually "provides" that target?
> >> I see that I can query what "requires" the given target, but how to I get
> > the other direction?
> >> I mean by using a tool like systemctl, not by finding and grepping some
> > directories for symbolic links.
> >>
> >> Sorry if that turns out to be a stupid question where I should have known
> > the answer...
> >>
> >> Regards,
> >> Ulrich
> >>
> >>
> >>
>
>
>
>

Re: [systemd-devel] Q: Querying units for "what provides" a target

[Michael Biebl]

I'd probably just use `systemctl status`

Am Fr., 9. Sept. 2022 um 10:18 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> I'm wondering: having some specific target, e.g. time-set.target, how can I 
> find out what actually "provides" that target?
> I see that I can query what "requires" the given target, but how to I get the 
> other direction?
> I mean by using a tool like systemctl, not by finding and grepping some 
> directories for symbolic links.
>
> Sorry if that turns out to be a stupid question where I should have known the 
> answer...
>
> Regards,
> Ulrich
>
>
>

Re: [systemd-devel] Help required for configuring a blocking service during shutdown

[Michael Biebl]

Would the systemd inhibit interface be an option?

https://www.freedesktop.org/wiki/Software/systemd/inhibit/

It was designed for that use case after all.

Am Mo., 29. Aug. 2022 um 14:01 Uhr schrieb Mantas Mikulėnas :
>
> On Mon, Aug 29, 2022 at 1:31 PM Henning Moll  wrote:
>>
>> Hi,
>>
>> back in the rcX days I configured a backup system which blocks a system 
>> shutdown in a certain state (network and mounts still active) if a backup is 
>> still running. The init script looks like this:
>>
>> ...
>> case "$1" in
>> ...
>>   stop)
>> plymouth --ping
>> if [ $? -ne 0 ]; then
>>   log_daemon_msg "waiting for running backup" "backup"
>> else
>>   plymouth message --text="waiting for running backup"
>> fi
>> sleep 10
>> logger -t backup "rcS: trying to get lock..."
>> exec {FD}<>"$LOCKFILE"
>> {
>>   logger -t backup "locked rsync_wrapper: waiting for lock"
>>   flock ${FD}
>> }
>> logger -t backup "rcS: continue shutdown..."
>> plymouth message --text=""
>>
>> ...
>> esac
>> ...
>>
>> The strategy is to wait for a successful lock on a shared LOCKFILE.
>>
>> Now, I want to solve this with systemd. I've read tons of documentation but 
>> I don't get it, all my experiments failed. I am using Linux Mint 21 
>> "Vanessa", which is based on Ubunut 22.04.
>>
>> I am looking for a solution which
>>
>> * "pauses" a shutdown or reboot attempt as long as the LOCK cannot be 
>> obtained (which means the backup is still running)
>> * while the network connection (ethernet) is still active
>> * and all mounts (local, usb and cifs) are still active
>> * openssh-server still running
>> * The logging functionality (plymouth / log_daemon) would be nice. so the 
>> system should be allowed to shutdown to a stage where plymouth is already 
>> visible
>>
>> Can you please help me?
>>
>> Best regards
>> Henning
>
>
> Probably similar to what you already have – create a service that starts on 
> boot (doing nothing) and delays the *stop* action. (You'll probably need to 
> start with [Service] Type=oneshot, RemainAfterExit=yes, TimeoutStopSec=1d.) 
> If you list After=ssh.service as a dependency, then your service will be 
> started after OpenSSH and *stopped before OpenSSH*, same with NetworkManager. 
> (I'm not sure if there's a dependency that can be used to target manually 
> done SMB mounts, although remote-fs.target might work for the ones in fstab?)
>
> Not sure how it works with Plymouth, but in its default console output, 
> systemd itself will already show which services are waiting to be stopped. 
> Syslog (journald) should be available the entire time.
>
> The backup system should also run under `systemd-inhibit --what=shutdown` as 
> an additional layer of precaution – that way the user will know that 
> something is still running *before* they initiate the actual shutdown.
>
> --
> Mantas Mikulėnas

Re: [systemd-devel] Service output missing from journal?

[Michael Biebl]

Am Mo., 4. Juli 2022 um 19:36 Uhr schrieb Lennart Poettering
:
>
> eOn So, 03.07.22 19:29, Uwe Geuder (systemd-devel-ugeu...@snkmail.com) wrote:
>
> > Hi!
> >
> > When I run the command given below on a current Fedora CoreOS system
> > (systemd 250 (v250.6-1.fc36)) I get a result I absolute cannot understand.
> > Can anybody help me with what is wrong there?
> >
> > $ systemd-run --user sh -c 'while true; do echo foo; df -h 
> > /var/log/journal/; echo $?; sleep 3; done'
> > Running as unit: run-r9a155474889b4d40a1ac119823bdc2bf.service
> > $ journalctl --user -f -u run-r9a155474889b4d40a1ac119823bdc2bf
> > [ ... similar lines redacted ... ]
> > Jul 03 15:25:08 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:11 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:11 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:14 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:14 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:17 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:17 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:20 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:20 ip-172-31-8-116 sh[366941]: Filesystem  Size  Used 
> > Avail Use% Mounted on
> > Jul 03 15:25:20 ip-172-31-8-116 sh[366941]: /dev/nvme0n1p4  9.5G  8.1G  
> > 1.5G  86% /var
> > Jul 03 15:25:20 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:23 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:23 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:26 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:26 ip-172-31-8-116 sh[366900]: 0
> > Jul 03 15:25:29 ip-172-31-8-116 sh[366900]: foo
> > Jul 03 15:25:29 ip-172-31-8-116 sh[366900]: 0
> > [...]
> >
> > So the output from the df command appears in the journal pretty rarely,
> > appearingly at random intervals. When I run the same loop on the
> > command line the output occurs every time.
> >
> > The problem was originally noted in a somewhat loaded system. However,
> > above reproducer (including the 2 echo commands and a shorter sleep)
> > shows the same problem even on an idling machine.
>
> https://github.com/systemd/systemd/issues/2913

I thought about this as well, but in this case the service is still
running. So I'm not sure if #2913 applies here.

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Michael Biebl]

Am Mo., 2. Mai 2022 um 11:26 Uhr schrieb Lennart Poettering
:
>
> On Sa, 30.04.22 14:54, Andrea Pappacoda (and...@pappacoda.it) wrote:
>
> > > > If current bootloader already works on platforms supported by
> > > > distribution, what is gained by adding yet another one?
> > > Freedom of choice
> > >
> > There's nothing preventing you from using systemd-boot on Debian, and in
> > fact I do. It would be nice to have secure boot working out of the box, but
> > unfortunately this isn't currently possible.
>
> Well, it's certainly *possible*, there's zero technical reason behing
> not allowing this. It's a 100% political decision by the SHIM upstream
> maintainer.

Right, this is really a shim upstream issue rather then Debian downstream issue.

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Michael Biebl]

Am Mi., 27. Apr. 2022 um 18:02 Uhr schrieb Michael Biebl :
>
> Am Mi., 27. Apr. 2022 um 17:16 Uhr schrieb Dan Nicholson :
> >
> > On Wed, Apr 27, 2022 at 9:01 AM Michael Biebl  wrote:
> > >
> > > Slightly related
> > > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138
> > > [sd-boot split]
> > > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
> > > [Draft: Prepare for EFI signing]
> >
> > Oh, nice. We've been signing sd-boot in Endless for a couple years now
> > with our systemd package based on Debian's. Currently the entire
> > systemd package is sent through the signing flow just for sd-boot.
> > When sd-boot is a separate package that can be much simpler with the
> > normal non-sd-boot targets unaffected.
>
>
> This discussion  might be relevant to  you then
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202
>
> Automatically signing sd-boot in Debian was rejected by Julian Andres Klode

>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202#60

"""
we have recently discussed the matter of systemd-boot in

an upstream shim review gathering.

We reject a signing of systemd-boot as

* systemd-boot does not use current ways of communicating with
  shim

* There was some concern over general quality

* systemd-boot is an additional bootloader, rather than replacing
  an existing one, thus increasing the attack surface.

  If people want to experiment with other bootloaders than the
  default one, they can disable secure boot, or load their own
  keys into the machine. We do not consider it valid to have
  a choice of bootloaders.

I want to note that the current shim has been signed with the
understanding that it will trust grub, kernels, and fwupd. A
signing of systemd-boot might be considered reasons for revoking
the existing shim, and will certainly result in new shims not
getting signed.
"""

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Michael Biebl]

Am Mi., 27. Apr. 2022 um 17:16 Uhr schrieb Dan Nicholson :
>
> On Wed, Apr 27, 2022 at 9:01 AM Michael Biebl  wrote:
> >
> > Slightly related
> > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138
> > [sd-boot split]
> > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
> > [Draft: Prepare for EFI signing]
>
> Oh, nice. We've been signing sd-boot in Endless for a couple years now
> with our systemd package based on Debian's. Currently the entire
> systemd package is sent through the signing flow just for sd-boot.
> When sd-boot is a separate package that can be much simpler with the
> normal non-sd-boot targets unaffected.


This discussion  might be relevant to  you then
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202

Automatically signing sd-boot in Debian was rejected by Julian Andres Klode

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Michael Biebl]

Slightly related
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138
[sd-boot split]
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
[Draft: Prepare for EFI signing]

Am Mi., 27. Apr. 2022 um 16:13 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> On Wed, Apr 27, 2022 at 08:55:55AM -0400, Neal Gompa wrote:
> > On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote:
> > > > Hey all,
> > >
> > > Hi Neal,
> > >
> > > thank you for starting the discussion. I think it'd be good to figure
> > > out what are the high-level options we have as a community…
> > >
> > > > Some of you might know about the recent discussion in Fedora about
> > > > dropping BIOS support[1][2]. While the end result for now is that
> > > > we're not dropping it[3], several side discussions involved enabling
> > > > systemd-boot as an option in Fedora in the future.
> > > >
> > > > While I *personally* am not a huge fan of systemd-boot itself
> > >
> > > You mentioned that a few times, and we (at least Lennnart and I) have
> > > asked for details. If there's something important missing from sd-boot,
> > > we would like to know.
> > >
> >
> > I think this is probably a distraction from this discussion, but sure
> > I guess I can answer: I fundamentally dislike systemd-boot because I
> > feel it's not a very user-friendly boot manager because of its
> > absolutely spartan interface. I'm much more of a fan of rEFInd[1],
> > which provides a feature-rich and user-friendly EFI boot manager[2].
>
> Ah, icons and graphics ;) Yeah, we don't provide that, and I don't think
> there are any plans to work on this. Instead of trying to make the menu
> better, we can follow the example of windows: integrate the boot menu
> directly in the graphical environment. We already have command-line access
> to this: bootctl reboot-to-firmware, bootctl set-oneshot,
> systemctl reboot --boot-loader-entry=. With a little bit of integration
> users should be able to select the system / kernel to boot directly
> from the reboot dialogue.
>
> Rebooting from the DE has advantages: nice UI without much work, l10n,
> accessibility, help, integration with normal auth mechanisms (e.g. polkit
> auth for non-default boot entries or firmware setup), no need to
> fiddle with pressing keys at the exactly right time.
>
> > Essentially, the Koji build channel for secure boot is made up of three 
> > things:
>
> [snip]
>
> Thanks for the description. If the limitation that only RH folks can
> build the official package is true, it'd be annoying, but not such a big
> issue. In the recent times, I made the most builds, with Adam Williamson
> and Yu Watanabe also doing an occasional build, i.e. all RH employees. It
> is important that people can do pull requests for dist-git, but limiting the
> offical builds to a few people wouldn't be a big issue. (Don't get me wrong:
> I would prefer to keep the current state where a bunch of maintainer *and*
> any proven packager or relengee can build systemd, but in practice it doesn't
> happen much.)
>
> > For sd-boot, it'd be making sure the package is "ExclusiveArch:
> > %{efi}", then in %install, you'd do:
> >
> > pushd %{buildroot}%{_prefix}/lib/systemd/boot/efi
> > %pesign -s -i systemd-boot%{efi_arch}.efi -o 
> > systemd-boot%{efi_arch}.efi.signed
> > popd
>
> https://src.fedoraproject.org/rpms/systemd/pull-request/77
> does the deed. PTAL. (Though it just conditionalized the build on
> %ifarch %efi, instead of limiting where the package is built. In mock
> this produces an additional .signed thingy that 'bootctl update'
> should pick up automatically.)
>
> Zbyszek

Re: [systemd-devel] Dropping split-usr/unmerged-usr support

[Michael Biebl]

Am Di., 5. Apr. 2022 um 22:07 Uhr schrieb Luca Boccassi
:
>
> Hi,
>
> As part of our spring cleaning effort, we are considering when to drop
> support for split/unmerged-usr filesystem layouts.
>
> A build-time warning was added last year:
>
> https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd954469
>
> We are now adding a runtime taint as well.
>
> Which distributions are left running with systemd on a split/unmerged-
> usr system?

cough, I guess you know at least one :-)

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

[Michael Biebl]

As far as Debian is concerned, we do have

4.9.x in old old stable aka stretch
4.19.x in old stable aka buster
5.10.x in stable aka bullseye
5.16.x in unstable/bookworm

We do provide backports of current systemd versions for bullseye. I
also do care that users upgrading from bullseye to bookworm can
continue to use the old stable kernel, which would be 5.10.x
So all in all, not an issue from the Debian side, as this would mean
the baseline would be 5.10.x

Obviously I can't speak for all our downstreams (like raspbian) or
individual users with their self-compiled kernels.
Which I guess is more common among Debian then e.g. Fedora users.


Regards,
Michael

Am Di., 22. März 2022 um 17:34 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> Hi all,
>
> we are considering dropping upstream support for kernel versions < 4.4.
> Would this be a problem for anyone? (*).
>
> Zbyszek
>
>
> (*) If you answer "yes", please substantiate why you are running new
> systemd with such old kernels.

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

[Michael Biebl]

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.

Re: [systemd-devel] making firewalld an early boot service

[Michael Biebl]

Am Mi., 9. März 2022 um 06:49 Uhr schrieb Andrei Borzenkov
:
>
> On 09.03.2022 00:59, Michael Biebl wrote:
> > Hi,
> >
> > I need help with firewalld issue, specifically
> > https://github.com/firewalld/firewalld/issues/414
> >
> > the TLDR: both firewalld.service and cloud-init-local.service hook
> > into network-pre.target and have a Before=network-pre.target ordering.
> >
> > cloud-init-local.service is an early boot service using
> > DefaultDependencies=no and before sysinit.target.
> > firewalld.service via DefaultDependencies=yes get's an
> > After=sysinit.target ordering.
> >
> > So we have conflicting requirements and a dependency loop that needs
> > to be broken by systemd.
> >
>
> Firewalld is red herring here. cloud-init.service has
>
> After=networking.service
> Before=sysinit.target
>
> This is a loop which has nothing to do with firewalld.

Afaics firewalld.service is involved here.
For one, without it installed, there is no such ordering cycle.

To me it looks like cloud-init.service and firewalld.service are tied
together via this cloud-init-local.service


> [1.643638] systemd[1]: sysinit.target: Found ordering cycle on
> cloud-init.service/start
> [1.645482] systemd[1]: sysinit.target: Found dependency on
> networking.service/start
> [1.647274] systemd[1]: sysinit.target: Found dependency on
> network-pre.target/start
> [1.649010] systemd[1]: sysinit.target: Found dependency on
> firewalld.service/start
> [1.650718] systemd[1]: sysinit.target: Found dependency on
> dbus.service/start
> [1.652294] systemd[1]: sysinit.target: Found dependency on
> basic.target/start
> [1.654033] systemd[1]: sysinit.target: Found dependency on
> sysinit.target/start
> [1.655528] systemd[1]: sysinit.target: Job cloud-init.service/start
> deleted to break ordering cycle starting with sysinit.target/start
>
>
> ...
>
> >
> >
> > I dropped the After=dbus.service polkit.service orderings, as they are
> > either socket or D-Bus activated services, added an explicit
> > After=local-fs.target ordering just to be sure and hooked it into
> > sysinit.target.
> >
> > Would you agree that making a firewall service an early boot service
> > is a good idea?
>
> Firewalld cannot be socket activated. The whole reason to have firewall
> (any firewall) startup service is to instantiate netfilter configuration
> before networking becomes available. When exactly it is done does not
> matter - it can well be done as early boot service. But it cannot be
> delayed until something contacts firewall endpoint. It must be done
> before network-pre.target.

I don't think i said I want firewalld to become socket activated?
What I did was drop After=dbus.service and After=polkit.service.
firewald.service is a Type=dbus service, so already get's an explicit
After=dbus.socket, Requires=dbus.socket which I think should satisfy
firewalld's D-Bus requirements, no?

> > Does the above make sense or have I missed something?
> >
> > Feedback welcome.
>
> firewalld requires D-Bus so it must be started after D-Bus. You cannot
> start it earlier.

See above, being Type=dbus, it has an explicit Requires/After=dbus.socket.

[systemd-devel] making firewalld an early boot service

[Michael Biebl]

Hi,

I need help with firewalld issue, specifically
https://github.com/firewalld/firewalld/issues/414

the TLDR: both firewalld.service and cloud-init-local.service hook
into network-pre.target and have a Before=network-pre.target ordering.

cloud-init-local.service is an early boot service using
DefaultDependencies=no and before sysinit.target.
firewalld.service via DefaultDependencies=yes get's an
After=sysinit.target ordering.

So we have conflicting requirements and a dependency loop that needs
to be broken by systemd.

I wonder if firewald should be turned into an early boot service as well.
Currently it looks like this:

[Unit]
Description=firewalld - dynamic firewall daemon
Before=network-pre.target
Wants=network-pre.target
After=dbus.service
After=polkit.service
Conflicts=iptables.service ip6tables.service ebtables.service
ipset.service nftables.service
Documentation=man:firewalld(1)

[Service]
...
[Install]
WantedBy=multi-user.target
Alias=dbus-org.fedoraproject.FirewallD1.service

I wonder if the following would make sense


[Unit]
Description=firewalld - dynamic firewall daemon
DefaultDependencies=no
Before=network-pre.target
Wants=network-pre.target
After=local-fs.target
Conflicts=iptables.service ip6tables.service ebtables.service
ipset.service nftables.service
Documentation=man:firewalld(1)

[Service]
...
[Install]
WantedBy=sysinit.target
Alias=dbus-org.fedoraproject.FirewallD1.service


I dropped the After=dbus.service polkit.service orderings, as they are
either socket or D-Bus activated services, added an explicit
After=local-fs.target ordering just to be sure and hooked it into
sysinit.target.

Would you agree that making a firewall service an early boot service
is a good idea?
Does the above make sense or have I missed something?

Feedback welcome.

Re: [systemd-devel] Passive vs Active targets

[Michael Biebl]

Fwiw, the Debian rsyslog package does not have any such dependencies/orderings.

But there is https://github.com/rsyslog/rsyslog-pkg-rhel-centos/issues/72

Re: [systemd-devel] Antw: [EXT] Service activation

[Michael Biebl]

Am Mo., 14. Feb. 2022 um 09:42 Uhr schrieb Wols Lists
:
> I doubt it. Documentation is excellent at reminding you what you already
> knew. It's piss poor at getting a newbie started.

The existing documentation of systemd is extensive and well written
but indeed probably not very well suited to get you started learning
the various concepts of systemd.
Being scattered across dozens of man pages and blog posts doesnt't
help with that either.

What I really like about upstart back in the days was the
documentation they provided in the form of a cookbook:
https://upstart.ubuntu.com/cookbook/

I really miss something like that for systemd.

Re: [systemd-devel] Service activation

[Michael Biebl]

Am So., 13. Feb. 2022 um 17:01 Uhr schrieb Wols Lists
:
>
> On 13/02/2022 15:46, Mantas Mikulėnas wrote:
> > On Sun, Feb 13, 2022 at 1:09 PM Wols Lists  > > wrote:
> >
> > On 13/02/2022 09:54, Mantas Mikulėnas wrote:
> >  > On Sun, Feb 13, 2022 at 2:03 AM Wol  > 
> >  >  > >> wrote:
> >  >
> >  > More fun getting things to work ... :-)
> >  >
> >  > So I've got a service, scarletdme.service, which fires up my
> > db backend
> >  > for running interactively. However, I also need a socket
> > service for
> >  > remote connections.
> >  >
> >  > I've got the xinetd files, but if I'm running systemd, I want
> > to use
> >  > systemd :-)
> >  >
> >  > So I've written scarletdme.socket, and scarletdme@.service,
> > but the
> >  > more
> >  > I read, the more I don't understand ...
> >  >
> >  > Do I enable scarletdme.socket the same as anything else eg
> > "systemctl
> >  > enable scarletdme.socket"? How does it know the difference
> > between
> >  > scarletdme.service and scarletdme@.service? I get the
> > impression I need
> >  > to put something in the .socket file to make it use
> > scarletdme@ rather
> >  > than scarletdme?
> >  >
> >  >
> >  > If it's a 'nowait' socket (which is "[Socket] Accept=yes" in systemd
> >  > terms), then it will use the templated @.service, starting a new
> >  > instance for each "accepted" socket (i.e. instance per
> > connection). See
> >  > oidentd.socket for comparison.
> >  >
> >  > Otherwise (by default) it uses the non-templated service and
> > directly
> >  > gives it the "listening" socket, letting the service itself
> > handle accept().
> >  >
> > ??? Sorry, that's double dutch to me.
> >
> > Are you telling me that just copying the files into /lib/systemd/system
> > will enable them? That seems weird to me because it doesn't do it for
> > normal services afaik. (Or shouldn't I be copying it direct into
> > /lib/systemd/system? I just don't know ...)
> >
> >
> > No, I was not talking about any of that. You asked how systemd knows the
> > difference between dme.service and dme@.service.
>
> Let's rewind a moment. That was my SECOND question. That's one of the
> reasons I got confused, because my FIRST question WAS "how do I start
> scarletdme.socket?"
>
> So the answer to that is nice and simple,
> "systemctl enable/start scarletdme.socket"

no, you start a socket by "systemctl start". You enable a socket,
service, unit,... via "systemctl enable"

enable and start are different concepts.

> Now what I don't want is for scarletdme.socket to invoke
> scarletdme.service. How do I tell it that it is supposed to invoke
> scarletdme@.service? Or have I messed up naming conventions? Or what the
> hell is the proper way to do it?

Please read again what Mantas wrote. He explained all that rather nicely.

Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists

[Michael Biebl]

Am Do., 6. Jan. 2022 um 10:00 Uhr schrieb Mantas Mikulėnas :

> Grep your entire /etc for those interface names (starting with /etc/udev), 
> find out where they're defined, and remove them

Please also make sure to rebuild your initramfs after doing that.
Files from /etc/udev are usually embedded in the initramfs.

Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists

[Michael Biebl]

Am Mi., 5. Jan. 2022 um 13:50 Uhr schrieb Mantas Mikulėnas :
> It does, yes, but note this part:
>
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed 
> from eth2
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed 
> from eth3
>
> Here the kernel-assigned names (eth2, eth3) are being renamed to custom names 
> (eth4, eth5). That's not something systemd or udev does by default. It 
> suggests that you likely have old "70-persistent-net" udev rules (or 
> something similar) that assign custom eth* names separately from the 
> slot-based "predictable" naming – perhaps a leftover from Debian 7.
>
> These interfaces aren't being skipped due to an earlier conflict – they are 
> intentionally skipped by 80-net-setup-link.rules because they already have a 
> custom 'NAME=' assigned by an earlier rule, so the "predictable" name is not 
> applied to avoid breaking existing configuration.

Yes, please check if you have a leftover file
/etc/udev/rules.d/70-persistent-net.rules
See also the relevant NEWS entry in /usr/share/doc/udev/NEWS.Debian.gz

systemd (220-7) unstable; urgency=medium

  The mechanism for providing stable network interface names changed.
  Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules
  which mapped device MAC addresses to the (arbitrary) name they got when
  they first appeared (i. e. mostly at the time of installation). As this
  had several problems and is not supported any more, this is deprecated in
  favor of the "net.ifnames" mechanism. With this most of your network
  interfaces will get location-based names. If you have ifupdown, firewall,
  or other configuration that relies on the old names, you need to update
  these by Debian 10/Ubuntu 18.04 LTS, and then remove
  /etc/udev/rules.d/70-persistent-net.rules. Please see
  /usr/share/doc/udev/README.Debian.gz for details about this.

 -- Martin Pitt   Mon, 15 Jun 2015 15:30:29 +0200

Re: [systemd-devel] [RFC] Switching to OpenSSL 3?

[Michael Biebl]

For some reason I sent this message to Lennart only back then, which
wasn't my intention.
Re-sending it to the mailing list.

Am Do., 16. Sept. 2021 um 19:25 Uhr schrieb Michael Biebl :
>
> Hi Lennart, hi everyone!
>
> First, a couple of remarks regarding the Debian package:
> So far, I tried to avoid enabling any OpenSSL dependent features (e.g.
> repart) for the simple reason that I didn't want to pull in two SSL
> stacks into systemd  (we already enable GnuTLS related bits).
> Consolidating around a single SSL library will definitely make this simpler.
>
> W.r.t. to OpenSSL 3: There is currently a package in experimental [1].
> It's possible/very likely, that its maintainer will start a transition
> to OpenSSL 3 during the bookworm development cycle, which just started
> now.
> But there hasn't been any official announcement yet in that regard.
> And given the size of the transition, I don't expect this to be
> trivial [2]. I also don't expect that there will be any efforts to
> make OpenSSL 1 and 3 co-installable.
> This also means, that it is highly unlikely that there will be a
> backport of OpenSSL for bullseye, our current stable release.
>
> This brings me to the next point: backports
>
> I typically provide backports of newer systemd versions for the
> current stable release. (I did this for jessie, stretch and buster)
> and I planned to do that for bullseye as well.
> Mainly for two reasons: popular demand and it also proved to be useful
> when filing upstream bug reports. With systemd's rather strict
> requirement to only accept bug reports for the last 2 releases, it is
> much easier for me to convince users to install a systemd backport
> then upgrading their stable system to unstable.
>
> Not being able to provide this service to users for the next 2 years
> is not the end of the world, but it's a bit of a nuisance. For the
> second part, maybe upstream could be a bit more lenient to accept such
> bug reports with older systemd versions during the transition to
> OpenSSL 3?
>
> Last but not least: The licensing issue brought up by Luca regarding
> the GPLv2 incompatibility. This is very unfortunate and I haven't
> really checked if and how that affects rdeps of libsystemd0. Maybe
> Luca already did that work. In this case, I'd be very interested in
> his feedback here.
>
> Using GnuTLS would avoid all that afaics, no?
>
> Just curious: Can you elaborate why GnuTLS only is not an option.
>
> Regards,
> Michael
>
> [1] 
> https://tracker.debian.org/news/1257327/accepted-openssl-300-1-source-into-experimental/
> [2] https://release.debian.org/transitions/html/auto-openssl.html
>
> Am Di., 14. Sept. 2021 um 13:36 Uhr schrieb Lennart Poettering
> :
> >
> > Heya!
> >
> > Some of the systemd developers have been discussing switching
> > systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop
> > support for older OpenSSL versions, as well as any GNUTLS/libgcrypt
> > support. As you might have noticed OpenSSL 3.0 has been released
> > recently, and for the first time resolves the GPL2 license
> > incompatibility mess comprehensively, which opens this door to us.
> >
> > I personally care a lot about reducing the combinatorial explosion of
> > deps a bit, and keeping our tree as maintainable as we can, with a
> > single implementation of everything, not multiple, and no abstraction
> > layers and such, and thus removing any compat kludges for other
> > libraries or other library versions.
> >
> > Now, before we make a decision on this, I'd like to collect feedback
> > on such a move. I know that there are some people who backpart new
> > systemd onto old distros. How big would the pain be require porting
> > OpenSSL 3, too, at the same time?
> >
> > (What's not up for discussion: for new additions to systemd we'll do
> > only OpenSSL, and won't accept anything else. My question is really
> > just about the stuff we aleady have, where we currently support
> > GNUTLS/libcgrypt.).
> >
> > Anyway, I'd be interested in your thoughts about this. i.e. hear
> > multiple takes, opinions, from differently people and positions?
> >
> > Thanks,
> >
> > Lennart

Re: [systemd-devel] [EXT] Re: Output from `tee' is not showing up in system journal consistently on some systems

[Michael Biebl]

Might be another instance of
https://github.com/systemd/systemd/issues/2913

You can verify by checking your whole journal, not just "-u tee_test.service".

Am Do., 28. Okt. 2021 um 21:54 Uhr schrieb Mitchel Humpherys
:
>
> On Thu, Oct 28, 2021 at 12:35 AM Ulrich Windl
>  wrote:
> >
> > ANother random idea: Did you experiment with tee option 
> > "--output-error=..."?
>
> Just gave that a shot and didn't get any additional output :(

Re: [systemd-devel] Xorg or Wayland Environment

[Michael Biebl]

Just curious:

Can someone familiar with KDE/Plasma tell us, if they nowadays (can)
use "systemd --user" to manage a login session.


Am Di., 21. Sept. 2021 um 12:52 Uhr schrieb Ed Greshko :
>
> On 21/09/2021 18:20, Colin Guthrie wrote:
> > Ed Greshko wrote on 19/09/2021 12:11:
> >> OK..
> >>
> >> I think I see the problem now.  I don't need Environment=.  But the issue 
> >> is that, I assumed, "plasma-core.target" would be
> >> reached only after a user logged in to plasma.
> >>
> >> I was wrong and the user's service is run earlier when the login screen 
> >> appears.
> >
> > I'm slightly confused by the logic here. Why is a user's systemd even 
> > running before they've logged in? If the user has lingering enabled, then 
> > it might have a systemd instance from that, but it certainly shouldn't 
> > reach any plasma-core.target as the login GUI should be running as a 
> > different user to your user I would have thought?
> >
> > e.g. under gnome, the login GUI runs as the "gdm" user. That user has a 
> > systemd --user instance, and runs various things but only once a real user 
> > has logged in will it's own systemd instance start and reach the 
> > appropriate targets.
> >
> >> I need to find a way such that the service only runs when a user logs on 
> >> to the plasma GUI.
> >
> > It seems a bit odd to me that your users' plasma-core.target has been run 
> > when your user hasn't even logged in yet. I think something is odd there, 
> > possible combined with user lingering and perhaps plasma-core being the 
> > default target for your user when it shouldn't be...
> >
> > Hope this helps you debug things.
>
> Yes, that helped.
>
> plasma-core.target isn't the correct target.  I switched to 
> graphical-session.target.
>
> I believe one issue remains.
>
> On login, after a reboot, the app is started.  And, on logout the app is 
> terminated.
>
> The issue is that if the user logs out and logs back in the service is not 
> run.
>
> How to make sure the service is run each time the user logs in?
>
>

Re: [systemd-devel] Xorg or Wayland Environment

[Michael Biebl]

Am So., 19. Sept. 2021 um 15:48 Uhr schrieb Ed Greshko :
>
> On 19/09/2021 21:39, Michael Biebl wrote:
>
> A useful command in this context is
>
> systemctl --user show-environment
>
>
> OK, that was helpful.  But leads to another question.
>
> How to run the service only if KDE_FULL_SESSION=true?

I have no idea what that is, sorry. I'm not really familiar with KDE/Plasma

Re: [systemd-devel] Xorg or Wayland Environment

[Michael Biebl]

A useful command in this context is

systemctl --user show-environment

Am So., 19. Sept. 2021 um 11:53 Uhr schrieb Mantas Mikulėnas
:
>
> On Sun, Sep 19, 2021 at 4:05 AM Ed Greshko  wrote:
>>
>> Not a everyday systemd service writer
>>
>> I've written a user service file to start an app on login.  It works well 
>> for Xorg with Environment=DISPLAY=:0.
>>
>> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg and 
>> login to a
>> Wayland session.
>>
>> What would be the proper way to get the DISPLAY environment varible use it 
>> as opposed
>> to "hard" coding it?
>
>
> The proper way is to have the desktop environment upload DISPLAY (and 
> whatever else is relevant, such as XAUTHORITY or WAYLAND_DISPLAY or 
> XDG_SESSION_TYPE) into systemd --user, so that it would be automatically 
> available to your service without doing anything special.
>
> For example, gnome-session does this for GNOME (it calls systemd's 
> UnsetAndSetEnvironment in gsm-util.c), and 
> /etc/X11/xinit/xinitrc.d/50-systemd-user.sh handles the bare minimum for 
> other Xorg-based desktops (when startx is used).
>
> If KDE integrates with systemd --user in any way (i.e. if it actually has a 
> "plasma-core.target" that you mention), I'd really expect it to do the same 
> before it tries to start its own targets, otherwise they would be kind of 
> useless.
>
> --
> Mantas Mikulėnas

Re: [systemd-devel] Xorg or Wayland Environment

[Michael Biebl]

You don't hard-code it, you just use it?

In your case, since you have a user service which appears bound to the
lifetime of a graphical (X/Wayland) session, I guess
graphical-session.target is what you want.
See man systemd.special.

So far, I think only GNOME implements graphical-session.target though.

Am So., 19. Sept. 2021 um 03:05 Uhr schrieb Ed Greshko :
>
> Not a everyday systemd service writer
>
> I've written a user service file to start an app on login.  It works well for 
> Xorg with Environment=DISPLAY=:0.
>
> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg and 
> login to a
> Wayland session.
>
> What would be the proper way to get the DISPLAY environment varible use it as 
> opposed
> to "hard" coding it?

Re: [systemd-devel] [hostnamed] Why the service will automatically exit after 30 seconds

[Michael Biebl]

Am Mi., 18. Aug. 2021 um 03:35 Uhr schrieb 李成刚 :
>
> How to configure this service so that it will not automatically exit

You can't. The exit-on-idle timeout of 30s is hard-coded.

Re: [systemd-devel] Antw: [EXT] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured

[Michael Biebl]

How exactly do you rename your interfaces? Do you use a udev rule? Can
you post those scripts/rules?

Re: [systemd-devel] Resource ( systemd )

[Michael Biebl]

There is no such property in .service units.

What you might do is have .path unit which monitors your python script
and triggers a restart.service which restarts server.service


Am Mi., 14. Juli 2021 um 04:38 Uhr schrieb Webstrucs :
>
> I'm developing a web server in python that is referenced in the path inside a 
> systemd service ( server.service ). In the path that points to the execution 
> of the python file it works without problems but when I make any changes in 
> this file it is necessary to restart the file in order to get the updates. Is 
> there any way to implement a property in (server.service) of the type 
> (autosave) so that you no longer need to use restarting the service when 
> there are changes in the related file in python ?
>
> Att,
> João Aguiar
> ___
> 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] Adding USB ID to hwdb/usb.ids

[Michael Biebl]

Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH :
> Works for me!  Make sure you are not trying to connect to 'https'.

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

Re: [systemd-devel] minimum required meson version bump?

[Michael Biebl]

Am Do., 13. Mai 2021 um 19:15 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> Hi,
> we're considering bumping the meson version from the current 0.46 to
> something more recent (0.52 or 0.53…). Ubuntu Biionic 18.04 has 0.45, so
> it is below the cutoff point already. Focal 20.04 has 0.53.2.
> Would this be a problem for anyone?

Thanks for asking. No problem from the Debian PoV.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Michael Biebl]

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Michael Biebl]

Am Sa., 1. Mai 2021 um 08:44 Uhr schrieb Luca Boccassi
:
>
> On Fri, 30 Apr 2021 at 22:15, Michael Biebl  wrote:
> >
> > I wonder if you have a dependency loop somewhere and systemd resolves
> > this by removing that ordering.
>
> As mentioned earlier, I strongly suspect systemd-tmpfiles-setup.service - I 
> had the same issue, because my /var/log partition is also not mounted in the 
> initramfs for $reasons, so it appears late at boot.
> I'd suggest again to try and override it.

I guess my point is, that before trying to suggest solutions, we
should understand what the underlying problem is first.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Michael Biebl]

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.


fstab
Description: Binary data


journal.txt.gz
Description: application/gzip


systemd-analyze.dump.txt.gz
Description: application/gzip
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Michael Biebl]

Am Fr., 30. Apr. 2021 um 19:42 Uhr schrieb Rick Winscot
:
>
> systemd 247

Ok, thanks

> /etc/systemd/journald.conf storage is persistent, 
> systemd-journal-flush.service has RequiresMountsFor=/var/log/journal.
>
> Mounting /var on a separate read-write partition handles the persistent log 
> requirement as well as offloading other read-write operations that can no 
> longer live on the rootfs... being read-only.

Sure, but what is the actual problem? I do have systems with a
separate /var and don't remember any ordering issues / race
conditions.
Do you have any error messages / journal logs which show the issue?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] early mounts in systemd

[Michael Biebl]

What is the actual problem you have with a separate /var and systemd-journald?
For completeness sake, which systemd version do you have?

Am Fr., 30. Apr. 2021 um 16:39 Uhr schrieb Rick Winscot
:
>
> We have an embedded product that uses a minimal Linux distribution generated 
> via Buildroot.
>
> Early in the project it was decided to make the rootfs read-only... in an 
> effort to improve durability in environments where power fluctuations might 
> cause problems on the eMMC. At the same time, making logging (e.g. /var) 
> persistent for debugging was added to requirements. Persistent storage would 
> be achieved by mounting /var to a separate partition that is read-write.
>
> Several-hundred hours later... with many systemd-analyze reports and various 
> configurations tested, we have determined that managing the /var mount with 
> stadard services is not going to work due to tightly coupled and precisely 
> timed dependencies. Attempts with /etc/fstab and the systemd generator are 
> also unstable.
>
> Getting /var mounted in proximity to the initialization of 
> systemd-journald.service seemed illusive.
>
> Several days ago I found a post on Stackoverflow that tied into udev triggers 
> that seemed promising; resulting in the method outlined below. Initial 
> testing shows proper timing with all dependencies satisfied. However, the 
> solution feels... hackey.
>
> My question for anyone on the list, is the method outlined below a reasonable 
> solution to mounting /var early in the start-up cycle?
>
> Or... is there a better way? Some trimming
>
>
> Step One: Create a systemd service that mounts /var to the specified partition
> Service:  /etc/systemd/system/var.service
>
> [Unit]
> Description=service for mounting /var
> DefaultDependencies=no
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/mount /dev/mmcblk0p6
>
>
> Step Two: Add a nofail mount
> fstab:/etc/fstab
>
> /dev/root / auto rw 0 1
> /dev/mmcblk0p6 /var ext4 rw,nofail 0 0
>
>
> Step Three: Add a wants dependency on the mount in udev triggers (some lines 
> deleted for brevity)
> Service:/usr/lib/systemd/system/systemd-udev-trigger.service
>
> [Unit]
> ...
> Wants=systemd-udevd.service var.service
>
> [Service]
> ...
> ExecStart=udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm 
> trigger
>
>
> Finally, systemd-analyze plot shows that the mount works as desired.
>
> systemd-udev-trigger.service
> var.service
> dev-mmcblk0p6.device
> var.mount
> 
> systemd-remount-fs.service
> systemd-journal-flush.service
> local-fs-pre.target
> 
> ___
> 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] bitcoind.service activation problem

[Michael Biebl]

I guess it's ok to ask such question on this mailing list, as it is
rather low traffic.

That said, more details are always better. So instead of a screenshot,
include a full copy of the service files and the full status and/or
journalctl -u bitcoind.service output.

This is either a configuration problem or the service file does not
have the proper Type=

Am Sa., 10. Apr. 2021 um 15:36 Uhr schrieb Tomasz Torcz :
>
> Dnia Sat, Apr 10, 2021 at 05:39:34PM +0600, Shafiun Miraz napisał(a):
> > [image: image.png]
> > [image: image.png]
> > I am getting this error. Please someone help me!
>
>   Hey Shafiun, couple of notes:
>
> - sending screenshots is not helpful, please just copy the message next
>   time;
>
> - there are no actual information why bitcoind.service is not starting.
>   Use "systemctl status bitcoind" to see more information and logs
>   related to the bitcoind.service. You can also use
>   "journalctl -u bitcoind.service" to see full logs.
>
>   I expect startup problem is connected to bitcoind's configuration, but
>   without logs it's only guesswork.
>
> - finally, this is not a correct place to get support. Please open a bug
>   with your Linux Distribution and ask them to replace systemd-devel URL
>   with real support address (bugzilla, forum, github issues etc.).
>   This way users will get quicker support in the future.
>
> --
> Tomasz TorczOnly gods can safely risk perfection,
> to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
>
> ___
> 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] is such a 'failed' state?

[Michael Biebl]

Am So., 28. März 2021 um 21:19 Uhr schrieb lejeczek :
>   Main PID: 922 (code=exited, status=0/SUCCESS)

[..]

> Restart=on-failure

The service terminated with a zero exit code and you use Restart=on-failure.
A zero exit code is not treated as failure.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is LTO worth it?

[Michael Biebl]

Am Mo., 11. Jan. 2021 um 18:26 Uhr schrieb Reindl Harald
:
> Am 11.01.21 um 18:10 schrieb Michael Biebl:
> > Am Mo., 11. Jan. 2021 um 18:07 Uhr schrieb Reindl Harald
> > :
> >> it don't make sense using different flags in CI and production builds,
> >> especially LTO which often points out otherwise unvisible bugs
> >
> > Such as? I don't remember any bug report which was uncovered by LTO
> > being enabled
>
> buggy code not always leads to visble bugs with reports, the warnings
> typically increase with LTO

So I guess no definite bug reports then. Ok.

> and https://www.avrfreaks.net/forum/compiler-bug-lto-only shows why it's
> nonsense to run CI with different flags than final builds
>
> however the whole topic and "we've been using LTO in the Debian build
> for as long as I can remember, but I begin to question whether that is a
> good idea" in 2021 is very strange given that more or less the whole
> world goe sinto LTO for everything direction

Really?

Anyway, I appreciate your contribution regarding lto=, but let's
leave it at that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is LTO worth it?

[Michael Biebl]

Am Mo., 11. Jan. 2021 um 18:10 Uhr schrieb Michael Biebl :
>
> Am Mo., 11. Jan. 2021 um 18:07 Uhr schrieb Reindl Harald
> :
> > it don't make sense using different flags in CI and production builds,
> > especially LTO which often points out otherwise unvisible bugs
>
> Such as? I don't remember any bug report which was uncovered by LTO
> being enabled.

That said, it would probably be sufficient if only parts of the
available runners enable lto and the rest doesn't.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is LTO worth it?

[Michael Biebl]

Am Mo., 11. Jan. 2021 um 18:07 Uhr schrieb Reindl Harald
:
> it don't make sense using different flags in CI and production builds,
> especially LTO which often points out otherwise unvisible bugs

Such as? I don't remember any bug report which was uncovered by LTO
being enabled.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is LTO worth it?

[Michael Biebl]

Am Mo., 11. Jan. 2021 um 16:39 Uhr schrieb Lennart Poettering
:
> https://fedoraproject.org/wiki/LTOByDefault

Interestingly, that wiki page says, that LTO should produce smaller
binaries, which clearly isn't the case here.
I wonder whether the wiki is incorrect or whether this is a toolchain
issue or if this is specific to systemd
Or maybe this is Debian specific. Would be interested to see numbers
from other distros.

Concerning the build speed: I wonder whether at least disabling LTO on
our CI would make sense. We don't really care for fast/small
executables there.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is LTO worth it?

[Michael Biebl]

Am Mo., 11. Jan. 2021 um 16:12 Uhr schrieb Reindl Harald
:
> export LDFLAGS="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -pie %{optflags}
> -flto=%(nproc)"
> %meson

Thanks for the hint. I tried it, but it didn't really help.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is LTO worth it?

[Michael Biebl]

Am Mo., 11. Jan. 2021 um 15:42 Uhr schrieb Reindl Harald
:
> it shouldn't if properly used - means param with cpu-cores, just -flto
> alone is terrible slow
>
> -flto=%(nproc)
> %{__make} %{?_smp_mflags}

The package uses meson's -Db_lto=true
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Is LTO worth it?

[Michael Biebl]

Hi,

we've been using LTO in the Debian build for as long as I can
remember, but I begin to question whether that is a good idea.
On Debian sid (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU
Binutils for Debian) 2.35.1),
an LTO build almost takes twice as long as a no-LTO build.
I also debdiffed the produced binary and LTO seems to produce bigger
binaries as well.
Most noticably (sizes in kB)
udev  9287 vs 8971
systemd 14755 vs 15998

LTO manages to strip some library dependencies here and there, but
that's about it.
Attached is a full debdiff output
$ debdiff no-lto/systemd_247.2-4_amd64.changes
lto/systemd_247.2-4_amd64.changes | colordiff
File lists identical (after any substitutions)

Control files of package libnss-myhostname: lines which differ (wdiff format)
-
Depends: libc6 (>= [-2.30), libselinux1 (>= 3.1~)-] {+2.30)+}
Installed-Size: [-265-] {+233+}

Control files of package libnss-mymachines: lines which differ (wdiff format)
-
Depends: libc6 (>= 2.30), [-libcap2 (>= 1:2.24-9~), libselinux1 (>=
3.1~),-] systemd-container (= 247.2-4)
Installed-Size: [-499-] {+419+}

Control files of package libnss-resolve: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.30), [-libselinux1 (>= 3.1~),-] systemd (= 247.2-4)
Installed-Size: [-277-] {+237+}

Control files of package libnss-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.30), [-libcrypt1 (>= 1:4.1.0), libselinux1 (>=
3.1~),-] systemd (= 247.2-4)
Installed-Size: [-417-] {+361+}

Control files of package libpam-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.30), [-libcap2 (>= 1:2.24-9~), libcrypt1 (>=
1:4.1.0),-] libpam0g (>= 0.99.7.1), [-libselinux1 (>= 3.1~),-] systemd
(= 247.2-4), libpam-runtime (>= 1.0.1-6), dbus, systemd-sysv
Installed-Size: [-673-] {+573+}

No differences were encountered between the control files of package
libsystemd-dev

Control files of package libsystemd0: lines which differ (wdiff format)
---
Installed-Size: [-963-] {+863+}
Pre-Depends: libc6 (>= 2.30), [-libcap2 (>= 1:2.24-9~),-] libgcrypt20
(>= 1.8.0), liblz4-1 (>= 0.0~r122), liblzma5 (>= 5.1.1alpha+20120614),
[-libselinux1 (>= 3.1~),-] libzstd1 (>= 1.4.0)

No differences were encountered between the control files of package libudev-dev

Control files of package libudev1: lines which differ (wdiff format)

Depends: libc6 (>= [-2.30), libselinux1 (>= 3.1~)-] {+2.30)+}
Installed-Size: [-332-] {+280+}

Control files of package libudev1-udeb: lines which differ (wdiff format)
-
Installed-Size: [-213-] {+161+}

Control files of package systemd: lines which differ (wdiff format)
---
Depends: {+libacl1 (>= 2.2.23),+} libapparmor1 (>= 2.13), libaudit1
(>= 1:2.2.1), {+libcap2 (>= 1:2.24-9~),+} libcrypt1 (>= 1:4.4.0),
libcryptsetup12 (>= 2:2.3), libgnutls30 (>= 3.7.0), libgpg-error0 (>=
1.14), libip4tc2 (>= 1.8.3), libkmod2 (>= 5~), liblz4-1 (>= 0.0~r130),
{+libmount1 (>= 2.30),+} libpam0g (>= 0.99.7.1), libseccomp2 (>=
2.4.1), libsystemd0 (= 247.2-4), systemd-timesyncd | time-daemon,
util-linux (>= 2.27.1), mount (>= 2.26), adduser
Installed-Size: [-14755-] {+15998+}
Pre-Depends: [-libacl1 (>= 2.2.23),-] libblkid1 (>= 2.24), libc6 (>=
2.30), [-libcap2 (>= 1:2.24-9~),-] libgcrypt20 (>= 1.8.0), liblz4-1
(>= 0.0~r122), liblzma5 (>= 5.1.1alpha+20120614), [-libmount1 (>=
2.30),-] libselinux1 (>= 3.1~), libzstd1 (>= 1.4.0)

Control files of package systemd-container: lines which differ (wdiff format)
-
Installed-Size: [-1230-] {+1214+}

No differences were encountered between the control files of package
systemd-coredump

Control files of package systemd-journal-remote: lines which differ
(wdiff format)
--
Installed-Size: [-333-] {+329+}

No differences were encountered between the control files of package
systemd-sysv

Control files of package systemd-tests: lines which differ (wdiff format)
-
Depends: libacl1 (>= 2.2.23), libapparmor1 (>= 2.13), libaudit1 (>=
1:2.2.1), libblkid1 (>= 2.24), libc6 (>= 2.30), libcap2 (>=
1:2.24-9~), libdbus-1-3 (>= 1.9.14), libgcrypt20 (>= 1.8.0),
libglib2.0-0 (>= 2.26.0), libgpg-error0 (>= 1.14), {+libip4tc2 (>=
1.8.3),+} libkmod2 (>= 5~), liblz4-1 

Re: [systemd-devel] SystemD dependency problem

[Michael Biebl]

In addition to what Mantas said, I'd suggest reading man systemd.special.
and https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

This should give you an idea what network-online.target is supposed to be.
It's not a target to hook arbitrary services into (via WantedBy).
Your service looks like multi-user.target is a better fit.

Stuff like NetworkManager-wait-online.service or
systemd-networkd-wait-online.service is something which should hook
into network-online.target via WantedBy.


Am Di., 22. Dez. 2020 um 14:17 Uhr schrieb Mantas Mikulėnas :
>
> On Tue, Dec 22, 2020 at 1:36 PM Ronald Wimmer  wrote:
>>
>> On a server running OL 7.9 with SystemD 219 we have a custom SystemD
>> service we have something like
>>
>>
>> [Unit]
>> Requires=network.target docker.service
>>
>> [Service]
>> Restart=always
>> RestartSec=10
>> TimeoutSec=300
>> WorkingDirectory=/data/someapplication
>> ExecStartPre=
>> ExecStart=
>> ExecStop=
>> ExecStopPost=
>>
>> [Install]
>> WantedBy=network-online.target
>>
>> which does not work. This service leads do several other services
>> (rsyslogd, docker, network-online.target, ...) to be stuck in "start
>> waiting".
>>
>> My question is why? Is there any obvious misconfiguration in the service
>> above I am too blind to see?
>
>
> As a special case, when a target has Wants= for some unit, it will 
> automatically add an After= as well. (So from your unit's point of view, you 
> have [Install] WantedBy=network-online.target, so you can imagine that you 
> automatically have a Before=network-online.target as well – unless you 
> explicitly specify the opposite.)
>
> However, Docker has "After=network-online.target", so you end up creating an 
> ordering loop:
>
> * yourthing.service has no After=, but it runs `docker` commands and cannot 
> finish until docker.service is up;
> * docker.service explicitly has After=network-online.target and won't start 
> until that target is reached;
> * but network-online.target has an implicit After=yourthing.service (as 
> explained above).
>
> --
> Mantas Mikulėnas
> ___
> 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] Help with Systemd + Apache 2.4 - CentOS 7

[Michael Biebl]

Am Mo., 23. Nov. 2020 um 02:33 Uhr schrieb Lucas Possamai
:
>
> Hi,
>
> I have Apache 2.4.6-93 running on a CentOS 7.8.2003 that is not starting 
> using Systemd.
>
> If I do: systemctl start httpd, I get the following error:
>
> Nov 22 20:14:11 localhost systemd[1]: Failed to start The Apache HTTP Server.
> -- Subject: Unit httpd.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit httpd.service has failed.
> --
> -- The result is failed.
>
>
> However, running 'httpd -k start' works!
>
> /usr/lib/systemd/system/httpd.service:
>
> [Unit]
> Description=The Apache HTTP Server
> After=network.target remote-fs.target nss-lookup.target
> Documentation=man:httpd(8)
> Documentation=man:apachectl(8)
>
> [Service]
> Type=notify

Are you sure that apache2 supports sd_notify?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prerelease 247-rc2

[Michael Biebl]

Am Do., 12. Nov. 2020 um 18:13 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:

> The tags change is probably limited in effect, and the lack of handling
> of "bind" in rules will be more important. But, as you said, that change
> was already happening since kernel 4.2. So it's possible that the biggest
> effect is that with our announcement more people will notice that things
> are not working as expected. I think it's safe to push 247 to users, but
> be prepared for some bug reports.

Unfortunately I wasn't so lucky and my X session got killed during the
update from v246 to v247 (along with other services that had BindsTo=
afaics)

I've filed https://github.com/systemd/systemd/issues/17605 for now
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prerelease 247-rc2

[Michael Biebl]

Hi there

Am Do., 12. Nov. 2020 um 11:58 Uhr schrieb systemd tag bot
:
>
> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
> tarball here:
>
> https://github.com/systemd/systemd/archive/v247-rc2.tar.gz

Congrats to the new release!

> Changes since the previous release:
>
> * KERNEL API INCOMPATIBILITY: Linux 4.12 introduced two new uevents
>   "bind" and "unbind" to the Linux device model. When this kernel
>   change was made, systemd-udevd was only minimally updated to handle
>   and propagate these new event types. The introduction of these new
>   uevents (which are typically generated for USB devices and devices
>   needing a firmware upload before being functional) resulted in a
>   number of issues which we so far didn't address. We hoped the kernel
>   maintainers would themselves address these issues in some form, but
>   that did not happen. To handle them properly, many (if not most) 
> udev
>   rules files shipped in various packages need updating, and so do 
> many
>   programs that monitor or enumerate devices with libudev or 
> sd-device,
>   or otherwise process uevents. Please note that this incompatibility
>   is not fault of systemd or udev, but caused by an incompatible 
> kernel
>   change that happened back in Linux 4.12, but is becoming more and
>   more visible as the new uevents are generated by more kernel 
> drivers.
>
>   To minimize issues resulting from this kernel change (but not avoid
>   them entirely) starting with systemd-udevd 247 the udev "tags"
>   concept (which is a concept for marking and filtering devices during
>   enumeration and monitoring) has been reworked: udev tags are now
>   "sticky", meaning that once a tag is assigned to a device it will 
> not
>   be removed from the device again until the device itself is removed
>   (i.e. unplugged). This makes sure that any application monitoring
>   devices that match a specific tag is guaranteed to both see uevents
>   where the device starts being relevant, and those where it stops
>   being relevant (the latter now regularly happening due to the new
>   "unbind" uevent type). The udev tags concept is hence now a concept
>   tied to a *device* instead of a device *event* — unlike for example
>   udev properties whose lifecycle (as before) is generally tied to a
>   device event, meaning that the previously determined properties are
>   forgotten whenever a new uevent is processed.
>
>   With the newly redefined udev tags concept, sometimes it's necessary
>   to determine which tags are the ones applied by the most recent
>   uevent/database update, in order to discern them from those
>   originating from earlier uevents/database updates of the same
>   device. To accommodate for this a new automatic property 
> CURRENT_TAGS
>   has been added that works similar to the existing TAGS property but
>   only lists tags set by the most recent uevent/database
>   update. Similarly, the libudev/sd-device API has been updated with
>   new functions to enumerate these 'current' tags, in addition to the
>   existing APIs that now enumerate the 'sticky' ones.
>
>   To properly handle "bind"/"unbind" on Linux 4.12 and newer it is
>   essential that all udev rules files and applications are updated to
>   handle the new events. Specifically:
>
>   • All rule files that currently use a header guard similar to
> ACTION!="add|change",GOTO="xyz_end" should be updated to use
> ACTION=="remove",GOTO="xyz_end" instead, so that the
> properties/tags they add are also applied whenever "bind" (or
> "unbind") is seen. (This is most important for all physical device
> types — those for which "bind" and "unbind" are currently
> generated, for all other device types this change is still
> recommended but not as important — but certainly prepares for
> future kernel uevent type additions).
>
>   • Similarly, all code monitoring devices that contains an 'if' 
> branch
> discerning the "add" + "change" uevent actions from all other
> uevents actions (i.e. considering devices only relevant after 
> "add"
> or "change", and irrelevant on all other events) should be 
> reworked
> to instead negatively check for "remove" only (i.e. considering
> devices relevant after all event types, except for "remove", which
> invalidates the device). Note that this also means that devices
> should be considered relevant on "unbind", even though 
> conceptually
> this — in some form — 

Re: [systemd-devel] ssh.service in rescue.target

[Michael Biebl]

Am Mo., 9. Nov. 2020 um 18:25 Uhr schrieb Michael Biebl :
> I guess this is kinda moot now, given that the initscripts package was
> completely removed in Ubuntu 20.10 it seems.
> Fwiw, I'd be surprised if there really are any packages in 20.04 still
> depending on initscripts.
> Maybe just purge the package (remove is not sufficient, initscripts
> being conffiles and all)

Hm, I guess Ubuntu has dropped the initscripts package for much longer already:

At least since bionic:

+sysvinit (2.88dsf-59.10ubuntu1) bionic; urgency=medium
+
+  * Merge with Debian, restoring 6ac609340af19a8d021c5ab8fea50c65241d1d0b:
+- When building for Ubuntu, skip all binaries except for sysvinit-utils.
+
+ -- Adam Conrad   Wed, 01 Nov 2017 15:00:29 -0600

So, Phillip, if you still have an initscripts package installed on
20.04, this is a left-over from previous dist-upgrades.

Purge the package (along with sysv-rc etc, in case you still have them
installed)

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

Re: [systemd-devel] ssh.service in rescue.target

[Michael Biebl]

Am Mo., 9. Nov. 2020 um 18:20 Uhr schrieb Michael Biebl :
>
> Am Mo., 9. Nov. 2020 um 17:12 Uhr schrieb Simon McVittie :
> >
> > On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote:
> > > I guess I'll try masking it.
> >
> > The Debian/Ubuntu package for systemd already masks various services
> > that are superseded by something in systemd, such as procps.service and
> > rcS.service. It used to also mask all the services from initscripts,
> > but that seems to have been dropped in version 243-5.
> >
> > systemd-sysv-generator (which generates systemd service units corresponding
> > to sysv-rc services) has stopped generating units for sysv-rc services that
> > run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to
> > rescue.target). killprocs runs in rc1.
> >
> > Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services
> > like killprocs, or perhaps the initscripts package should take over
> > responsibility for masking rc1 services that it ships if they are not
> > applicable to systemd,
>
> https://tracker.debian.org/news/874168/accepted-sysvinit-288dsf-5910-source-into-unstable/
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874685
>
> Masking those SysV init specific services was moved to initscripts a
> long time ago (before I dropped those masks from the systemd package).
>
> Obviously I can't speak for the Ubuntu package

I guess this is kinda moot now, given that the initscripts package was
completely removed in Ubuntu 20.10 it seems.
Fwiw, I'd be surprised if there really are any packages in 20.04 still
depending on initscripts.
Maybe just purge the package (remove is not sufficient, initscripts
being conffiles and all)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] ssh.service in rescue.target

[Michael Biebl]

Am Mo., 9. Nov. 2020 um 17:12 Uhr schrieb Simon McVittie :
>
> On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote:
> > I guess I'll try masking it.
>
> The Debian/Ubuntu package for systemd already masks various services
> that are superseded by something in systemd, such as procps.service and
> rcS.service. It used to also mask all the services from initscripts,
> but that seems to have been dropped in version 243-5.
>
> systemd-sysv-generator (which generates systemd service units corresponding
> to sysv-rc services) has stopped generating units for sysv-rc services that
> run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to
> rescue.target). killprocs runs in rc1.
>
> Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services
> like killprocs, or perhaps the initscripts package should take over
> responsibility for masking rc1 services that it ships if they are not
> applicable to systemd,

https://tracker.debian.org/news/874168/accepted-sysvinit-288dsf-5910-source-into-unstable/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874685

Masking those SysV init specific services was moved to initscripts a
long time ago (before I dropped those masks from the systemd package).

Obviously I can't speak for the Ubuntu package
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] ssh.service in rescue.target

[Michael Biebl]

Am Fr., 6. Nov. 2020 um 22:31 Uhr schrieb Phillip Susi :
>
>
> Lennart Poettering writes:
>
> > Are you running systemd? If so, please get rid of "killproc". It will
> > interfere with systemd's service management.
>
> I see.. apparently Ubuntu still has it around.

Are you sure?
Which Ubuntu version is that?
At least in Debian, /etc/init.d/killprocs is shipped by "initscripts"
which is no longer installed by default.
___
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

[Michael Biebl]

Am Mo., 19. Okt. 2020 um 15:56 Uhr schrieb Lennart Poettering
:
>
> >   2) Could resolved be changed so that this message is only emitted
> > (say) once for every 100 or 500 times that the condition is
> > detected.
>
> We actually try hard to suppress unnecessary log lines, but I think
> this one is a downstream change.
>


https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch?h=ubuntu/focal-updates

Bringing Dimitri into the loop here.

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

Re: [systemd-devel] journald forwarding to rsyslogd. Huge (350 times) performance degradation. What am I doing wrong???

[Michael Biebl]

Hm, some performance penalty is certainly expected but 350times slower
looks like something is odd.
Would be interesting to know, if you can reproduce the performance
issue with a more recent version.
Afaik, using imuxsock and syslog forwarding should be more performant
then imjournal (which was suggested earlier).

You could configure systemd, to not do syslog forwarding and let
rsyslog handle syslog messages directly.
This has a few downsides though:
- syslog messages don't end up in the journal
- non-syslog messages from journald don't end up in your syslog, say
messages from systemd or services logging to stdout/stderr.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Enable sandboxing options globally for all services

[Michael Biebl]

Am Mi., 9. Sept. 2020 um 21:40 Uhr schrieb Christopher Wong
:
>
> Hi,
>
>
> Is there a way to turn on a sandboxing option for all services?

Recent versions of systemd allow to use global drop-in config
snippets. See the changelog of v244

* Unit files now support top level dropin directories of the form
  .d/ (e.g. service.d/) that may be used to add configuration
  that affects all corresponding unit files.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Need help with setting up systemd for Apache on Debian 10

[Michael Biebl]

Am So., 23. Aug. 2020 um 19:20 Uhr schrieb Tom Browder :

> I assume the data are correct, and I'm pretty sure there is some
> fancy, automated sysstemctl way to get it all working.  I would
> greatly appreciate some guidance as to how to install the files
> correctly.

Those files are installed correctly. What's your specific question?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] I/O error on "systemctl kill -s HUP rsyslog.service"

[Michael Biebl]

Am Do., 13. Aug. 2020 um 09:05 Uhr schrieb Andrei Borzenkov
:
>
> 13.08.2020 09:54, Harald Dunkel пишет:
> > On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
> >> 12.08.2020 14:03, Harald Dunkel пишет:
> >>> See attachment. Hope this helps
> >>> Harri
> >>
> >>
> >>> 1 openat(AT_FDCWD,
> >>> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
> >>> O_RDONLY|O_CLOEXEC) = 24
> >>> 1 read(24, "0\n1544456\n", 4096)= 10
> >>
> >>
> >> kernel returns "0" as process number in this cgroup which results in EIO
> >> returned by systemd.
> >
>
> systemd should really clearly log this (invalid PID and and in which
> cgroup it was). Returning generic error message without any indication
> what caused this error is not useful at all.

I agree. Could you file a github issue for this?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] : How to modify systemd so that the NTP function is disabled when systemd is first started?

[Michael Biebl]

Am Sa., 25. Apr. 2020 um 08:52 Uhr schrieb www :

> Apr 02 17:24:52 demoboard systemd[1]: System time before build time, 
> advancing clock.

See https://github.com/systemd/systemd/blob/master/src/core/main.c#L1485
or more specifically
https://github.com/systemd/systemd/blob/master/src/shared/clock-util.c#L145

If you want to change time_epoch, use the meson "time_epoch" build option.
time_epoch is currently derived frome the date, when the NEWS file was
last modified.
But you could set that to say 1.1.1970.


> Apr 02 17:25:02 demoboard systemd[1]: logrotate.timer: Not using persistent 
> file timestamp Sat 2020-04-25 13:45:26 CST as it is in the future.
> Apr 02 17:25:04 demoboard systemd[1]: Reached target Timers.
> Apr 02 17:25:38 demoboard systemd[1]: Starting Time & Date Service...
> Apr 02 17:25:40 demoboard systemd[1308]: systemd-timedated.service: 
> ProtectHostname=yes is configured, but the kernel does not support UTS 
> namespaces, ignoring namespace setup.
> Apr 02 17:25:42 demoboard systemd[1]: Started Time & Date Service.
> Apr 02 17:26:13 demoboard systemd[1]: systemd-timedated.service: Succeeded.
> Apr 02 17:27:03 demoboard systemd[1]: Starting Time & Date Service...
> Apr 02 17:27:03 demoboard systemd[1823]: systemd-timedated.service: 
> ProtectHostname=yes is configured, but the kernel does not support UTS 
> namespaces, ignoring namespace setup.
> Apr 02 17:27:03 demoboard systemd[1]: Started Time & Date Service.
>
> It can be seen from the log that after the TimeSync service is disabled, the 
> latest time is obtained from NTP server, but it is not updated to the system. 
> But the system time has also been modified.

systemd-timedated.service has nothing to do with NTP.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user service conflict and confusion

[Michael Biebl]

Am Fr., 10. Apr. 2020 um 17:59 Uhr schrieb Matt Zagrabelny :
>
> Greetings,
>
> I am hitting a confusing scenario with my system. I am running 245.4-2 
> (Debian).
>
> I have a user service, mpd, which is failing to start. It is enabled:
>
> $ systemctl --user is-enabled mpd
> enabled
>
> And now that I look for the enabled unit within the filesystem, I don't see 
> it.
>
> I'm expecting to see something in ~/.config/systemd, but that directory 
> doesn't exist.

I suspect it is enabled system wide, i.e. in /etc/systemd/user
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] dockerd broken docker works without It own docker image but need

[Michael Biebl]

Am Do., 26. März 2020 um 21:43 Uhr schrieb Dorian ROSSE
:
>
> Do you know the dockerd mailing list?

Don't be lazy and find that out yourself. Google (or your search
engine of choice) is your friend.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Infinite loop at startup on var fsck failure

[Michael Biebl]

Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl
:
>
> >>> Vito Caputo  schrieb am 25.02.2020 um 01:01 in
> Nachricht
> <7343_1582589314_5e546582_7343_4690_1_20200225000143.nowls5peec5sx...@shells.gnu
>
> eneration.com>:
> > Hello list,
> >
> > Today I experienced an unclean shutdown due to battery dying unexpectedly,
> > and it left my /var in a state requiring a manual fsck to repair errors.
>
> I wonder: Shouldn't be a fsck just be a journal reply these days? For ext >=3
> this should be quite fast. ReiserFS was rather slow several years ago (it did
> replay too much IMHO), but haven't used it the last five years.
>
> >
> > The normal startup process failed and dropped me to a rescue shell after
> > asking for my root password.  But I was unable to immediately run fsck
> > manually, because systemd was endlessly trying to fsck /var.
>
> That's not a problem of fsck.


I suspect that the real problem is, that fsck failed to fix the file
system, so as a result, systemd tried repeatedly to start the fsck job
for /var as var.mount was pulled in as a dependency (e.g. for
journald).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: show journalctl while stopping?

[Michael Biebl]

Am Fr., 24. Jan. 2020 um 09:45 Uhr schrieb Ulrich Windl
:

> Similarly: Before bashing the proposal, why not think about an option that
> will enable that feature? Like "--verbose", "--monitor",
> "--whatever-you-like"...

There you go
https://github.com/systemd/systemd/blob/master/TODO#L891
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hotplug auto mounting and masked mount units

[Michael Biebl]

Am Fr., 10. Jan. 2020 um 17:13 Uhr schrieb Phillip Susi :
>
>
> Lennart Poettering writes:
>
> > Can you file a bug about this? Sounds like something to fix.
>
> Sure.


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

Re: [systemd-devel] Antw: Re: Binary changed since start

[Michael Biebl]

There is a tool called needrestart which should do exactly what you want.
See
https://tracker.debian.org/pkg/needrestart
https://github.com/liske/needrestart

Am Di., 10. Dez. 2019 um 15:12 Uhr schrieb Ulrich Windl
:
>
> >>> Lennart Poettering  schrieb am 10.12.2019 um 12:32
> in
> Nachricht <20191210113234.GA16721@gardel-login>:
> > On Di, 10.12.19 10:38, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >> Hi!
> >>
> >> Two questions (In Linux it's possible to replace the image of the binary
> > that is executed on disk):
> >>
> >> 1) It seems my version of systemd (228) does not detect that a
> >> binary has changed since the service was started. In case it's still
> >> true in the current version, is it difficult to indicate that fact
> >> in "systemctl status .."?
> >
> > We don't, no. It has been requested before that we deal with that, but
> > it's not realistic to do this correctly. Thing is, binaries are
>
> Well at least "zypper ps" does that kind of things:
> # zypper ps
> The following running processes use deleted files:
>
> PID   | PPID  | UID  | User   | Command| Service| Files
> --+---+--++++--
> 2502  | 1 | 0| root   | multipathd | multipathd |
> /lib64/libtinfo.so.5.9
> 2903  | 1 | 100  | messagebus | dbus-daemon| dbus   |
> /lib64/libnss_sss.so.2
> 2967  | 1 | 0| root   | mcelog | mcelog |
> /lib64/libnss_sss.so.2
> 3774  | 1 | 0| root   | xinetd | xinetd |
> /lib64/libnss_sss.so.2
> 3796  | 1 | 1086 | nagios | nrpe   | nrpe   |
> /lib64/libnss_sss.so.2
> 3973  | 1 | 0| root   | sshd   | sshd   |
> /lib64/libnss_sss.so.2
> 4060  | 1 | 0| root   | automount  | autofs |
> /usr/lib64/libxml2.so.2.9.4
> 4074  | 1 | 0| root   | snmpd  | snmpd  |
> /lib64/libnss_sss.so.2
> 4079  | 1 | 74   | ntp| ntpd   | ntpd   |
> /lib64/libnss_sss.so.2
> 4080  | 4079  | 74   | ntp| ntpd   | ntpd   |
> /lib64/libnss_sss.so.2
> 4082  | 1 | 25   | at | atd| atd|
> /lib64/libnss_sss.so.2
> 4166  | 1 | 0| root   | bash   | md-mon |
> /lib64/libtinfo.so.5.9
> ...
> 25512 | 1 | 0| root   | cupsd  | cups   |
> /lib64/libnss_sss.so.2
> 26053 | 3973  | 0| root   | sshd   ||
> /lib64/libnss_sss.so.2
> 26061 | 26053 | 0| root   | bash   ||
> /lib64/libnss_sss.so.2
>
> # zypper ps -s
> The following running processes use deleted files:
>
> PID   | PPID  | UID  | User   | Command| Service
> --+---+--+++---
> 2502  | 1 | 0| root   | multipathd | multipathd
> 2903  | 1 | 100  | messagebus | dbus-daemon| dbus
> 2967  | 1 | 0| root   | mcelog | mcelog
> 3774  | 1 | 0| root   | xinetd | xinetd
> 3796  | 1 | 1086 | nagios | nrpe   | nrpe
> 3973  | 1 | 0| root   | sshd   | sshd
> 4060  | 1 | 0| root   | automount  | autofs
> 4074  | 1 | 0| root   | snmpd  | snmpd
> ...
>
> > generally not statically compiled, they link against other libraries
> > which might also be updated, and which would have to be checked
> > too. And they do so via module loading (i.e. dlopen()) and explicitly,
> > we'd have to check both, which already is harder, since you cannot
> > just look at the ELF headers of binaries to determine deps
> > anymore. But they also keep other resources mapped, for example l10n
> > and i18n data, and a lot of other stuff. We'd have to check that
> > too. And then, there are the invisible dependencies too: some file
> > changed that some library a program opens and reads, but only
> > sometimes: how would you ever figure out you need to restart the
> > service? And then, there's also the fact that C is just one
> > programming language and others work very differently, and require
> > other schemes for updating, i.e. Python does something very very
> > different.
> >
> > So in the end: implementing something like that could at best be a
> > heuristic, that works sometimes but not generally. I know that some
> > distros implemented a checker for this in their package manager. But I
> > am very sure this has no place in systemd, since it's black magic and
> > you never could rely on the correctness for that.
> >
> >> 2) Given 1), would it make sense to allow an option like
> >> "RestartIfBinary Changed"?
> >
> > Binding control flow to such a heuristic sounds even more dangerous to
> > me.
>
> I was asking for an option, not for a default.
>
> Regards,
> Ulrich
>
>
> >
> > Lennart
> >
> > ‑‑
> > Lennart 

Re: [systemd-devel] need help with undestanding a udev warning

[Michael Biebl]

Am Sa., 16. Nov. 2019 um 09:20 Uhr schrieb Andrei Borzenkov
:
>
> Likely result of mass-rewrite in
>
> commit 25de7aa7b90c23d33ea50ada1e50c5834a414237
> Author: Yu Watanabe 
> Date:   Thu Apr 25 01:21:11 2019 +0200
>
> udev: modernize udev-rules.c


A bug then? Or is there an error in the udev rule that I don't see?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] need help with undestanding a udev warning

[Michael Biebl]

Hi,

with v243 I get the following warning in my journal:

Nov 13 15:38:12 pluto systemd-udevd[319]:
/lib/udev/rules.d/90-libgpod.rules:19 IMPORT key takes '==' or '!='
operator, assuming '==', but please fix it.
Nov 13 15:38:12 pluto systemd-udevd[319]:
/lib/udev/rules.d/90-libgpod.rules:23 IMPORT key takes '==' or '!='
operator, assuming '==', but please fix it.

Looking at the rules file, it shows

ACTION=="add|change", ENV{USBMUX_SUPPORTED}=="1",
IMPORT{program}+="/lib/udev/iphone-set-info", GOTO="libgpod_end"
..
ACTION=="add|change", SUBSYSTEM=="usb", ATTR{idVendor}=="05ac",
ATTR{idProduct}=="129[0-9a]",
IMPORT{program}+="/lib/udev/iphone-set-info"

I don't see the error in those udev rules, so I was wondering why udev
is complaining about them
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] perform fsck on everyt boot

[Michael Biebl]

Am Mo., 11. Nov. 2019 um 16:47 Uhr schrieb Lennart Poettering
:
> Well, note that ext4's fsck only does an actual file system check
> every now and then.

Afair this is outdated knowledge. newer e2fsprogs versions no longer
setup ext4 file systems to do regular fscks.
At least on Debian sid, /etc/mke2fs.conf contains

enable_periodic_fsck = 0

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl stuck when run restart

[Michael Biebl]

Am Sa., 5. Okt. 2019 um 17:06 Uhr schrieb Hongyi Zhao :
> Type=notify

> $ sudo systemctl start ssh
> ^C
> werner@localhost:~/software/openssh$ sudo systemctl restart ssh
> ^C
>
> If I don't hit ^C, the command will stuck there for ever.

I don't think the upstream openssh supports sd_notify.
E.g in Debian it's a custom patch
https://salsa.debian.org/ssh-team/openssh/blob/master/debian/patches/systemd-readiness.patch

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] startup hang at 'load/save random seed'

[Michael Biebl]

See https://github.com/systemd/systemd/issues/13252

Am Mi., 7. Aug. 2019 um 00:39 Uhr schrieb Chris Murphy
:
>
> [   10.281769] fmac.local systemd[1]: Starting Update UTMP about
> System Boot/Shutdown...
> [   10.295504] fmac.local audit[806]: SYSTEM_BOOT pid=806 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='
> comm="systemd-update-utmp" exe="/usr/lib/systemd/systemd-update-utmp"
> hostname=? addr=? terminal=? res=success'
> [   10.305289] fmac.local systemd[1]: Started Update UTMP about System
> Boot/Shutdown.
> [   10.305527] fmac.local audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-update-utmp comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> [   15.264423] fmac.local systemd[1]: systemd-rfkill.service: Succeeded.
> [   15.268231] fmac.local audit[1]: SERVICE_STOP pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
> [  286.296649] fmac.local kernel: random: crng init done
> [  286.301223] fmac.local kernel: random: 7 urandom warning(s) missed
> due to ratelimiting
> [  286.319857] fmac.local systemd[1]: Started Load/Save Random Seed.
> [  286.322850] fmac.local audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-random-seed comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> [  286.323576] fmac.local systemd[1]: Reached target System Initialization.
>
>
> I don't know why there's ratelimiting on urandom warnings, I have
> printk.devkmsg=on
>
> This also seems relevant.
>
> [chris@fmac ~]$ sudo journalctl -b -o short-monotonic | grep -i seed
> [8.870985] fmac.local systemd[1]: Starting Load/Save Random Seed...
> [9.021818] fmac.local systemd-random-seed[619]: Kernel entropy
> pool is not initialized yet, waiting until it is.
> [  286.319857] fmac.local systemd[1]: Started Load/Save Random Seed.
> [  286.322850] fmac.local audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-random-seed comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> [chris@fmac ~]$
>
>
> ---
> Chris Murphy
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] lto issues

[Michael Biebl]

Am Di., 6. Aug. 2019 um 09:26 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> > Hi,
> >
> > today I tried compiling systemd v242 (on Debian sid) once using lto
> > (-Db_lto=true) and once without lto (-Db_lto=false).
> >
> > The lto build took approximately twice as long on my laptop (using
> > dpkg-buildpackage, which introduces a bit of overhead):
> >
> > lto:
> > real 11m22,605s
> > user 37m9,675s
> > sys 2m51,041s
> >
> > nolto:
> > real 6m35,615s
> > user 18m51,782s
> > sys 2m12,934s
> >
> > That's kinda expected. What suprised me though is that using lto
> > produced larger binaries:
>
> I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
> a big increase in binary sizes *before stripping*. After stripping,
> binaries with lto=true are smaller:
>
> $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
>   7116384 Aug  6 09:08 build-rawhide/systemd*
>  11951256 Aug  6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
>   1594912 Aug  6 09:12 build-rawhide-lto/systemd*
>   3167096 Aug  6 09:11 build-rawhide-lto/src/shared/libsystemd-shared-243.so*
> $ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
>   1439640 Aug  6 09:19 build-rawhide/systemd*
>   2806456 Aug  6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
>   1370008 Aug  6 09:19 build-rawhide-lto/systemd*
>   2806288 Aug  6 09:19 build-rawhide-lto/src/shared/libsystemd-shared-243.so*


The sizes I posted i.e. the debdiff is after stripping.

gcc --version
gcc (Debian 8.3.0-19) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ld --version
GNU ld (GNU Binutils for Debian) 2.32.51.20190727
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.

So with the toolchain I have, mostly has downsides. The only benefit
it seems to have is that it optimizes unnecessary library dependencies
away (see how the udev subpackage does not depend on libcap2 (>=
1:2.10), libidn2-0 (>= 0.6)



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] lto issues

[Michael Biebl]

Hi,

today I tried compiling systemd v242 (on Debian sid) once using lto
(-Db_lto=true) and once without lto (-Db_lto=false).

The lto build took approximately twice as long on my laptop (using
dpkg-buildpackage, which introduces a bit of overhead):

lto:
real 11m22,605s
user 37m9,675s
sys 2m51,041s

nolto:
real 6m35,615s
user 18m51,782s
sys 2m12,934s

That's kinda expected. What suprised me though is that using lto
produced larger binaries:

File lists identical (after any substitutions)

Control files of package libnss-myhostname: lines which differ (wdiff format)
-
Installed-Size: [-202-] {+222+}

Control files of package libnss-mymachines: lines which differ (wdiff format)
-
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} systemd-container (= 242-2)
Installed-Size: [-401-] {+461+}

Control files of package libnss-resolve: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} systemd (= 242-2)
Installed-Size: [-396-] {+460+}

Control files of package libnss-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} systemd (= 242-2)
Installed-Size: [-400-] {+460+}

Control files of package libpam-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} libpam0g (>=
0.99.7.1), systemd (= 242-2), libpam-runtime (>= 1.0.1-6), dbus,
systemd-sysv
Installed-Size: [-398-] {+466+}

No differences were encountered between the control files of package
libsystemd-dev

Control files of package libsystemd0: lines which differ (wdiff format)
---
Installed-Size: [-774-] {+862+}
Pre-Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} libgcrypt20 (>=
1.8.0), liblz4-1 (>= 0.0~r122), liblzma5 (>= [-5.1.1alpha+20120614)-]
{+5.1.1alpha+20120614), libselinux1 (>= 2.1.9)+}

No differences were encountered between the control files of package libudev-dev

Control files of package libudev1: lines which differ (wdiff format)

Installed-Size: [-257-] {+297+}

Control files of package systemd: lines which differ (wdiff format)
---
Depends: [-libacl1 (>= 2.2.23),-] libapparmor1 (>= 2.9.0-3+exp2),
libaudit1 (>= 1:2.2.1), [-libcap2 (>= 1:2.10),-] libcryptsetup12 (>=
2:1.6.0), libgnutls30 (>= 3.6.6), libgpg-error0 (>= 1.14), libidn2-0
(>= 2.0.0), libip4tc2 (>= 1.8.3), libkmod2 (>= 5~), liblz4-1 (>=
0.0~r130), libmount1 (>= 2.30), libpam0g (>= 0.99.7.1), libpcre2-8-0
(>= 10.32), libseccomp2 (>= 2.3.1), libsystemd0 (= 242-2), util-linux
(>= 2.27.1), mount (>= 2.26), adduser
Installed-Size: [-13781-] {+12696+}
Pre-Depends: {+libacl1 (>= 2.2.23),+} libblkid1 (>= 2.24), libc6 (>=
2.28), {+libcap2 (>= 1:2.10),+} libgcrypt20 (>= 1.8.0), liblz4-1 (>=
0.0~r122), liblzma5 (>= 5.1.1alpha+20120614), libselinux1 (>= 2.1.9)

Control files of package systemd-container: lines which differ (wdiff format)
-
Installed-Size: [-1118-] {+1126+}

No differences were encountered between the control files of package
systemd-coredump

Control files of package systemd-journal-remote: lines which differ
(wdiff format)
--
Installed-Size: [-314-] {+318+}

No differences were encountered between the control files of package
systemd-sysv

Control files of package systemd-tests: lines which differ (wdiff format)
-
Depends: libacl1 (>= 2.2.23), libapparmor1 (>= 2.9.0-3+exp2),
libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.24), libc6 (>= 2.28), libcap2
(>= 1:2.10), libcryptsetup12 (>= 2:1.6.0), libdbus-1-3 (>= 1.9.14),
libgcrypt20 (>= 1.8.0), libglib2.0-0 (>= 2.26.0), libgpg-error0 (>=
1.14), [-libidn2-0 (>= 2.0.0), libip4tc2 (>= 1.8.3),-] libkmod2 (>=
5~), liblz4-1 (>= 0.0~r130), libmount1 (>= 2.30), libpam0g (>=
0.99.7.1), libseccomp2 (>= 2.3.1), libselinux1 (>= 2.1.9), libsystemd0
(= 242-2), libudev1 (>= 215), systemd (= 242-2), zlib1g (>= 1:1.1.4),
python3
Installed-Size: [-26530-] {+24446+}

Control files of package udev: lines which differ (wdiff format)

Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.24), libc6 (>= 2.28),
{+libcap2 (>= 1:2.10), libidn2-0 (>= 0.6),+} libkmod2 (>= 5~),
libselinux1 (>= 2.1.9), adduser, dpkg (>= 1.19.3) | systemd-sysv,
libudev1 (= 242-2), util-linux (>= 2.27.1)
Installed-Size: 

Re: [systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

[Michael Biebl]

Am Di., 2. Juli 2019 um 18:52 Uhr schrieb František Šumšal
:
> This, or since the URL leads to [0], it would be also useful to extend
> the "About systemd-devel" section to provide some kind of warning that
> this ML is mainly/only for upstream systemd, not for systemd shipped by
> distributions.

Fwiw, I have no problems if systemd related questions that also touch
distro specific issues are discussed here.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

[Michael Biebl]

Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
:
> Reading the output above, I can see, why the people contact this mailing
> list.

I agree here. While we do have `support-url` which distros can
override, Apparently not all of them do.
We could probably change our build system, that `support-url` needs to
be set explicitly and if unset, no Support URL is printed in the
journal output.
Just an idea...


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

[Michael Biebl]

Am Di., 11. Juni 2019 um 16:18 Uhr schrieb Reindl Harald
:
>
>
>
> Am 11.06.19 um 15:00 schrieb Ulrich Windl:
>  Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> > Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
> >>
> >> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >>> I have a forking service (with a PID file) that can reopen the logfile 
> >>> after
> >> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to 
> >> send
> >> SIGHUP to the daemon as "postrotate" action. After converting (actually 
> >> being
> >> converted ;-)) to systemd I dropped the LSB script, and wonder which 
> >> command
> >> to use as "postrotate" action:
> >>>
> >>> Should I implement a oneshot service (using "systemctl start {service}")
> >> that does depend on the actual service and send a SIGHUP on start, or is
> >> there a more elegent solution?
> >>
> >> that's what reload is all about
> >>
> >> [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> >> ExecReload=/usr/bin/kill -HUP $MAINPID
> >
> > The manual page says it's about "configuration reload". I was talking about 
> > logfile rotation (my service does not suport configuration reload (other 
> > than restart))
>
> frankly it's nothing new or uncommon that services close and re-open
> their logfiles by "reload" and that's really not systemd specific,
> sysvinit had reload too
>
> it's you turn what happens with "systemctl reload yourservice" becaus
> ethere is no default action for that unless "ExecReload" is specified

Of course you can do whatever you please in ExecReload, but as said I
think it's good practice if "reload" has a certain consistent meaning
across services so admins not familiar with a particular service know
what to expect from "systemctl reload".

See also
https://github.com/rsyslog/rsyslog/commit/fd26a42bdc04eaf497cafd9ef806a54f3de1a7e9#diff-c64e6ed7f40ecd1530e093a77c9465f6



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

[Michael Biebl]

Am Di., 11. Juni 2019 um 15:00 Uhr schrieb Ulrich Windl
:
>
> >>> Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>
> >
> > Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >> I have a forking service (with a PID file) that can reopen the logfile 
> >> after
> > receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send
> > SIGHUP to the daemon as "postrotate" action. After converting (actually 
> > being
> > converted ;-)) to systemd I dropped the LSB script, and wonder which command
> > to use as "postrotate" action:
> >>
> >> Should I implement a oneshot service (using "systemctl start {service}")
> > that does depend on the actual service and send a SIGHUP on start, or is
> > there a more elegent solution?
> >
> > that's what reload is all about
> >
> > [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> > ExecReload=/usr/bin/kill -HUP $MAINPID
>
> The manual page says it's about "configuration reload". I was talking about 
> logfile rotation (my service does not suport configuration reload (other than 
> restart)).

Right, I wouldn't use ExecReload= for this use case myself.
If I run "systemctl reload $service", I expect that the service
reloads its configuration and I think it's good practice to be
consistent in that matter and not overload ExecReload= with "rotate
log files".


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: Implementing logrotate's postrotate with systemd

[Michael Biebl]

A separate oneshot service sounds like overkill. I would probably use
something like
`systemctl kill -s HUP ${service}.service`
If your sevices spawns multiple processes and you only want to send
SIGHUP to the main process, you should add a `--kill-who=main`

All documented nicely in
https://www.freedesktop.org/software/systemd/man/systemctl.html

Am Di., 11. Juni 2019 um 13:34 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> I have a forking service (with a PID file) that can reopen the logfile after 
> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
> SIGHUP to the daemon as "postrotate" action. After converting (actually being 
> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
> to use as "postrotate" action:
>
> Should I implement a oneshot service (using "systemctl start {service}") that 
> does depend on the actual service and send a SIGHUP on start, or is there a 
> more elegent solution?
>
> Regards,
> Ulrich
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Wtrlt: Antw: Re: Can I enable/disable a target?

[Michael Biebl]

Am Do., 9. Mai 2019 um 15:52 Uhr schrieb Ulrich Windl
:
>
> (Sorry, I didn't send to the list before)
> >>> Ulrich Windl  schrieb am 09.05.2019 um 
> >>> 14:28
> in Nachricht <5cd44cae.ed38.00a...@rz.uni-regensburg.de>:
> >>>> Michael Biebl  schrieb am 09.05.2019 um 12:29 in 
> >>>> Nachricht
> > :
> > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
> > > :
> > >>
> > >> Hi!
> > >>
> > >> Whenever I try to enable or disable a target (that exists), I get 
> > >> "Failed to
> >
> > > execute operation: No such file or directory". What file or directory,
> > > please? Or what is the command trying to say?
> > >
> > > Can you share the target unit please.
> > > Into what location have you installed the unit file?
> >
> > This is after fixing obvious errors:
> > # systemctl enable iotwatch.target
> > Failed to execute operation: No such file or directory
> > # cat /run/systemd/generator.late/iotwatch.target
> > [Unit]
> > Description=iotwatch I/O performance monitor
> > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8)
> > After=nss-lookup.target time-sync.target paths.target
> > Wants=iotwatch@VAR.service
> >
> > [Install]
> > WantedBy=multi-user.target

This doesn't make sense. You generate an ephemeral runtime unit in
/run but you then try to enable it in /etc.

To make it easier to help, you should give us an idea/overview what
you are trying to achieve. What you did so far (and why), what
environment you are using etc.

It's really hard to give you a good answer when we don't even tell us
the systemd version and distro you are using.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can I enable/disable a target?

[Michael Biebl]

[Please do not send this message to me privately only]

Am Do., 9. Mai 2019 um 13:22 Uhr schrieb Ulrich Windl
:
>
> >>> Michael Biebl  schrieb am 09.05.2019 um 12:29 in
> Nachricht
> :
> > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
> > :
> >>
> >> Hi!
> >>
> >> Whenever I try to enable or disable a target (that exists), I get "Failed
> to
> > execute operation: No such file or directory". What file or directory,
> > please? Or what is the command trying to say?
> >
> > Can you share the target unit please.
> > Into what location have you installed the unit file?
>
> Good question: I should have been created by a generator, so the location
> should be /run/systemd/generator*, but I could not find it. I have the feeling
> that "systemctl daemon-reload" did not trigger the generator (which is at
> /usr/lib/systemd/system-generators/iotwatch-generator).
>
> OK, trying to run the generator manually I found that it exits with 1, not
> creating the target. Wouldn't it be nice if systemd would log failed
> generators?

It does. You can find the log message in the journal.
See my other email

> So I fixed the generator (it can still exit with 1, but no longer in the
> success-case).
>
> Now I have some "bad" state:
> # systemctl status iotwatch.target
>  ● iotwatch.target - iotwatch I/O performance monitor
>Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad; vendor
> preset: disabled)
>Active: inactive (dead) since Thu 2019-05-09 12:39:45 CEST; 39min ago
> ...
>
> What is that "bad" referring to? The target
> /run/systemd/generator.late/iotwatch.target looks like this:
> # cat /run/systemd/generator.late/iotwatch.target
> [Unit]
> Description=iotwatch I/O performance monitor
> Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8)
> After=nss-lookup.target time-sync.target paths.target
> Wants=iotwatch@VAR.service
>
> [Install]
> WantedBy=multi-user.target



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Any defined exit code for a generator?

[Michael Biebl]

Am Do., 9. Mai 2019 um 12:29 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> The manual page of generators does not talk about exit codes in case of an 
> error. Is there any handling of exit codes in systemd?

exit codes > 0 returned by the generator are treated as errors and
systemd will log about this when the generator is run. You'll get an
error message like this in the journal:

Mai 09 12:41:46 pluto systemd[1]: Reloading.
Mai 09 12:41:47 pluto systemd[5481]:
/lib/systemd/system-generators/test failed with exit status 1.

Can you be more specific about you are trying to do?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can I enable/disable a target?

[Michael Biebl]

Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> Whenever I try to enable or disable a target (that exists), I get "Failed to 
> execute operation: No such file or directory". What file or directory, 
> please? Or what is the command trying to say?

Can you share the target unit please.
Into what location have you installed the unit file?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)

[Michael Biebl]

Hi

Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl
:

> Despite of that I'm missing a "systemctl validate ..." command. That way I 
> wouldn't need to execute start, status, stop, just to find out that some 
> settings are rejected.

There is "systemd-analyze verify".

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel