Re: [systemd-devel] repart.d: Root partition not grown on Ubuntu 22.04 with *systemd* 249.11-0ubuntu3.12

[Paul Menzel]

Dear Nils,


Thank you for the fast answer.

Am 06.05.24 um 02:00 schrieb Nils Kattenbeck:

This was not properly implemented until the current version:
https://github.com/systemd/systemd/pull/30030


Indeed, it seems to work with Ubuntu 24.04 (noble numbat) with *systemd* 
255.4-1ubuntu8.


```
$ systemd --version
systemd 255 (255.4-1ubuntu8)
+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

$ sudo journalctl -u systemd-repart
May 07 10:31:27 localhost systemd-repart[424]: Failed to find TPM2 
pcrlock policy file 'pcrlock.json': No such file or directory
May 07 10:31:27 localhost systemd-repart[424]: Device '/' has no 
dm-crypt/dm-verity device, no need to look for underlying block device.
May 07 10:31:27 localhost systemd-repart[424]: Device /dev/vda opened 
and locked.
May 07 10:31:27 localhost systemd-repart[424]: Sector size of device is 
512 bytes. Using grain size of 4096.
May 07 10:31:27 localhost systemd-repart[424]: TYPE 
   LABEL   UUID PARTNO FILE 
 NODEOFFSET   OLD SIZE RAW SIZE  SIZE  OLD 
PADDING RAW PADDING PADDING ACTIVITY
May 07 10:31:27 localhost systemd-repart[424]: esp 
   esp 53907356-a252-4940-8ed1-c20276a7e04d 0 
00-esp.conf  /dev/vda1   1048576  536870912536870912512.0M 
 0   0 0B  unchanged
May 07 10:31:27 localhost systemd-repart[424]: 
21686148-6449-6e6f-744e-656564454649 linux 
60b723a6-ff6c-49f0-91af-1d47e379d03c 1  05-bios.conf /dev/vda2 
5379194881048576  1048576  1.0M0   0 
0B  unchanged
May 07 10:31:27 localhost systemd-repart[424]: root-x86-64 
   root-x86-64 05068373-5d08-4133-ac7d-719e5498d27d 2 
10-root.conf /dev/vda3 538968064 1117876224 108492058624 1.0G → 101.0G 
107374182400   0 100.0G → 0B resize
May 07 10:31:27 localhost systemd-repart[424]: 

   Σ = 101.5G 
   Σ = 0B
May 07 10:31:27 localhost systemd-repart[424]: 
▒░

May 07 10:31:27 localhost systemd-repart[424]:  ├─ 10-root.conf
May 07 10:31:27 localhost systemd-repart[424]:  ├─ 05-bios.conf
May 07 10:31:27 localhost systemd-repart[424]:  └─ 00-esp.conf
May 07 10:31:27 localhost systemd-repart[424]: Applying changes to /dev/vda.
May 07 10:31:27 localhost systemd-repart[424]: Growing existing partition 2.
May 07 10:31:27 localhost systemd-repart[424]: Writing new partition table.
May 07 10:31:28 localhost systemd-repart[424]: Telling kernel to reread 
partition table.

May 07 10:31:28 localhost systemd-repart[424]: All done.
May 07 10:31:28 localhost systemd[1]: systemd-repart.service: Child 424 
belongs to systemd-repart.service.
May 07 10:31:28 localhost systemd[1]: systemd-repart.service: Main 
process exited, code=exited, status=0/SUCCESS (success)
May 07 10:31:28 localhost systemd[1]: systemd-repart.service: Changed 
start -> exited
May 07 10:31:28 localhost systemd[1]: systemd-repart.service: Job 60 
systemd-repart.service/start finished, result=done
May 07 10:31:28 localhost systemd[1]: Finished systemd-repart.service - 
Repartition Root Disk.
May 07 10:31:28 localhost systemd[1]: systemd-repart.service: Control 
group is empty.

```

On Ubuntu 22.04 editing the partition table with `fdisk /dev/vda` or 
using `growpart /dev/vda 3` (package *cloud-guest-utils*) works around it.



Kind regards,

Paul

[systemd-devel] repart.d: Root partition not grown

[Paul Menzel]

Dear systemd folks,


On Ubuntu 22.04 with *systemd-repart* 249.11-0ubuntu3.12, the root 
partition in a qcow2 image, resized with


qemu-img resize ubuntu-jammy.qcow2 +100G

is not grown:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sr0 11:01  1024M  0 rom
vda254:00 101.5G  0 disk
|-vda1 254:10   512M  0 part
|-vda2 254:20 1M  0 part
`-vda3 254:30 989.1M  0 part /

$ more /etc/repart.d/*.conf
::
/etc/repart.d/00-esp.conf
::
[Partition]
Type=esp
Format=vfat
CopyFiles=/boot:/
CopyFiles=/efi:/
SizeMinBytes=512M
SizeMaxBytes=512M
::
/etc/repart.d/05-bios.conf
::
[Partition]
# UUID of the grub BIOS boot partition which grubs needs on GPT to
# embed itself into.
Type=21686148-6449-6e6f-744e-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M
::
/etc/repart.d/10-root.conf
::
[Partition]
Type=root
Format=ext4
CopyFiles=/
Minimize=guess

$ sudo systemd-repart
/etc/repart.d/10-root.conf:5: Unknown key name 'Minimize' in 
section 'Partition', ignoring.
TYPE LABEL   UUID 
  FILE NODE  SIZE PADDING
esp  esp 
8c1fa117-5470-40fb-ae88-706406a7e115 00-esp.conf  /dev/vda1   512.0M  0B
21686148-6449-6e6f-744e-656564454649 linux 
13d7f959-ea58-4560-9a51-956603dccdbd 05-bios.conf /dev/vda2 1.0M  0B
root-x86-64  root-x86-64 
9e46548d-16e7-4b79-aa05-bf9d8e4bff48 10-root.conf /dev/vda3   989.0M  0B


 Σ = 1.4G  Σ = 0B


▓
 ├─ 10-root.conf
 ├─ 05-bios.conf
 └─ 00-esp.conf

No changes.

Reading the manual I’d assume, that type *root* would automatically be 
grown. Before creating an issue, can you see, if something is wrong with 
the configuration files?



Kind regards,

Paul

Re: [systemd-devel] mkosi config to build minimal Ubuntu 22.04 VM image?

[Paul Menzel]

Dear Daan,


Thank you very much for your reply.


Am 04.03.24 um 15:52 schrieb Daan De Meyer:


Please see the config included in the mkosi repository itself:
https://github.com/systemd/mkosi/blob/main/mkosi.conf and
https://github.com/systemd/mkosi/tree/main/mkosi.conf.d. This should
help you get started. https://mkosi.systemd.io/bootable.html shows how
to build a minimal bootable image for different distributions. mkosi
doesn't concern itself with which packages are installed in the image.
Please refer to your distribution of choice for that.


Thank you for the pointers. I started to try it again, but Ubuntu 22.04 
(Jammy Jellyfish) does not have `bootctl`, that means *systemd-boot* is 
not in the official package archive [1].



Kind regards,

Paul


[1]: https://packages.ubuntu.com/search?keywords=systemd-boot

[systemd-devel] mkosi config to build minimal Ubuntu 22.04 VM image?

[Paul Menzel]

Dear systemd and mkosi folks,


I would like to create a minimal Ubuntu 22.04 (Jammy) virtual machine 
image for QEMU/KVM with VirtIO. Inside the VM only systemd, sshd, a 
shell and curl or Wget should be installed. (From this base, one goal is 
then to install BigBlueButton for example.) I found one blog post from 
2020 [1], but mkosi changed a lot since then.



Thank you in advance and kind regards,

Paul


[1]: https://krystof.litomisky.com/2020/09/08/mkosi-for-ubuntu/

Re: [RFC] initoverlayfs - a scalable initial filesystem

[Paul Menzel]

[Sorry for the spam to the people in Cc. Now the real address.]

Dear Luca,


Am 11.12.23 um 22:45 schrieb Luca Boccassi:
> On Mon, 11 Dec 2023 at 21:20, Demi Marie Obenour wrote:
>>
>> On Mon, Dec 11, 2023 at 08:58:58PM +, Luca Boccassi wrote:
>>> On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour wrote:

 On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote:
> On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour

>> On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote:
>>> On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote:

[…]

> And for ancient, legacy platforms that do not support modern APIs, the
> old ways will still be there, and can be used. Nobody is going to take
> away grub and dracut from the internet, if you got some special corner
> case where you want to use it it will still be there, but the fact
> that such corner cases exist cannot stop the rest of the ecosystem
> that is targeted to modern hardware from evolving into something
> better, more maintainable and more straightforward.

 The problem is not that UEFI is not usable in automotive systems.  The
 problem is that U-Boot (or any other UEFI implementation) is an extra
 stage in the boot process, slows things down, and has more attack
 surface.
>>>
>>> Whatever firmware you use will have an attack surface, the interface
>>> it provides - whether legacy bios or uefi-based - is irrelevant for
>>> that. Skipping or reimplementing all the verity, tpm, etc logic also
>>> increases the attack surface, as does adding initrd-only code that is
>>> never tested and exercised outside of that limited context. If you are
>>> running with legacy bios on ancient hardware you also will likely lack
>>> tpm, secure boot, and so on, so it's all moot, any security argument
>>> goes out of the window. If anybody cares about platform security, then
>>> a tpm-capable and secureboot-capable firmware with a modern, usable
>>> interface like uefi, running the same code in initrd and full system,
>>> using dm-verity everywhere, is pretty much the best one can do.
>>
>> Neither Chrome OS devices nor Macs with Apple silicon use UEFI, and both
>> have better platform security than any UEFI-based device on the market I
>> am aware of.
> 
> We are talking about Linux distributions here. If one wants to use
> proprietary systems, sure, there are better things out there, but
> that's off topic.

In what way is ChromeOS more proprietary than the other GNU/Linux 
distributions, that allow to install the Chrome browser?


Kind regards,

Paul

[systemd-devel] All Systems Go! 2023 (13/14. 09. 23): Call for Proposals ends July 7th

[Paul Menzel]

Dear systemd folks,


I didn’t see an announcement for ASG2023 on the list, so for those, like 
me, who haven’t seen this yet [1]:



All Systems Go! 2023 Call for Proposals

The Call for Participation (CFP) for All Systems Go! 2023 is now
open! Please submit your proposals for consideration.

The CFP will close on July 7th, 2023. A response will be sent to all
submitters on or before July 14th, 2023. The conference takes place
in ️ Berlin, Germany  on Sept. 13-14th.

All Systems Go! 2023 is all about foundational open-source Linux
technologies. We are primarily looking for deeply technical talks by
and for developers, engineers and other technical roles.

We focus on the userspace side of things, so while kernel topics are
welcome they must have clear, direct relevance to userspace. The
following is a non-comprehensive list of topics encouraged for 2023
submissions:

 *  Image-Based Linux ️ 
 *  Secure and Measured Boot  
 *  TPM-Based Local/Remote Attestation, Encryption, Authentication  
 *  Low-level container executors and infrastructure ⚙️. 
 *  IoT, embedded and server Linux infrastructure 
 *  Reproducible builds  
 *  Package management, OS, container , image delivery and updating 
 *  Building Linux devices and applications ️ 
 *  Low-level desktop  technologies 
 *  Networking  
 *  System and service management  
 *  Tracing and performance measuring  
 *  IPC and RPC systems 列 
 *  Security  and Sandboxing ️ 


Format: submissions must be in one of three formats: 35min talk + 5
min Q, 20min talk + 5 min Q, and 5min lightning talks.

Please familiarize yourself with our Code of Conduct as all speakers
and attendees are expected to abide by it.

You can enter proposals until 2023-07-07 23:59 (UTC)


Kind regards,

Paul


[1]: https://cfp.all-systems-go.io/all-systems-go-2023/cfp

Re: [systemd-devel] systemd enables custom service units on firstboot

[Paul Menzel]

Dear Martin,


Am 29.04.23 um 16:12 schrieb Martin Petzold:

we are building our OS with debootstrap (Debian bullseye). Our image 
shall be flashed on embedded devices. In order to get a unique 
machine-id we removed '/etc/machine-id' as instructed in [1] and also 
removed '/var/lib/dbus/machine-id' as instructed in [2]) from the golden 
image.


After we flash the image and boot it, new machine-ids are created and 
identical.


However, now we realized that some of our systemd service units added to 
'/lib/systemd/system' are enabled and starting on boot. We did not 
enable them, we just copied them to that location at the end of our 
rootfs build. They are just there to be used in some special test cases.


We already checked '/lib/systemd/system-preset/*'. But there is only a 
single file '90-systemd.preset' and there is no rule which matches our 
service units.


1. Why are our service units placed in '/lib/systemd/system' enabled?
2. What actually happens during firstboot?


Sorry, you provide not enough information.

Please provide an example `systemctl status X` and `systemctl cat X` for 
service X, that is started but does not. Does that happen with all 
services you add?


Please enable debug logs by for example adding `debug` to the Linux 
command line.


Related 3. If we do A/B rootfs updates could there be any problems if a 
new machine-id is created on each (sys)update?


I recommend to start a separate thread for this question.


Kind regards,

Paul



Platform:

systemd 252.5-2~bpo11+1 (from bullseye-backports)
systemd-resolved and systemd-networkd with iwd (all from 
bullseye-backports)

Custom Debian bullseye (with some packages from bullseye-backports)
Custom Kernel 5.10
U-Boot

[1] https://systemd.io/BUILDING_IMAGES/
[2] https://wiki.debian.org/MachineId

Re: [systemd-devel] Plot time data anomalies

[Paul Menzel]

Dear Joshua,


Am 11.01.23 um 12:53 schrieb Joshua Zivkovic:

[…]


I'm interested in whether this means that the times for unit
initialisation, presented by `plot`, aren't entirely accurate and if
there is anything that can be done about this.


I believe, systemd-bootchart is recommended to capture more accurate 
boot time date.



Kind regards,

Paul

Re: [systemd-devel] kexec reboot fails and reboots in normal cold boot way

[Paul Menzel]

Dear Prashantkumar,


Am 14.06.22 um 10:39 schrieb Prashantkumar dhotre:


In  systemd 243.2+ version, intermittently sometimes I see that 'systemctl
kexec' does not result in kexec reboot but results in reguler cold boot
reboot


The upstream list only gives support for the last two systemd releases. 
Please try with these first, and if not, please contact the support of 
your distribution.


(I doubt it’s a systemd issue though, and more a Linux kernel or other 
configuration issue. If you manually reboot with kexec, does it always 
work?)



In console logs, I see below logs.
At line#209, I see "FAIL" string but not sure where it is coming from.
In which cases do 'systemctl kexec' can fail and result in non-kexec
reguler reboot?


  185 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/data/var/home/root/.ssh^[[0m.^M
  186 2022-06-13 13:56:18 [^[[0;1;31mFAILED^[[0m] Failed unmounting
^[[0;1;39m/etc^[[0m.^M
  187 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/soft/uswitch^[[0m.^M
  188 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmo[ 1130.272883]
systemd-shutdown[1]: Could not deactivate swap /sda3: Transport endpoint is
not
  connected^M
  189 2022-06-13 13:56:18 unted ^[[0;1;39m/u^[[0m.^M
  190 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/usr/conf^[[0m.^M
  191 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/usr/evo/share^[[0m.^M
  192 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/uswitch/data/var/external^[[0m.^M
  193 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/uswitch/dev^[[0m.^M
  194 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/uswitch/proc^[[0m.^M
  195 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/uswitch/soft^[[0m.^M
  196 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/uswitch/tmp^[[0m.^M
  197 2022-06-13 13:56:18 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/var/db^[[0m.^M
  198 2022-06-13 13:56:19 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/var/etc^[[0m.^M
  199 2022-06-13 13:56:19 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/var/pfe^[[0m.^M
  200 2022-06-13 13:56:19 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39m/var/rundb^[[0m.^M
  201 2022-06-13 13:56:19 [^[[0;32m  OK  ^[[0m] Unmounted
^[[0;1;39mTemporary Directory (/tmp)^[[0m.^M
  202 2022-06-13 13:56:19 [^[[0;32m  OK  ^[[0m] Stopped target
^[[0;1;39mSwap^[[0m.^M
  203 2022-06-13 13:56:19  Deactivating swap
^[[0;1;39m/sda3^[[0m...^M
  204 2022-06-13 13:56:19  Unmounting ^[[0;1;39m/data/var^[[0m...^M
  205 2022-06-13 13:56:19  Unmounting ^[[0;1;39m/soft^[[0m...^M
  206 2022-06-13 13:56:19  Unmounting
^[[0;1;39m/uswitch/data/var^[[0m...^M
  207 2022-06-13 13:56:19  Unmounting ^[[0;1;39m/var^[[0m...[
1131.454830] reboot: Restarting system^M
  208 2022-06-13 13:56:19 ^M
  209 2022-06-13 13:56:19 [^[[0;1;31mFAIL^[c^M
  210 2022-06-13 13:56:19 Booting from Flash A^M
  211 2022-06-13 13:56:19 ^M
  212 2022-06-13 13:56:19 FPGA Reset Reason = 0x80^M
  213 2022-06-13 13:56:19 ^M
  214 2022-06-13 13:56:20 Primary BIOS version CBDE_P_LIG0_00.25.1^M


Please annotate the paste, and make sure the paste is also not wrapped 
(by Google Mail) after 72(?) characters. Currently it’s hard to read.


You also missed to provide details about your system, the Linux kernel 
version. You might want to set the log level to debug, and the log gives 
more clues [1]:


systemd-analyze set-log-level debug

The systemd Wiki page *Debuggingo [2] also documents more ways on how to 
debug problems.



Kind regards,

Paul


[1]: 
https://unix.stackexchange.com/questions/566190/how-can-i-get-the-current-systemd-log-level-and-change-it

[2]: https://freedesktop.org/wiki/Software/systemd/Debugging/

Re: [systemd-devel] issues with systemd-cryptsetup@.service after in 251-rc3

[Paul Menzel]

Dear Dusty,


Am 19.05.22 um 05:32 schrieb Dusty Mabe:

I'm requesting help to try to find a problematic commit between
v251-rc2..v251-rc3.

We have a test in Fedora CoreOS [1] that tests luks and this test
started failing in our rawhide stream with the introduction of
251-rc3. Reverting back to 251-rc2 makes the failing test go away. I
briefly looked at the commits from v251-rc2..v251-rc3 but nothing 
jumped out at me.


Any commits in there that we think might be risky or ones we should
look at closer?


Please bisect. It’s the most efficient way, and you can do it yourself, 
especially as you have a test to reproduce the issue.



Here's the original bug [2] I opened against Fedora CoreOS:



Kind regards,

Paul



[1] 
https://github.com/coreos/fedora-coreos-config/tree/testing-devel/tests/kola/root-reprovision/luks
[2] https://github.com/coreos/fedora-coreos-tracker/issues/1200

Re: [systemd-devel] trivial net connection logs - ?

[Paul Menzel]

[Sorry for this resent to your personal address.]

Dear L,


Am 11.04.22 um 09:28 schrieb lejeczek:

I must have gone blind cause can't find it in man page and to my 
surprise internet search does not help or my quering is broken.

'systemctl' can show status for specific NM connection - what was that?


Does NM mean NetworkManager?


- and can 'journalctl' do the same? (or was it the opposite way?)


To my knowledge there is no such integration from NetworkManager and 
systemctl. You can only check if NetworkManager is running with


systemctl status NetworkManager

`networkctl` can show you information about the network configuration, 
also when it’s not managed by systemd-networkd.


Lastly, NetworkManager also ships `nmcli` and `nmtui`, you can use on 
the command line.



Kind regards,

Paul


PS: Next time, if you write an email to several hundreds/thousands of 
people, it’d be great if you could elaborate a little more.

Re: [systemd-devel] Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts

[Paul Menzel]

Dear Adam,


First, just a note (for myself), `ipmitool power` is a shortcut for 
`ipmitool chassis power`.



Am 11.02.22 um 10:54 schrieb Adam Nielsen:

After flashing the firmware of some pcie card I need to power cycle
the server to finish the flashing process.


Can you please tell us the PCIe device, where a normal system reboot is
not enough to reset it, so I can avoid buying it?


Most remote access cards work like this by design.  You might be
connected to a remote computer via a web browser, and need to get into
the BIOS to change some settings.  If you reboot the machine, the last
thing you want is the card to reset as well, causing your remote
session to drop out.  By the time the card's firmware has started and
you reconnect, you've probably missed the prompt to press F2/DEL/etc.


Then these remote management cards should allow to be restarted 
separately. The BMC I had to deal with allow that.



A lot of server hardware (e.g. SAS controllers) have onboard firmware
which may or may not restart during a reboot.  This is also by design,
because the cards can take many minutes for the firmware to boot up, so
by continuing to run the firmware across a restart they can cut the
server boot time down by many minutes, which makes a big difference if
you're running an OS that requires frequent reboots.


Why should the firmware need more than one second? There is no reason 
for that. So, one more point to avoid such a device.



I think most hardware vendors (at least in the server space) view a
reboot as a means to apply operating system updates rather than a means
to actually reset hardware.  This would no doubt be why programs like
ipmitool have an option to automatically power cycle the machine, for
the rare cases where you do want the hardware reset as well.


Hmm, that would be very strange. Luckily until now, a normal reboot was 
totally fine in my experience with Dell and Supermicro servers.



It's only really a problem when you try to use this server hardware in
consumer machines, which don't really have a means to automatically
power cycle themselves.  Most servers seem to be configurable, to do
things like intercept a hardware reset and turn it into a power cycle
automatically, or have an "always on" mode configured where you just
tell the OS to shut down and power off, and the server will
automatically power itself back on a few seconds later, or at the very
least the server will have one of those remote access controllers that
you can use to remotely power it back on again after you've done a
normal shut down + power off.

So if you don't like the idea of parts of the system continuing to run
across reboots, just stay clear of hardware designed for enterprise
servers and you'll likely never encounter it.


Yes, that is why I asked, so I will never buy such crappy hardware. With 
Dell and Supermicro servers, rebooting the system was all I needed. (The 
BMC is not reset, but can be done separately while the server itself is 
still running.)



Kind regards,

Paul

Re: [systemd-devel] Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts

[Paul Menzel]

Dear Etienne,


Am 09.02.22 um 22:05 schrieb Etienne Champetier:


After flashing the firmware of some pcie card I need to power cycle
the server to finish the flashing process.


Can you please tell us the PCIe device, where a normal system reboot is 
not enough to reset it, so I can avoid buying it?


[…]


Kind regards,

Paul

Re: [systemd-devel] Converting xinetd files

[Paul Menzel]

Dear Wol,


Am 11.02.22 um 01:57 schrieb Wol:

I've found the pid0 blog, and had no real trouble (I think, I haven't
tested it yet :-) converting an xinetd setup.


Please always provide the URL, if you refer to some resource.

But the documentation (man systemd.service) didn't tell me how to 
convert a couple of settings, namely xinetd had "user=" and "group=".

Okay, user= was root, so group= probably doesn't matter either, but
how do you get a service to change user and drop privileges?


systemd has several manual pages. I always look at 
systemd.directives(7), and go to the right one from there. In this case, 
`User=` and `Group=` are documented in systemd.exec(5).

It would be nice to know for the future, even the near future to try
and modify qm/scarletdme so it doesn't need root and lower any
possible attack surface.


Sorry, no idea, what you mean.


Kind regards,

Paul

Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

[Paul Menzel]

Dear Brian,


Am 19.11.21 um 00:34 schrieb Brian Hutchinson:


On Thu, Nov 18, 2021 at 5:48 PM Alvin Šipraga wrote:


On 11/18/21 23:25, Brian Hutchinson wrote:



On Thu, Nov 18, 2021 at 4:20 PM Alvin Šipraga wrote:



 On 11/18/21 01:20, Brian Hutchinson wrote:


[…]


I don't think that will work either.  eth0 has to be up and stay up or
DSA driver won't work at all.  eth0 has to be up or the slaves can't be
added to the bond.


This use-case is also addressed in the newer kernels (>=5.11), see the
below commit. It is not only when a user port is brought up (as I
summarized it), but rather when it is opened.

commit 9d5ef190e5615a7b63af89f88c4106a5bc127974
Author: Vladimir Oltean 
Date:   Fri Feb 5 15:37:10 2021 +0200

  net: dsa: automatically bring up DSA master when opening user port


[…]


Hmm, looks like I might just have to wait a bit until we can step up to
5.11.  We just stepped up to 5.10.69.  IMX8 Freescale yocto lags a bit.
And too bleeding edge hurts.


Well, I know opinions differ on that, but in this case, it obviously 
hurt that you use an old Linux kernel, as the problem you have might be 
already fixed it current Linux kernels.


It’d be great if you verified, that the problem is fixed in Linux 5.15, 
which is also an LTS series, and then maybe get the commits in questions 
into the 5.10.x stable series.


[…]


Kind regards,

Paul

Re: [systemd-devel] Running systemd unprivileged in Docker container

[Paul Menzel]

Dear Johannes,


Am 12.06.21 um 01:55 schrieb Johannes Ernst:

I can run a full Arch system (with systemd as PID 1) in a Docker container in 
Docker privileged mode:
 sudo docker run -i -t --privileged archlinux /usr/lib/systemd/systemd
but privileged mode is, well, a bit privileged. I believe used to be able to 
tone this down with something like:

 sudo docker run -i -t --cap-add=ALL -v /sys/fs/cgroup:/sys/fs/cgroup:ro 
archlinux /usr/lib/systemd/systemd
or even less capabilities than "all". But now I'm getting:

 systemd 248.3-2-arch 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 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP 
-SYSVINIT default-hierarchy=unified)
 Detected virtualization docker.
 Detected architecture x86-64.
 Detected first boot.

 Welcome to Arch Linux!

 Initializing machine ID from random generator.
 Failed to create /init.scope control group: Read-only file system
 Failed to allocate manager object: Read-only file system
 [!!] Failed to allocate manager object.
 Exiting PID 1...
I don't understand what that means. (Somebody likes exclamation marks.) What's the 
"manager object", and who is trying to allocate it?

Assuming that the "Read-only filesystem" in question is that /sys/fs/cgroup, 
when binding it into the container as read-write I get that instead:

 Failed to create /init.scope control group: No such file or directory
 Failed to allocate manager object: No such file or directory
This long Serverfault thread 

 may be related? Are they saying it's broken? Can it be done?

Posted this earlier  in the Arch 
forum, lots of views, no answers.


There are some issues in the systemd issue tracker like *systemd 248 
broke read-only /sys/fs/cgroup mount in docker #19245* [1]. Do they 
apply to your problem?


Also, unprivileged Docker environment with systemd inside does not work 
well. The systemd folks say, that Docker needs to implement the 
container interface [2][3], which it does not do. Other container 
manager like Podman [4] do that.



Kind regards,

Paul


[1]: https://github.com/systemd/systemd/issues/19245
[2]: https://github.com/systemd/systemd/issues/17320
[3]: https://systemd.io/CONTAINER_INTERFACE
[4]: https://podman.io/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to make the systemd init faster

[Paul Menzel]

Dear Dino,


Am 05.06.21 um 00:08 schrieb Dino Joseph Mycle:


I am trying t improve my embedded system boot time which uses systemd.
debugging understood that it spends lot time around ~1.3 second in my iMX6
board running @800MHz on initialization of the systemd

plotting  the graph using “systemd-analyze plot > /tmp/bootime.svg “ i am
seeing that, it spend around 1 second reading config file and generating
dynamic file at /run/systemd. And then it start executing unit files


What does `systemd-analyze` output?

Please share that file, and read up a little about analyzing the boot 
time. As far as I know, that command is not very suitable for that and 
more or less plots the unit, which I would not consider “systemd init”. 
Please look into systemd-bootchart for example.


What distribution and systemd version do you use?


My questions are, since its an embedded system where the hardware and
configuration are always constant once you build the image so all these
dynamic stuff reading from files are not required

1)  what all i should be doing to make the boot faster


These questions (with the ones below) are too general and not suitable 
to discuss in one thread. Please start separate threads for each of 
them, and provide more data. For a general introduction into the topic I 
recommend to read the slides of the course *embedded Linux boot time 
optimization* by Bootlin [1]. (It only has one slide for systemd though, 
but – as written – please look into systemd-bootchart.)



2)  is there a way I can configure the files statically at compile
time, which will reduce the time of reading each file from eMMC.


(What files?)


3)  How can I disable the mounting of the root partition from the
systemd-generators as I see the kernel mounts it in my systemd and gets
remounted, even though I commented the line in fstab


(Add `systemd.log_level=debug`, and analyze what generators are run, 
read the manual of the generator, and find out how to disable it, or 
just delete it.)



Kind regards,

Paul


[1]: 
https://bootlin.com/blog/new-training-course-embedded-linux-boot-time-optimization/

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

Re: [systemd-devel] DHCP6 client failing when /etc is mounted as overlayfs

[Paul Menzel]

[Sorry for the duplicate.]

Dear Alessandro,


Am 01.06.21 um 23:32 schrieb Alessandro Tagliapietra:

It seems that while DHCP6 doesn't return any error now and the DUID is
the same after reboot and after network restart by our agent:

DHCP6 Client DUID: DUID-EN/Vendor:ab118bf885a2ab7335a0

it never gets a DHCP6 IP after network restart and the state stays in
"configuring".

Logs only show

DHCPv6 lease lost
IPv6 successfully enabled


This looks like a new issue. A new thread or even report in the issue 
tracker would be good. (At least it looks unrelated to overlayfs.)



and only a reboot fixes the problem. I think I'll probably just move
on and remove ipv6 support from the kernel (as it seems that changing
the default and all values from sysctl doesn't apply to networkd).


I think you can add `ipv6.disable=1` to the Linux kernel command line to 
achieve that, and that is respected by systemd-networkd (as it’s 
disabled in the Linux kernel) [1]. `ipv6.disable_ipv6=1` is ignored in 
my experience, because systemd-networkd writes to sysfs directly. (I 
have not analyzed that.)



Kind regards,

Paul


[1]: https://www.kernel.org/doc/html/latest/networking/ipv6.html
___
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

[Paul Menzel]

[Sorry for the duplicate.]

Dear Greg, dear Mantas, dear Daniele,


Am 02.06.21 um 07:37 schrieb Mantas Mikulėnas:

On Wed, Jun 2, 2021, 08:04 Greg KH  wrote:


On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:

Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH <

gre...@linuxfoundation.org>:

Works for me!  Make sure you are not trying to connect to 'https'.


No https? Why?


Because why would serving up text files about this topic requires https?


Because browsers are starting to default to "https:" if not specified
otherwise, and visitors now have to scratch heads and jump through hoops to
access those text files.


HTTPS is also good for authenticating the server and not only for 
encryption.



If you don't do HTTPS, at least shut off the HTTPS listener
completely or make it redirect to the HTTP version, instead of just
leaving visitors stare at a 503 page that's pretty much 
indistinguishable from "the CGI backend gave up five reboots ago".


$ LANG=C curl -I https://www.linux-usb.org/
curl: (7) Failed to connect to www.linux-usb.org port 443: 
Connection refused


(Daniele just replied the same.)

Port 443 is open though for linux-usb.org, and the user gets an error:

$ LANG=C curl -I https://linux-usb.org
curl: (60) SSL: no alternative certificate subject name matches 
target host name 'linux-usb.org'

[…]


Kind regards,

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

[systemd-devel] systemd-networkd: How to configure network with environment variables?

[Paul Menzel]

Dear systemd folks,


Due to historical reasons, in our environment we have a configuration 
file with the network device name and the to be assigned IP address:


$ more /etc/local/mxhost.conf
MX_NETDEV=net02
MX_IPADDR=141.14.18.X

Then a custom service unit `network.service` [1] configures the network 
with the configuration file as environment file.


[Unit]
Description=Network Connectivity
DefaultDependencies=no

[Service]
EnvironmentFile=/etc/local/mxhost.conf
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/mxnetctl start
ExecStart=/sbin/ip addr add ${MX_IPADDR}/20 broadcast 141.14.31.255 
dev ${MX_NETDEV}

ExecStart=/sbin/ip link set up dev ${MX_NETDEV}
ExecStart=/sbin/ip route add default via 141.14.16.X
ExecStop=/sbin/ip addr del ${MX_IPADDR}/20 dev ${MX_NETDEV}
StandardOutput=syslog

[Install]
WantedBy=network.target

Wanting to use systemd-network but keeping local device configuration in 
`/etc/local` is there an easy way? systemd.network(5) does not say 
anything about, that environment variables could be used.


If that does not work, do you have another suggestion? Possible, but not 
nice, solutions, I came up with:


1.  Use a generator to create .network files from `/etc/local/mxhost.conf`.

2.  Convert `/etc/local/mxhost.conf` manually to 
`/etc/local/mxhost.network` and add a symbolic link from 
`/etc/systemd/network` to that file.



Kind regards,

Paul


[1]: 
https://github.molgen.mpg.de/mariux64/mxtools/blob/master/misc_systemd_units/network.service

[2]: https://www.freedesktop.org/software/systemd/man/systemd.network.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] log_assert_failed_realm crash in systemd journal-file

[Paul Menzel]

Dear Aditya,


Am 21.12.20 um 04:30 schrieb Aditya Tayade:


Could you please help with this.


I think, you testing applying the patch or upgrading to a newer systemd 
version will give you the quickest results. Upstream systemd only 
support the last two releases.



Kind regards,

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

[systemd-devel] systemd-networkd and GNOME integration

[Paul Menzel]

Dear systemd folks,


For several GNOME systems, systemd-networkd is an alternative to the 
NetworkManager. For example, desktop systems with a plugged in Ethernet 
cable, which do not use wireless devices. As systemd-networkd is often 
not packaged separately by distributions, it’s a viable option to not 
install NetworkManager on these systems for space and speed (and even 
security) reasons.



Am 18.12.20 um 21:56 schrieb Florian Müllner:

It’d be great, if the network indicator could also talk to
systemd-networkd.


Sorry, but our policy is to integrate one technology well, instead of
trying to support different alternatives to different extents.

That has been tried for NetworkManager alternatives in the past, and I
don't see how systemd-networkd is different. That is, unless we
expect it to replace NetworkManager eventually, we are not going to
add support.

That said, systemd-networkd probably provides a D-Bus API, so it
should be possible for an extension to provide that support.


I assume, that GNOME Shell’s indicator is part of the network settings, 
meaning, that right clicking it, should allow to configure the whole 
network? Then indeed, seamless integration would be hard, unless 
systemd-networkd somehow implements the NetworkManager API?


There several network daemons out there, like ConnMan. A (seemingly 
unmaintained) GNOME Shell extension exists [2].


So, would a generic network indicator applet work, just showing the 
current network status with IP address and no configuration? The daemons 
could implement that API? Is that realistic? Does such a simple API 
exist already?



Kind regards,

Paul


[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3419
[2]: https://github.com/jgke/gnome-extension-connman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Timestamps in journal during suspend/resume

[Paul Menzel]

Dear systemd folks,


Using Debian sid/unstable with systemd 246.5, suspend and resuming a 
Dell Precision 3540 the timestamps below can be seen.


```
Nov 28 19:58:47.516555 morley systemd[1]: Reached target Sleep.
Nov 28 19:58:47.517585 morley systemd[1]: Starting Suspend...
Nov 28 19:58:47.525240 morley systemd[1]: Stopping Atop advanced 
performance monitor...
Nov 28 19:58:47.603491 morley wpa_supplicant[690]: nl80211: deinit 
ifname=p2p-dev-wlo1 disabled_11b_rates=0

Nov 28 19:58:47.759586 morley systemd[1]: atop.service: Succeeded.
Nov 28 19:58:47.759790 morley systemd[1]: Stopped Atop advanced 
performance monitor.

Nov 28 19:58:47.761552 morley systemd-sleep[15059]: Suspending system...
Nov 28 19:58:47.762380 morley kernel: PM: suspend entry (s2idle)
Nov 28 19:58:47.766488 morley wpa_supplicant[690]: nl80211: deinit 
ifname=wlo1 disabled_11b_rates=0

Nov 28 22:44:50.643707 morley kernel: Filesystems sync: 0.005 seconds
Nov 28 22:44:50.646269 morley kernel: (NULL device *): firmware: 
direct-loading firmware i915/kbl_dmc_ver1_04.bin
Nov 28 22:44:50.646329 morley kernel: (NULL device *): firmware: 
direct-loading firmware regulatory.db
Nov 28 22:44:50.646359 morley kernel: (NULL device *): firmware: 
direct-loading firmware regulatory.db.p7s
Nov 28 22:44:50.646384 morley kernel: (NULL device *): firmware: 
direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-46.ucode

Nov 28 22:44:50.646417 morley kernel: Freezing user space processes ...
Nov 28 22:44:50.646451 morley kernel: [drm] PCIE GART of 256M enabled 
(table at 0x00F4).
Nov 28 22:44:50.646479 morley kernel: [drm] UVD and UVD ENC initialized 
successfully.

Nov 28 22:44:50.646511 morley kernel: [drm] VCE initialized successfully.
Nov 28 22:44:50.646543 morley kernel: (elapsed 0.494 seconds) done.
Nov 28 22:44:50.646580 morley kernel: OOM killer disabled.
Nov 28 22:44:50.646613 morley kernel: Freezing remaining freezable tasks 
... (elapsed 0.001 seconds) done.
Nov 28 22:44:50.646646 morley kernel: printk: Suspending console(s) (use 
no_console_suspend to debug)

Nov 28 22:44:50.646667 morley kernel: e1000e: EEE TX LPI TIMER: 0011
Nov 28 22:44:50.646688 morley kernel: ACPI: EC: interrupt blocked
Nov 28 22:44:50.646710 morley kernel: ACPI: EC: interrupt unblocked
Nov 28 22:44:50.646730 morley kernel: [drm] PCIE GART of 256M enabled 
(table at 0x00F4).
Nov 28 22:44:50.646747 morley kernel: [drm] UVD and UVD ENC initialized 
successfully.

Nov 28 22:44:50.646764 morley kernel: [drm] VCE initialized successfully.
Nov 28 22:44:50.646781 morley kernel: OOM killer enabled.
Nov 28 22:44:50.646799 morley kernel: Restarting tasks ... done.
Nov 28 22:44:50.643826 morley rtkit-daemon[954]: The canary thread is 
apparently starving. Taking action.

Nov 28 22:44:50.646521 morley systemd-logind[688]: Lid opened.
Nov 28 22:44:50.643833 morley rtkit-daemon[954]: Demoting known 
real-time threads.

```

At least to me, some of the entries with timestamps from resuming should 
have timestamps from suspending. Is the reason, that “suspend message“ 
was only written to the journal after resume?


Is there a way to access the Linux kernel timestamp from within the journal?


Kind regards,

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

[systemd-devel] Fwd: [coreboot] Upcoming virtual OSFC 2020

[Paul Menzel]

Dear systemd folks,


Some of you might be interested in firmware. The Open Source Firmware 
Conference 2020 [1] is going to start today.



Kind regards,

Paul


[1]: https://osfc.io
--- Begin Message ---
Hello people,

This is a last reminder on the upcoming OSFC 2020 (www.osfc.io) which will 
start tomorrow noon CET.
If you are interested in attending the conference, please get your tickets via 
https://hopin.com/events/osfc-2020

Best regards,
Philipp
___
coreboot mailing list -- coreb...@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
--- End Message ---
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] jio test results

[Paul Menzel]

Dear Vito,


Am 26.11.20 um 19:54 schrieb Vito Caputo:

On Thu, Nov 26, 2020 at 12:28:16PM +0100, Paul Menzel wrote:


[…]


Thank you. It builds fine on Debian Sid/unstable with GCC 10.2.0-19 (some
warnings), and the results are attached.


Any chance you could mail me the warnings?  I see none here, would
prefer a clean build for others.


Hopefully there won’t be line wrapping when viewed with `format=flowed`.

```
$ gcc --version
gcc (Debian 10.2.0-19) 10.2.0
[…]
$ make
[…]
  CC   jio-journals.o
journals.c: In function ‘got_hash_table_iter_object_header’:
journals.c:361:4: warning: converting a packed ‘HashedObjectHeader’ 
pointer (alignment 1) to a ‘DataObject’ pointer (alignment 8) may result 
in an unaligned pointer value [-Waddress-of-packed-member]

  361 |DataObject *data_object = (DataObject *)iter_object_header;
  |^~
In file included from journals.h:14,
 from journals.c:30:
upstream/journal-def.h:80:8: note: defined here
   80 | struct HashedObjectHeader {
  |^~
upstream/journal-def.h:95:8: note: defined here
   95 | struct DataObject DataObject__contents;
  |^~
journals.c:372:4: warning: converting a packed ‘HashedObjectHeader’ 
pointer (alignment 1) to a ‘FieldObject’ pointer (alignment 8) may 
result in an unaligned pointer value [-Waddress-of-packed-member]

  372 |FieldObject *field_object = (FieldObject *)iter_object_header;
  |^~~
In file included from journals.h:14,
 from journals.c:30:
upstream/journal-def.h:80:8: note: defined here
   80 | struct HashedObjectHeader {
  |^~
upstream/journal-def.h:105:8: note: defined here
  105 | struct FieldObject FieldObject__contents;
  |^~~
[…]
```


Kind regards,

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

Re: [systemd-devel] Mounting / as writable without in `/etc/fstab`

[Paul Menzel]

Dear Mantas,



Thank you for your detailed reply.


Am 26.11.20 um 09:12 schrieb Mantas Mikulėnas:

On Mon, Nov 23, 2020 at 5:23 PM Paul Menzel wrote:



Is an entry for / in `/etc/fstab` still needed, or is there a systemd
way of doing it?


That *is* the systemd way -- the fstab entry will be read by
systemd-remount-fs(8) and the new mount options applied.


Thank you. That wasn’t clear to me.


Installing Debian bullseye/testing with the Debian Installer, it creates
a GPT and `/etc/fstab`. [...]
Commenting out the entries for `/`, the root partition is mounted as
read-only.

  $ findmnt /
  TARGET SOURCE FSTYPE OPTIONS
  /  /dev/nvme0n1p2 ext4   ro,relatime

Shouldn’t it be mounted as writable?


No, if you had it initially mounted with 'ro' and did not leave any
instructions for remounting, then it won't be remounted...


Understood.



  $ sudo /lib/systemd/systemd-remount-fs
  $ findmnt /
  TARGET SOURCE FSTYPE OPTIONS
  /  /dev/nvme0n1p2 ext4   rw,relatime,errors=remount-ro


Sorry, that was my confusion. I checked it again, and I messed up during 
testing. This result was with the entry for / present in `/etc/fstab`, 
that means not commented out.



The log says:

  [2.320133] systemd[179]: 
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator succeeded.

I can work around it changing `ro` to `rw` on the Linux command line,
but I thought, it is possible without that.


I would say that having the initramfs directly mount the filesystem as rw
is the *preferred method*, not a workaround... Of course it depends on how
your distro's initramfs wants to work, but at least that's what Arch does
-- since fsck is run from the initramfs, there's not much point in later
mounting it ro at all.


Sorry, I didn’t understand that last paragraph. I thought, it’s 
desirable to first mount it ro, so fsck can run, and then remount it as 
read-writable?


My use case is to boot without initramfs. But, now that I know, that 
`/etc/fstab` is there to stay, I know what to do.



Kind regards,

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

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

[Paul Menzel]

Dear Frank,


Am 24.11.20 um 16:35 schrieb 海阔天空:


I need to turn off the ntp time synchronization in default when power on, how 
to do it?
Should I stop to launch "systems-timesyncd.service" when power on？
It would be appreciated if you could tell me what to do.


Please read the manual systemd-timesyncd(8) (`man 8 systemd-timesyncd`).

   timedatectl set-ntp false

should stop and disable it.


Kind regards,

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

[systemd-devel] Mounting / as writable without in `/etc/fstab`

[Paul Menzel]

Dear systemd folks,


Is an entry for / in `/etc/fstab` still needed, or is there a systemd 
way of doing it?


Installing Debian bullseye/testing with the Debian Installer, it creates 
a GPT and `/etc/fstab`.


$ systemd --version
systemd 246 (246.6-2)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID 
+ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid


```
$ sudo gdisk /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Model: SAMSUNG MZVKW512HMJP-0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): E367AC65-C92D-4600-8071-7F122612CC59
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)End (sector)  Size   Code  Name
   12048 1050623   512.0 MiB   EF00
   2 1050624   998215679   475.5 GiB   8300
   3   998215680  1000214527   976.0 MiB   8200
```

```
$ more /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
#
# / was on /dev/nvme0n1p2 during installation
UUID=d23ce27e-5c5c-45fb-bfa8-79a87caff13f /   ext4 
errors=remount-ro 0   1

# /boot/efi was on /dev/nvme0n1p1 during installation
#UUID=FCD0-628D  /boot/efi   vfatumask=0077  0   1
# swap was on /dev/nvme0n1p3 during installation
UUID=ab3adb78-b618-48d3-8316-3177f20b03f8 noneswapsw 
 0   0

```

Commenting out the entries for `/`, the root partition is mounted as 
read-only.


$ findmnt /
TARGET SOURCE FSTYPE OPTIONS
/  /dev/nvme0n1p2 ext4   ro,relatime

Shouldn’t it be mounted as writable?

$ sudo /lib/systemd/systemd-remount-fs
$ findmnt /
TARGET SOURCE FSTYPE OPTIONS
/  /dev/nvme0n1p2 ext4   rw,relatime,errors=remount-ro

The log says:

[2.320133] systemd[179]: 
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator succeeded.


I can work around it changing `ro` to `rw` on the Linux command line, 
but I thought, it is possible without that.



Kind regards,

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

Re: [systemd-devel] Journald retaining logs for only 10 days

[Paul Menzel]

Dear Nikolaus,


Am 14.11.20 um 10:31 schrieb Nikolaus Rath:


I just discovered that on one of my systems journald only retains log
entries for about 10 days:

# journalctl | head -1
-- Logs begin at Wed 2020-11-04 15:57:13 UTC, end at Sat 2020-11-14 09:28:19 
UTC. --

I do not understand what could cause this, because I have no retention
limit configured, and the logs take up way less space than I have
reserved:

# journalctl --disk-usage
Archived and active journals take up 320.0M in the file system.

# journalctl > alllogs
# ls -lh alllogs
-rw-r--r-- 1 root root 27M Nov 14 09:24 alllogs


What size does adding the switch `-a` result in? From journalctl(1):


   -a, --all
   Show all fields in full, even if they include unprintable
   characters or are very long. By default, fields with unprintable
   characters are abbreviated as "blob data". (Note that the pager may
   escape unprintable characters again.)



Can someone help me understand where the log entries have gone?

# journalctl --version
systemd 241 (241)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid

# grep -vE '^#' /etc/systemd/journald.conf

[Journal]
SystemMaxUse=300M


The number shown by disk usage (320 MB) is higher than 300 MB. Maybe 
also check the files in `/var/log/journal`.



Kind regards,

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

Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)

[Paul Menzel]

Dear PGNet,


Am 12.07.20 um 07:54 schrieb PGNet Dev:

On 6/16/20 1:35 AM, Lennart Poettering wrote:

On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote:



IS there a backport of this^^ fix available for v234 that popped
up in the meantime?

If not, as is likely, is there a "safe" workaround for quieting
the fail, and rm'ing the associated boot delay?  Is rm'ing either the
"Also=" or "WantedBy=" a reasonable band-aid?

Or, some other approach?


You could use RequiredForOnline= in the bridge's .network file to mark
it as irrelevant for systemd-network-wait-online.



On my current machine, just upgraded to new OS version (still same
distro -- for the moment) I've,

  networkctl
  IDX LINK TYPE   OPERATIONAL SETUP
1 lo   loopback   carrier unmanaged
2 enp3s0   ether  no-carrier  configuring
3 enp5s0   ether  routableconfigured

infc #3 is active; intfc #2 is unused

I added to each

cd /etc/systemd/network
grep Link -A1 *
  20-enp3s0.network:[Link]
  20-enp3s0.network-RequiredForOnline=no
  --
  20-enp5s0.network:[Link]
  20-enp5s0.network-RequiredForOnline=no

and rebooted.

still, there's a 2min delay on startup

systemd-analyze blame | head
   2min 284ms systemd-networkd-wait-online.service
   5.803s dkms.service
   5.409s rc-local.service
   4.270s mariadb-custom.service
   3.952s after-local.service
   3.647s udisks2.service
   2.985s rpcbind.service
   2.936s mcelog.service
   2.901s ca-certificates.service
   2.878s smartd.service

in dmesg,

  dmesg | grep wait-online -A1 -B1
   [  129.299191] systemd[1]: Started update geoipdb service.
   [  130.961418] systemd-networkd-wait-online[1664]: Event loop failed: 
Connection timed out
   [  130.971019] systemd[1]: systemd-networkd-wait-online.service: Main 
process exited, code=exited, status=1/FAILURE
   [  130.971276] systemd[1]: Failed to start Wait for Network to be Configured.
   [  130.974180] systemd[1]: systemd-networkd-wait-online.service: Unit 
entered failed state.
   [  130.974187] systemd[1]: systemd-networkd-wait-online.service: Failed with 
result 'exit-code'.
   [  130.974266] systemd[1]: Reached target Network is Online.

other than the two interfaces I _do_ have -- and have set

  [Link]
  RequiredForOnline=no

for, what's possibly _still_ causing this delay?

this^ is, as before, with

  rpm -qa | grep ^systemd-2
   systemd-234-lp152.30.1.x86_64

switching back to non-systemd-networkd network stack eliminates any such delay.
not surprising, given the bug -- and certainly not ideal.


If systemd is still the same, your distribution upgrade wasn’t relevant 
to the issue at hand, was it?


The upstream project only supports the latest two versions of systemd, 
which currently are 244 and 245. Please report your issues to openSUSE.



Kind regards,

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

Re: [systemd-devel] systemd-networkd packet loss Ubuntu 18.04 (systemd 237)

[Paul Menzel]

Dear Luke,


On 2020-07-08 13:10, Luke Alexander wrote:

> I had a look through some of the issues against the systemd github repo but
> could not find any matching - there were a couple which look promising but
> don't completely resolve our issue.
> 
> Our issue is that we have a k8s (1.18, kube-router CNI) cluster comprised
> of a number of Ubuntu 16.04 nodes, we are in the process if upgrading the
> nodes to Ubuntu 18.04 - however after upgrading the first node and adding
> it back to the cluster we observed high packet loss from other cluster
> nodes to the 18.04 node as well as ping error messages when running a
> continuous ping from the 18.04 node to another node in the cluster, eg:
> 
> 64 bytes from 10.8.11.1: icmp_seq=91 ttl=64 time=0.088 ms
> 64 bytes from 10.8.11.1: icmp_seq=92 ttl=64 time=0.076 ms
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> 
> Another observation is that one of our daemonset pods (promtail) could not
> start.
> 
> systemctl --version
> systemd 237
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN
> -PCRE2 default-hierarchy=hybrid
> 
> After many days of troubleshooting various possibilities, changing network
> cable, NIC, a different server, various sysctl values, I eventually tried
> switching from systemd-networkd to NetworkManager as the backend via
> netplan config. After rebooting the server with NetworkManager in place and
> re-adding the node back to the k8s cluster, the packet loss disappeared as
> did the ping errors and the daemonset pod (promtail) also started normally.
> 
> I would like to use Ubuntu's default of systemd-networkd to handle our
> NIC/route config - but cannot until I've figured out what in
> systemd-networkd is breaking.
> 
> Any help is much appreciated on this matter.

Unfortunately, upstream only supports the last two upstream versions of
systemd. Please report the issue to the Ubuntu bug tracker Launchpad [1].
It would probably help to verify, if the issue is still present in the newest
version. So maybe try Ubuntu 20.04 first to see if it’s fixed there.
Otherwise, building systemd yourself in Ubuntu should be doable too.

I am sorry for the unsatisfying answer.


Kind regards,

Paul


[1]: https://bugs.launchpad.net/ubuntu/+source/systemd



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: systemctl kill: "Invalid who argument 15862"

[Paul Menzel]

Dear Ulrich,


Am 06.05.20 um 11:21 schrieb Ulrich Windl:


I have a question for systemd-228-150.82.1.x86_64 (of SLES12 SP4):
While developing a script for logrotate, I tested this command with the
following result:

# systemctl kill -s HUP --kill-who=15862 iotwatch@LOC1.service
Failed to kill unit iotwatch@LOC1.service: Invalid who argument 15862


[…]


Did I misinterpret the manual page, or what is the problem?

--kill-who=
When used with kill, choose which processes to send a signal to.
Must be one of main, control or all to select whether to kill only
the main process, the control process or all processes of the
unit.


I understand it, that only *main*, *control* or *all* are valid arguments.


Kind regards,

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

Re: [systemd-devel] Fwd: systemd for petitboot as linux payload (x230)

[Paul Menzel]

Dear systemd folks,


Am 20.04.20 um 11:47 schrieb Lennart Poettering:

On Mo, 20.04.20 10:52, Robin C (amisbie...@posteo.net) wrote:



Hi everyone,

I'm curruntly trying to build petitboot for my lenovo x230 (actualy runs
coreboot + tianocore).

I use this tutorial to build it:
https://www.raptorengineering.com/content/kb/1.html

I think it is not up to date, can anyone confirme or not? I'm stuck on the
first part, buildind systemd... I have this errors:

In file included from ../src/basic/errno-list.c:31:0:
./src/basic/errno-from-name.h:143:1: error: conflicting types for ‘lookup_errno’
  lookup_errno (register const char *str, register size_t len)
  ^~~~
../src/basic/errno-list.c:27:33: note: previous declaration of ‘lookup_errno’ 
was here
  static const struct errno_name* lookup_errno(register const char *str,
  ^~~~


gperf changed its output some time back. You need to have a newer
gperf (or if you build an older version of systemd, an older one) to
build systemd.


Maybe the configure script can check the version. I created an issue [1].


Kind regards,

Paul


[1]: https://github.com/systemd/systemd/issues/15492
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Paul Menzel]

Dear Lennart,


Am 01.04.20 um 17:10 schrieb Lennart Poettering:

On Mi, 01.04.20 14:23, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:


After=device should work. udev announces device after all rules have
been processed.


After= only orders, but this doesn't pull the device unit into the job
queue. To do that, you need to add Wants= on the device unit as well.


Trying this,

 After=dev-dri-card0.device
 Wants=dev-dri-card0.device

the service times out waiting for the device.

 $ journalctl -a
 […]
 Apr 01 14:15:42.672430 kodi systemd[1]: Reached target Multi-User System.
 […]
 Apr 01 14:17:09.805001 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start timed out.
 Apr 01 14:17:09.805839 kodi systemd[1]: Timed out waiting for device 
/dev/dri/card0.
 Apr 01 14:17:09.806464 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start failed with result 'timeout'.
 Apr 01 14:17:09.809847 kodi systemd[1]: Starting Weston, a Wayland 
compositor, as a system service...
 […]
 $ ls -l /dev/dri/card0
 crw-rw 1 root video 226, 0 Apr  1 14:15 /dev/dri/card0


DRM devices are currently not tagged with "systemd", and thus no
.device units are syntesized for them in systemd. Add a udev rule that
matches against them and sets the "systemd" tag and they will appear
in systemd, so that you can order your stuff against it.


That did the trick. In `systemd-analyze critical-chain` the device shows 
up with three seconds. Quite a lot, but unfortunately the Linux drivers 
do not seem to be optimized for speed.


But my problem turned out to be something else. getty@tty1.service and 
Weston on tty1 were apparently conflicting causing the permission denied 
errors, and adding `Conflict=getty@tty1.service` seems to have fixed it.


I created merge/pull request #15307 for adding the tags anyway [1].


Kind regards,

Paul


[1]: https://github.com/systemd/systemd/pull/15307
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Paul Menzel]

Dear Andrei, dear Lennart,


Thank you very much for your answers.

Am 31.03.20 um 17:09 schrieb Lennart Poettering:

On Do, 19.03.20 20:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:


19.03.2020 19:47, Paul Menzel пишет:



I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.

I amtrying to start a graphical desktop as soon as possible. Currently,
I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
permission denied error. The Weston service unit is ordered after
`systemd-logind.service`.

Weston now fails to start, because it gets a permission denied error
accessing `/dev/dri/card0` [1][2].

     drmModeSetCrtc(backend->drm.fd, output->crtc_id,
scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);

Right before Weston starts, the permission and ownership are like below.

     $ ls -l /dev/dri:
     insgesamt 0
     crw--- 1 root root 226,   0 Mär 19 17:29 card0
     crw--- 1 root root 226, 128 Mär 19 17:29 renderD128

After udev applied the rules, it looks like below, meaning users in
group `video` are allowed to access the device.

     $ ls -l /dev/dri
     insgesamt 0
     drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
     crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
     crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128

Is there a way to order a service in such a way, that it’s guaranteed
that udev rules to devices were applied?


After=device should work. udev announces device after all rules have
been processed.


After= only orders, but this doesn't pull the device unit into the job
queue. To do that, you need to add Wants= on the device unit as well.


Trying this,

After=dev-dri-card0.device
Wants=dev-dri-card0.device

the service times out waiting for the device.

$ journalctl -a
[…]
Apr 01 14:15:42.672430 kodi systemd[1]: Reached target Multi-User 
System.

[…]
Apr 01 14:17:09.805001 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start timed out.
Apr 01 14:17:09.805839 kodi systemd[1]: Timed out waiting for 
device /dev/dri/card0.
Apr 01 14:17:09.806464 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start failed with result 'timeout'.
Apr 01 14:17:09.809847 kodi systemd[1]: Starting Weston, a Wayland 
compositor, as a system service...

[…]
$ ls -l /dev/dri/card0
crw-rw 1 root video 226, 0 Apr  1 14:15 /dev/dri/card0


Kind regards,

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

[systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Paul Menzel]

Dear systemd folks,


I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.

I amtrying to start a graphical desktop as soon as possible. Currently, 
I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a 
permission denied error. The Weston service unit is ordered after 
`systemd-logind.service`.


Weston now fails to start, because it gets a permission denied error 
accessing `/dev/dri/card0` [1][2].


drmModeSetCrtc(backend->drm.fd, output->crtc_id, 
scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);


Right before Weston starts, the permission and ownership are like below.

$ ls -l /dev/dri:
insgesamt 0
crw--- 1 root root 226,   0 Mär 19 17:29 card0
crw--- 1 root root 226, 128 Mär 19 17:29 renderD128

After udev applied the rules, it looks like below, meaning users in 
group `video` are allowed to access the device.


$ ls -l /dev/dri
insgesamt 0
drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128

Is there a way to order a service in such a way, that it’s guaranteed 
that udev rules to devices were applied?


A small script applying permissions and ownership manually in 
`ExecStartPre=` seems to work around the (graphics) issue.


If it cannot be solved with ordering, what would you suggest?

[1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
[2]: 
https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741

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

[systemd-devel] Best practices for starting unit only if network is online

[Paul Menzel]

Dear systemd folks,


fwupd ships the service unit `fwupd-refresh.service` with the ordering 
below [1].


After=network.target network-online.target systemd-networkd.service 
NetworkManager.service connman.service


I would have thought ordering after `network-online.target` would be 
enough. Are there best practices for ensuring that the network is working?


(As a sidenote, the service seems to be only activated by a timer [2], 
so network will be up probably.)



Kind regards,

Paul


[1]: 
https://github.com/fwupd/fwupd/blob/4f28afb6e720215a33805f37d1845ec425a45256/data/motd/fwupd-refresh.service.in#L4
[2]: 
https://github.com/fwupd/fwupd/blob/master/data/motd/fwupd-refresh.timer

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

Re: [systemd-devel] Service fails to start with no log messages

[Paul Menzel]

Dear Jeffrey,


On 2020-01-07 03:17, Jeffrey Walton wrote:

[…]

> There are absolutely 0 entires about my monitor service:
> 
> $ journalctl -e | grep -i callboot | grep monitor
> $

The switch `-e` implies that by default only 1000 lines are shown.

   -e, --pager-end
   Immediately jump to the end of the journal inside the implied
   pager tool. This implies -n1000 to guarantee that the pager will
   not buffer logs of unbounded size. This may be overridden with an
   explicit -n with some other numeric value, while -nall will
   disable this cap. Note that this option is only supported for the
   less(1) pager.

Does `journalctl -b | grep -i callboot` show something? `-b` only shows log
messages for the current boot.

[…]


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to apply for partition type GUID for Linux /boot?

[Paul Menzel]

Dear Arseny,


On 2019-11-28 15:10, Arseny Maslennikov wrote:
> On Wed, Nov 27, 2019 at 01:13:52PM +0100, Lennart Poettering wrote:
>> On Mi, 27.11.19 12:43, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
>> wrote:
>>
>>> Dear systemd folks,
>>>
>>> A partition type GUID [1] for the partition to be mounted under `/boot`
>>> when started with Linux would be nice. For example, there is already one
>>> for FreeBSD /boot [2].
>>>
>>> As you seem to have requested one for the freedesktop.org shared boot
>>> loader partition already, could you please share the application process
>>> for such a partition type GUID?
>>
>> The great thing about UUIDs are that they are an unmanaged
>> namespace. Anyone can pick one, as long they generate them properly
>> (which today means pulling from a good /dev/urandom).
>>
>> Hence there's no requesting or registration, you just pick one,
>> that's it.
>>
>> I don't know what you expect /boot to be. In the systemd context we
>> defined the "extended boot loader partition", which is a place you can
>> place kernels and stuff, if you don't want to use the EFI ESP for
>> that, and sd-boot and our userspace tools look in it too. It's
>> automatically discovered and mounted to /boot if it exists, by
>> systemd-gpt-auto-generator.
>>
>> This extended boot loader partition as GPT type UUID
>> bc13c2ff-59e6-4262-a352-b275fd6f7172 and that's documented in the
>> systemd-gpt-auto-generator(8) man page.
> 
> The spec at freedesktop.org[1], (naturally) being the first Google hit
> for "discoverable partitions spec" and also being referred to from a lot
> of places all over the community[2][3][4][5][6], has no mention of the
> extended boot loader partition.
> I did not find it at systemd.io (which is, AFAIK, generated from the
> source).
> Is the page unmaintained? If it is: was it moved? are there any
> official, maintained pages for the spec visible and citable on the web?

Isn’t it [7]?

> Otherwise, if the OS is installed on a disk with GPT disk label, and
> if the ESP partition already exists but is too small, a new suitably
> sized (let’s say 500MB) partition with GPT type GUID of
> bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should
> be used as $BOOT.

Do you mean the term is missing there?


Kind regards,

Paul


> [1]https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> 
> [2]https://forum.manjaro.org/t/discoverable-partitions-specification/104505
> [3]https://lists.freedesktop.org/archives/systemd-devel/2014-March/017817.html
> [4]https://en.wikipedia.org/wiki/GUID_Partition_Table
> [5]https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
> [6]https://wiki.archlinux.org/index.php/GPT_fdisk
[7]: https://systemd.io/BOOT_LOADER_SPECIFICATION



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to apply for partition type GUID for Linux /boot?

[Paul Menzel]

Dear Lennart,


On 2019-11-27 13:13, Lennart Poettering wrote:
> On Mi, 27.11.19 12:43, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
> wrote:

>> A partition type GUID [1] for the partition to be mounted under `/boot`
>> when started with Linux would be nice. For example, there is already one
>> for FreeBSD /boot [2].
>>
>> As you seem to have requested one for the freedesktop.org shared boot
>> loader partition already, could you please share the application process
>> for such a partition type GUID?
> 
> The great thing about UUIDs are that they are an unmanaged
> namespace. Anyone can pick one, as long they generate them properly
> (which today means pulling from a good /dev/urandom).
> 
> Hence there's no requesting or registration, you just pick one,
> that's it.
> 
> I don't know what you expect /boot to be. In the systemd context we
> defined the "extended boot loader partition", which is a place you can
> place kernels and stuff, if you don't want to use the EFI ESP for
> that, and sd-boot and our userspace tools look in it too. It's
> automatically discovered and mounted to /boot if it exists, by
> systemd-gpt-auto-generator.
> 
> This extended boot loader partition as GPT type UUID
> bc13c2ff-59e6-4262-a352-b275fd6f7172 and that's documented in the
> systemd-gpt-auto-generator(8) man page.

Yes, I wanted to use that, but as it was formatted with ext4 the boot
failed [3].

> --
> Lennart Poettering, Berlin

A space is missing after your signature separator [4].


Kind regards,

Paul


[3]: https://github.com/systemd/systemd/issues/14165
[4]: https://de.wikipedia.org/wiki/Signatur_(E-Mails_und_Postings)#Form



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to apply for partition type GUID for Linux /boot?

[Paul Menzel]

Dear systemd folks,


A partition type GUID [1] for the partition to be mounted under `/boot`
when started with Linux would be nice. For example, there is already one
for FreeBSD /boot [2].

As you seem to have requested one for the freedesktop.org shared boot
loader partition already, could you please share the application process
for such a partition type GUID?


Kind regards,

Paul


[1]: https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
[2]: 
https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Problems with DNS resolution in German Rail WiFi

[Paul Menzel]

Dear systemd folks,


Since over half a year, I am having problems with the German Rail WIFI 
(Deutsche Bahn, WIFIonICE) [1]. I am only having problems with the WIFI 
in the train. The WIFI on the train stations (operated by Deutsche 
Telekom(?)) works fine.


I am able to connect to the WIFI network, but accessing the capture page 
to log in, and after logging in, I am having serious DNS problems in the 
browsers (Mozilla Firefox 70.0 and Google Chromium). I am using Debian 
Sid/unstable.


It looks like that, DNS requests are not answered in time (also 
confirmed by the developer tools in the browser). SSH (and even Mozilla 
Thunderbird) seems to work better. The fellow train travelers do not 
seem to have any problems.


Testing on the console shows:

```
$ time host bahn.de
bahn.de has address 18.185.205.203
bahn.de has address 35.157.56.133
bahn.de has address 35.158.56.207
bahn.de mail is handled by 10 mailgate2.deutschebahn.com.
bahn.de mail is handled by 10 mailgate1.deutschebahn.com.

real0m0,243s
user0m0,021s
sys 0m0,000s
$ systemd-resolve bahn.de
bahn.de: resolve call failed: Die Wartezeit für die Verbindung ist 
abgelaufen

$ time systemd-resolve bahn.de
bahn.de: resolve call failed: DNSSEC validation failed: failed-auxiliary

real0m55,967s
user0m0,006s
sys 0m0,006s
$ time systemd-resolve bahn.de
bahn.de: resolve call failed: Die Wartezeit für die Verbindung ist 
abgelaufen


real2m0,094s
user0m0,005s
sys 0m0,007s
$ time systemd-resolve bahn.de
bahn.de: resolve call failed: Die Wartezeit für die Verbindung ist 
abgelaufen


real2m0,113s
user0m0,014s
sys 0m0,000s
```

How can this be debugged (next time I am using the ICE)? Is this 
systemd-resolved related? If not, who should I bug about it?



Kind regards,

Paul


[1]: https://www.bahn.de/p/view/service/zug/railnet_ice_bahnhof.shtml
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How-to for systemd user timers instead of cron/crontab?

[Paul Menzel]

Dear systemd folks,


I couldn’t find a simple documentation for “normal” users how
to use systemd timers instead of cron/crontab? The Arch Wiki
has a page [1], but I am afraid it’s still too complicated
for our users.


Kind regards,

Paul


[1]: https://wiki.archlinux.org/index.php/Systemd/Timers



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Reduce loading time (size) of init program (systemd)

[Paul Menzel]

Dear systemd folks,


In his talk *Linux kernel fastboot on the way* at this years Linux
Plumbers Conference [1][2], Feng Tang (CCed) has the notes below on
the slide for userspace/systemd.

> • Systemd is ~1.5MB - the loading time for emmc is 100ms> • Can we use a 
> small lightweight “init” program, which starts
>   target programs in parallel and readahead to preload libraries
>   and executables?

Are you already aware of these issues? If yes, have you ideas or
suggestions how to solve this? Maybe something to discuss at this
weeks All System Go! 2019.


Kind regards,

Paul


[1]: https://linuxplumbersconf.org/event/4/contributions/281/
[2]: 
https://linuxplumbersconf.org/event/4/contributions/281/attachments/216/617/LPC_2019_kernel_fastboot_on_the_way.pdf



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Paul Menzel]

Dear systemd folks,


On 7/2/19 3:44 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 02, 2019 at 03:39:04PM +0200, ABDUL MAJITH wrote:

>> I am trying to use the Docker in GNS3, when I try to launch it show the
>> error as follows,
>>
>> -- The start-up result is done.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request
>> repeated too quickly.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with
>> result 'exit-code'.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker
>> Application Container Engine.
>> -- Subject: Unit docker.service has failed
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit docker.service has failed.
>> -- 
>> -- The result is failed.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with
>> result 'service-start-limit-hit'.
>> Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache...
>> -- Subject: Unit dnf-makecache.service has begun start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has begun starting up.
>> Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching disabled.
>> Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache.
>> -- Subject: Unit dnf-makecache.service has finished start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has finished starting up.
>> -- 
>> -- The start-up result is done.
>> ...skipping...
>> -- 
>> -- The start-up result is done.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request
>> repeated too quickly.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with
>> result 'exit-code'.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker
>> Application Container Engine.
>> -- Subject: Unit docker.service has failed
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit docker.service has failed.
>> -- 
>> -- The result is failed.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with
>> result 'service-start-limit-hit'.
>> Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache...
>> -- Subject: Unit dnf-makecache.service has begun start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has begun starting up.
>> Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching disabled.
>> Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache.
>> -- Subject: Unit dnf-makecache.service has finished start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has finished starting up.
>> -- 
>> -- The start-up result is done.
>>
>> How to rectify this failure to start the docker application
> 
> This is a problem with docker. Nothing to do with the systemd-devel list.
> Please ask in a forum appropriate for docker issues.

Reading the output above, I can see, why the people contact this mailing
list.

The output has the systemd-devel list listed as support all over the
place.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Collect logs over serial

[Paul Menzel]

Dear systemd/udev folks,


Having a large pool of (different) systems, we hit Linux kernel
panics several times in a year. To better debug those, we want
to make use of the serial ports still present on today’s
systems.

Unfortunately, the serial ports on the back plane, we’d like to
use, are numbered differently. Can you recommend best practices
how to detect where that port is on a system?

Currently, we only do it for port ttyS1, by adding
`console=ttyS1,115200n8` to the Linux kernel command line *on
all systems*, and using the attached script and service unit
template and the server the serial cable is connected to.

```
[Unit]
Description=TTY logger

[Service]
ExecStart=/usr/libexec/serial-log %I
Type=simple
UtmpIdentifier=%I

[Install]
WantedBy=basic.target
```

```
devnam="$1"

while true; do
until /usr/bin/stty -F "/dev/$devnam" 115200 -echo 2>/dev/null; do
sleep 60
done
until cat "/dev/$devnam" >> /var/log/$devnam.log 2>&1;do
sleep 1
done
done
```

Polling the device every 60 seconds is not very elegant, and we
also would like to avoid having to configure each device
manually, where the serial port is.

Does udev/systemd/… have some features solving this more in a
better way?


Kind regards,

Paul
[Unit]
Description=TTY logger

[Service]
ExecStart=/usr/libexec/serial-log %I
Type=simple
UtmpIdentifier=%I

[Install]
WantedBy=basic.target
#! /bin/bash

(($#==1)) || { echo "usage: $0 device-name" >&2; exit 1; }

devnam="$1"

while true; do
until /usr/bin/stty -F "/dev/$devnam" 115200 -echo 2>/dev/null; do
sleep 60
done
until cat "/dev/$devnam" >> /var/log/$devnam.log 2>&1;do
sleep 1
done
done


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Run OpenVPN unprivileged as systemd user service

[Paul Menzel]

Dear systemd folks,


Our users sometimes need to access the internal network of another
organization, but unfortunately SSH access is blocked, and it’s only possible
over OpenVPN. With that, they could use their browser and SSH to access the
internal network.

Due to security reasons, we do not want to allow OpenVPN on our systems, and
wonder, if systemd user service would enable us to run OpenVPN unprivileged for
a user, so that the user has no chance of disturbing other users.

OpenVPN provides systemd units [1].

Do you think, it’d be easily possible, that the OpenVPN sets up the connection
in a separate network name space, and the user can enter that name space and
start SSH and a browser from there?

If yes, do you have any hints before I start to dig into that?


Kind regards,

Paul


[1]: https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/
[Unit]
Description=OpenVPN tunnel for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/client
ExecStart=/usr/local/sbin/openvpn --suppress-timestamps --nobind --config 
%i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process

[Install]
WantedBy=multi-user.target
[Unit]
Description=OpenVPN service for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/server
ExecStart=/usr/local/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE 
CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process
RestartSec=5s
Restart=on-failure

[Install]
WantedBy=multi-user.target


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mailing List List-Id Header

[Paul Menzel]

Dear Esben,


On 10/30/18 16:17, Esben Stien wrote:
> Is there supposed to be a List-Id in the headers of email that comes from
> this mailing list?
> 
> I don't see any. Any other headers you use?

I see all the headers. For example, from your message (Ctrl + u in Thunderbird):

```
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: systemd Development Mailing List 
List-Unsubscribe: 
, 
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
 
```


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to debug stop job running into time-out?

[Paul Menzel]

Dear systemd folks,


With Debian Sid/unstable (systemd 239) and GDM 3.30.1, sometimes
powering off the system, it takes two minutes and the message
below is shown on the screen.

> A stop job is running for User Manager for UID 1000 (1min 3s / 1 min 59s)

What ways are there to debug this issue. The problem is, it’s
not always reproducible.

Is there a key combination for dumping the necessary information?
Like what process(?) cannot be stopped?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to profile units with perf? (was: logind: How to process enumerate buttons in parallel?)

[Paul Menzel]

Dear systemd folks,


On 07/16/18 11:26, Lennart Poettering wrote:
> On Mo, 16.07.18 10:25, Paul Menzel wrote:

[…]

>> Do you have suggestions how to do that with systemd-logind?
> 
> People tend to use "perf" for things like this these days.

Thank you, that’s what I wanted to use, but I am not really sure how
to do it with systemd units?

I failed by adapting the systemd-logind Exec line, as the permissions
for the perf counters(?) are not there.

Then I tried to add a perf service unit doing

/usr/sbin/perf_4.17 record -o /dev/shm/perf.data sleep 10

and order it before sysinit.target but that did not contain anything
useful.


Kind regads,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logind: How to process enumerate buttons in parallel?

[Paul Menzel]

Dear Lennart,


Thank you for your response.


On 07/13/18 17:12, Lennart Poettering wrote:
> On Do, 12.07.18 16:51, Paul Menzel wrote:

>> Trying to decrease the start-up time, I noticed that `systemd-logind`
>> probes devices in serial(?) (instead of parallel).
>>
>> From `manager_enumerate_buttons(Manager *m)` in `src/login/logind.c`:
>>
>> ```
>> udev_list_entry_foreach(item, first) {
>> _cleanup_(udev_device_unrefp) struct udev_device *d = NULL;
>> int k;
>>
>> d = udev_device_new_from_syspath(m->udev, 
>> udev_list_entry_get_name(item));
>> if (!d)
>> return -ENOMEM;
>>
>> k = manager_process_button_device(m, d);
>> if (k < 0)
>> r = k;
>> }
>> ```
>>
>> The macro is defined as below:
>>
>> ```
>> /**
>>  * udev_list_entry_foreach:
>>  * @list_entry: entry to store the current position
>>  * @first_entry: first entry to start with
>>  *
>>  * Helper to iterate over all entries of a list.
>>  */
>> #define udev_list_entry_foreach(list_entry, first_entry) \
>> for (list_entry = first_entry; \
>>  list_entry != NULL; \
>>  list_entry = udev_list_entry_get_next(list_entry))
>> ```
>>
>> Is there a way to do that in parallel?
> 
> systemd components are generally single threaded. Probing input
> devices from systemd is unlikely to be a performance problem. I mean,
> we don't process 10K devices here, but usually not more than 25 or
> so... Also the code isn't really CPU or IO bound here, it just does a
> few open() and ioctl() calls mostly.

By the way, below are the timings from the journal.

```
$ journalctl -o short-precise -u systemd-logind.service -b
-- Logs begin at Sat 2017-12-16 23:28:06 CET, end at Mon 2018-07-16 08:23:11 
CEST. --
Jul 16 08:22:54.006190 kodi systemd[1]: Starting Login Service...
Jul 16 08:22:54.103445 kodi systemd-logind[169]: New seat seat0.
Jul 16 08:22:54.163713 kodi systemd[1]: Started Login Service.
Jul 16 08:22:54.312955 kodi systemd-logind[169]: Watching system buttons on 
/dev/input/event1 (Power Button)
Jul 16 08:22:54.514965 kodi systemd-logind[169]: Watching system buttons on 
/dev/input/event0 (Power Button)
Jul 16 08:22:54.781082 kodi systemd-logind[169]: Watching system buttons on 
/dev/input/event2 (AT Translated Set 2 keyboard)
```

> Before spending time on optimizing anything like this: did you did
> profiling on this, that shows clearly that this is performance
> relevant at all?

Do you have suggestions how to do that with systemd-logind?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to reduce time to between Linux’ `run_init_process()` and systemd banner?

[Paul Menzel]

Dear systemd folks,


I forgot to attach the logs.


Am 13.07.2018 um 20:20 schrieb Paul Menzel:


Trying to decrease the boot time, I got rid of the initrd. Now, there
is a noticeable delay between Linux `run_init_process()` and the first
systemd message.

I added an output line to the Linux function.

```
static int run_init_process(const char *init_filename)
{
     argv_init[0] = init_filename;

     pr_info("Run %s as init process\n", init_filename);
     return do_execve(getname_kernel(init_filename),
     (const char __user *const __user *)argv_init,
     (const char __user *const __user *)envp_init);
}
```

Here you see the result on a system (ASRock E350M1) with an SDD
(spinning).

```
[    0.287632] Run /sbin/init as init process
[    0.547261] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

```

The systemd binary is only 2.3 MB in size, so I do not think that
this is the loading time.

     $ ls -lh /lib/systemd/systemd
     -rwxr-xr-x 2 root root 2.3M Mar 12 13:44 /lib/systemd/systemd

Is there a way, to get a message from systemd as early as possible
to see where the time is spent?

`log_execution_mode(_boot)` is not at the beginning in
`main()` in `src/core/main.c`. I guess the “console” needs to be
set up first?

Any help is appreciated.



Kind regards,

Paul
[0.00] Linux version 4.18.0-rc4-00097-g33ec366fda95 (root@f2fc51708d66) 
(gcc version 7.3.0 (Debian 7.3.0-24)) #96 SMP Fri Jul 13 15:26:28 UTC 2018
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] type 16
[0.00] BIOS-e820: [mem 0x1000-0x0009] usable
[0.00] BIOS-e820: [mem 0x000c-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xc7d3bfff] usable
[0.00] BIOS-e820: [mem 0xc7d3c000-0xc7ff] type 16
[0.00] BIOS-e820: [mem 0xc800-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00011eff] usable
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0xc7d3c max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-back
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0C000 mask FF800 write-back
[0.00]   2 base 08000 mask FC000 write-back
[0.00]   3 base 0 mask F8000 write-back
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00011f00 aka 4592M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] Scanning 1 areas for low memory corruption
[0.00] initial memory mapped: [mem 0x-0x0fff]
[0.00] Base memory trampoline at [(ptrval)] 9b000 size 16384
[0.00] BRK [0x0fc61000, 0x0fc61fff] PGTABLE
[0.00] log_buf_len: 33554432 bytes
[0.00] early log buf free: 259860(99%)
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0800 24 (v02 CORE  )
[0.00] ACPI: XSDT 0xC7D4D0E0 6C (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: FACP 0xC7D4F850 F4 (v04 CORE   COREBOOT 
 CORE )
[0.00] ACPI: DSDT 0xC7D4D280 0025C7 (v02 ASROCK COREBOOT 
00010001 INTL 20180629)
[0.00] ACPI: FACS 0xC7D4D240 40
[0.00] ACPI: FACS 0xC7D4D240 40
[0.00] ACPI: SSDT 0xC7D4F950 8A (v02 CORE   COREBOOT 
002A CORE 002A)
[0.00] ACPI: TCPA 0xC7D4F9E0 32 (v02 CORE   COREBOOT 
 CORE )
[0.00] ACPI: APIC 0xC7D4FA20 5C (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: HEST 0xC7D4FA80 28 (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: SSDT 0xC7D4FAB0 00168E (v02 AMDALIB 
0001 MSFT 0400)
[0.00] ACPI: SSDT 0xC7D51140 0003DE (v01 AMDPOWERNOW 
0001 AMD  0001)
[0.0

[systemd-devel] How to reduce time to between Linux’ `run_init_process()` and systemd banner?

[Paul Menzel]

Dear systemd folks,


Trying to decrease the boot time, I got rid of the initrd. Now, there
is a noticeable delay between Linux `run_init_process()` and the first
systemd message.

I added an output line to the Linux function.

```
static int run_init_process(const char *init_filename)
{
argv_init[0] = init_filename;

pr_info("Run %s as init process\n", init_filename);
return do_execve(getname_kernel(init_filename),
(const char __user *const __user *)argv_init,
(const char __user *const __user *)envp_init);
}
```

Here you see the result on a system (ASRock E350M1) with an SDD
(spinning).

```
[0.287632] Run /sbin/init as init process
[0.547261] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

```

The systemd binary is only 2.3 MB in size, so I do not think that
this is the loading time.

$ ls -lh /lib/systemd/systemd
-rwxr-xr-x 2 root root 2.3M Mar 12 13:44 /lib/systemd/systemd

Is there a way, to get a message from systemd as early as possible
to see where the time is spent?

`log_execution_mode(_boot)` is not at the beginning in
`main()` in `src/core/main.c`. I guess the “console” needs to be
set up first?

Any help is appreciated.


Kind regards,

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

[systemd-devel] logind: How to process enumerate buttons in parallel?

[Paul Menzel]

Dear systemd folks,


Trying to decrease the start-up time, I noticed that `systemd-logind`
probes devices in serial(?) (instead of parallel).

From `manager_enumerate_buttons(Manager *m)` in `src/login/logind.c`:

```
udev_list_entry_foreach(item, first) {
_cleanup_(udev_device_unrefp) struct udev_device *d = NULL;
int k;

d = udev_device_new_from_syspath(m->udev, 
udev_list_entry_get_name(item));
if (!d)
return -ENOMEM;

k = manager_process_button_device(m, d);
if (k < 0)
r = k;
}
```

The macro is defined as below:

```
/**
 * udev_list_entry_foreach:
 * @list_entry: entry to store the current position
 * @first_entry: first entry to start with
 *
 * Helper to iterate over all entries of a list.
 */
#define udev_list_entry_foreach(list_entry, first_entry) \
for (list_entry = first_entry; \
 list_entry != NULL; \
 list_entry = udev_list_entry_get_next(list_entry))
```

Is there a way to do that in parallel?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to set `InitRDTimestampMonotonic` from console?

[Paul Menzel]

Dear Dimitri,


Am 04.07.2018 um 12:24 schrieb Dimitri John Ledkov:


On 4 July 2018 at 10:22, Lennart Poettering  wrote:

On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:


Dear systemd folks,


Debian uses a shell script as `/init` in initrd, and I like to extend that,
to set the time stamps for the initrd execution.


This is part of the data that is serialized during the transition from
the systemd instance in the initrd to the systemd instance on the
host. The serialization is internal to systemd, and this is unlikely
to change, as it contains numerous bits of information that are
fragile and sensitive as the serialization really contains the full
service manager state with all its units and so on.


Is it possible to set that value from a shell script? If yes, could you
please tell me how?


It's not, and quite frankly I am not enthusiastic about the idea to
make this configurable...


At one point, I was considering to serialize just enough data to add
these in the initramfs-tools (and/or systemd) as Debian specific
patches to start supporting these measurements.
And have a distro patch in systemd to read these measurements from a
separately serialized file on boot-up.


Yeah, that wolud be good to have. Do you know, if there are feature 
requests for these already?



Also, there are bootloader measurements, that I think we do not
receive either from grub.


With Ubuntu 18.04 on a TUXEDO Book BU1406 with Ubuntu 18.04, UEFI 
firmware and GRUB, I get the output below.



Startup finished in 5.793s (firmware) + 3.339s (loader) + 7.002s (kernel) + 
8.107s (userspace) = 24.242s



Kind regards,

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

[systemd-devel] How to set `InitRDTimestampMonotonic` from console?

[Paul Menzel]

Dear systemd folks,


Debian uses a shell script as `/init` in initrd, and I like to extend 
that, to set the time stamps for the initrd execution.


`systemd-analyze` built from `src/analyze/analyze.c` uses D-Bus to get 
the time stamp to display that.


```
   bus_get_uint64_property(bus,
"/org/freedesktop/systemd1",
"org.freedesktop.systemd1.Manager",
"InitRDTimestampMonotonic",
_time) < 0
```

In `src/core/manager.c` the value is set like below.

```
if 
(dual_timestamp_is_set(>timestamps[MANAGER_TIMESTAMP_INITRD])) {


/* The initrd case on bare-metal*/
kernel_usec = 
m->timestamps[MANAGER_TIMESTAMP_INITRD].monotonic - 
m->timestamps[MANAGER_TIMESTAMP_KERNEL].monotonic;
initrd_usec = 
m->timestamps[MANAGER_TIMESTAMP_USERSPACE].monotonic - 
m->timestamps[MANAGER_TIMESTAMP_INITRD].monotonic;


log_struct(LOG_INFO,
   "MESSAGE_ID=" 
SD_MESSAGE_STARTUP_FINISHED_STR,

   "KERNEL_USEC="USEC_FMT, kernel_usec,
   "INITRD_USEC="USEC_FMT, initrd_usec,
   "USERSPACE_USEC="USEC_FMT, 
userspace_usec,
   LOG_MESSAGE("Startup finished in 
%s%s (kernel) + %s (initrd) + %s (userspace) = %s.",

   buf,
   format_timespan(kernel, 
sizeof(kernel), kernel_usec, USEC_PER_MSEC),
   format_timespan(initrd, 
sizeof(initrd), initrd_usec, USEC_PER_MSEC),


format_timespan(userspace, sizeof(userspace), userspace_usec, 
USEC_PER_MSEC),
   format_timespan(sum, 
sizeof(sum), total_usec, USEC_PER_MSEC)));

```




Is it possible to set that value from a shell script? If yes, could you 
please tell me how?



Kind regards,

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

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Paul Menzel]

Dear Dimitri,


On 04/16/18 18:51, Dimitri John Ledkov wrote:

On 16 April 2018 at 14:25, Paul Menzel wrote:



On 04/16/18 12:47, Dimitri John Ledkov wrote:


On 13 April 2018 at 16:40, Paul Menzel wrote:



In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
ordering of systemd-resolved.service was changed. (How do I find the
merge
request to find possible discussion? Also the commit message description
is
too specific in my opinion, as it doesn’t give a clue that more is
changed.)



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


Thank you, no idea, why I didn’t find it with `git log --oneline --graph`.
Hmm, looks like, Lennart directly put that commit in master without merging
the pull request.


I like starting systemd-resolved earlier, but unfortunately ordering it
before `network.target` adds a delay on systems wanting to start as fast
as
possible. But why did you change it from `network-online.target` to
`network.target`? I’d say `network-online.target` is more correct.

For my use case of a fast system start-up, this change delays it by at
least
100 ms, as now it takes longer to reach the end of the network target.



cloud-init initializes networking configuration by fetching,
potentially, remote sources to customize an instance on first boot.
Specifically it may dhcp any interface, to reach a metadata source,
download the real networking configuration, reconfigure networking to
match the final networking details (all interfaces / public ip
addresses / etc), and proceed to complete networking.target and
network-online.target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.



Just to be sure, you mean *network.target*, right?

Thank you for specifying the requirement. I agree, that it should be started
as early as possible, but I disagree with the rest.


There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.



Sorry for being ignorant, but could you please be specific, what these
things are. If these units have that requirement order them after
`network-online.target`.


If your systems have problems with it, they have wrong dependencies,
don’t
they? Also, they should probably be able to deal with the situation, that
DNS does not work, as that can happen during operation.

So, I’d really like to rework that ordering change.



Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

Alternatively, as a system integrator, you may want to change these
dependencies in your distro, especially if you do not configure
resolved _stub resolver_ as the default provider of /etc/resolv.conf
or for example to do not use the recommended default stub-provider
over 127.0.0.53 and instead use the nss module over dbus.

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

Specifically, the dependencies as is are "too-early" if one uses the
last two modes of the /etc/resolv.conf handling as described in the
man page -
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf


First, I think, the terminology of *early* leads to misunderstandings. For
you it includes ordering with `Before=`, for me it’s just about `After=`
statements.


It's actually both. Cloud-init is a cross-distribution tool, and it
injects itself at multiple points during boot. It pre-empts networking
target, is between networking & network-online, and after
network-online target.

Without this upstream change, cloud-init was not able to pre-empt
network.target, was resulting in a dependency cycle, and systems
resulted booting degraded (due to dependency cycle resolved by
shooting arbitrary unit in the head), in a default upstream systemd
configuration.


Anyway, regressing the user experience for everyone only because it’s


Can you please explain what has degraded? starting systemd-resolved
before or after network*.target shouldn't make any difference in wall
clock time to reach multi-user.target. And in my boot testing, I did
not see any boot regressions.


Just look, what is ordered after the network target.

1. units/rc-local.service.in:After=network.target
2. units/systemd-user-sessions.service.in:After=remote-fs.target 
nss-user-lookup.target network.target


Both are needed for the login screen.


Or are you explicitly measuring time to network.target, separate from
time to network-online.target, and separate from reaching the default
target?

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Paul Menzel]

Dear Dimitri,


Thank you for your quick response.


On 04/16/18 12:47, Dimitri John Ledkov wrote:

On 13 April 2018 at 16:40, Paul Menzel wrote:



In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
ordering of systemd-resolved.service was changed. (How do I find the merge
request to find possible discussion? Also the commit message description is
too specific in my opinion, as it doesn’t give a clue that more is changed.)


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


Thank you, no idea, why I didn’t find it with `git log --oneline 
--graph`. Hmm, looks like, Lennart directly put that commit in master 
without merging the pull request.



I like starting systemd-resolved earlier, but unfortunately ordering it
before `network.target` adds a delay on systems wanting to start as fast as
possible. But why did you change it from `network-online.target` to
`network.target`? I’d say `network-online.target` is more correct.

For my use case of a fast system start-up, this change delays it by at least
100 ms, as now it takes longer to reach the end of the network target.


cloud-init initializes networking configuration by fetching,
potentially, remote sources to customize an instance on first boot.
Specifically it may dhcp any interface, to reach a metadata source,
download the real networking configuration, reconfigure networking to
match the final networking details (all interfaces / public ip
addresses / etc), and proceed to complete networking.target and
network-online.target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.


Just to be sure, you mean *network.target*, right?

Thank you for specifying the requirement. I agree, that it should be 
started as early as possible, but I disagree with the rest.



There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.


Sorry for being ignorant, but could you please be specific, what these 
things are. If these units have that requirement order them after 
`network-online.target`.



If your systems have problems with it, they have wrong dependencies, don’t
they? Also, they should probably be able to deal with the situation, that
DNS does not work, as that can happen during operation.

So, I’d really like to rework that ordering change.


Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

Alternatively, as a system integrator, you may want to change these
dependencies in your distro, especially if you do not configure
resolved _stub resolver_ as the default provider of /etc/resolv.conf
or for example to do not use the recommended default stub-provider
over 127.0.0.53 and instead use the nss module over dbus.

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

Specifically, the dependencies as is are "too-early" if one uses the
last two modes of the /etc/resolv.conf handling as described in the
man page - 
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf


First, I think, the terminology of *early* leads to misunderstandings. 
For you it includes ordering with `Before=`, for me it’s just about 
`After=` statements.


Anyway, regressing the user experience for everyone only because it’s 
required for cloud-init is not right in my opinion. As you pointed out, 
the system integrator can adapt certain things, and in my opinion, I 
throw the ball back to you, and kindly ask you, to adapt systemd locally 
so it works with your use-case or let’s come up with a better solution.


Maybe a new target is needed, where you can order your services after, 
as ordering them after systemd-resolved.service is too specific.


I submitted a merge/pull request to change the ordering [1].


Kind regards,

Paul


[1] https://github.com/systemd/systemd/pull/8731



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Changed ordering of systemd-resolved.service

[Paul Menzel]

Dear Dimitri, dear systemd folks,


In commit 1f158013 (resolved.service: set DefaultDependencies=no) the 
ordering of systemd-resolved.service was changed. (How do I find the 
merge request to find possible discussion? Also the commit message 
description is too specific in my opinion, as it doesn’t give a clue 
that more is changed.)



commit 1f1580139ed48dd308a6a2470baf037ae1ed6aab
Author: Dimitri John Ledkov 
AuthorDate: Mon Dec 11 18:27:49 2017 +
Commit: Lennart Poettering 
CommitDate: Thu Jan 11 12:40:44 2018 +0100

resolved.service: set DefaultDependencies=no

On systems that only use resolved for name resolution, there are usecases that

require resolved to be started before sysinit target, such that network name
resolution is available before network-online/sysinit targets. For example,
cloud-init for some datasources hooks into the boot process ahead of sysinit
target and may need network name resolution at that point already.

systemd-resolved already starts pretty early in the process, thus starting it

slightly earlier should not have negative side effects.

However, this depends on resolved ability to connect to system DBus once that

is up.

diff --git a/units/systemd-resolved.service.in 
b/units/systemd-resolved.service.in
index 8059aa7b6..c4c7f1fee 100644
--- a/units/systemd-resolved.service.in
+++ b/units/systemd-resolved.service.in
@@ -13,8 +13,10 @@ Documentation=man:systemd-resolved.service(8)
 Documentation=https://www.freedesktop.org/wiki/Software/systemd/resolved
 
Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
 
Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
-After=systemd-networkd.service network.target
-Before=network-online.target nss-lookup.target
+DefaultDependencies=no
+After=systemd-sysusers.service systemd-networkd.service
+Before=network.target nss-lookup.target shutdown.target
+Conflicts=shutdown.target
 Wants=nss-lookup.target
 
 [Service]


I like starting systemd-resolved earlier, but unfortunately ordering it 
before `network.target` adds a delay on systems wanting to start as fast 
as possible. But why did you change it from `network-online.target` to 
`network.target`? I’d say `network-online.target` is more correct.


For my use case of a fast system start-up, this change delays it by at 
least 100 ms, as now it takes longer to reach the end of the network target.



   network.target
   This unit is supposed to indicate when network functionality is
   available, but it is only very weakly defined what that is supposed
   to mean, with one exception: at shutdown, a unit that is ordered
   after network.target will be stopped before the network — to
   whatever level it might be set up then — is shut down. It is hence
   useful when writing service files that require network access on
   shutdown, which should order themselves after this target, but not
   pull it in. Also see Running Services After the Network is up[1]
   for more information. Also see network-online.target described
   above.

   systemd automatically adds dependencies of type After= for this
   target unit to all SysV init script service units with an LSB
   header referring to the "$network" facility.



   network-online.target
   Units that strictly require a configured network connection should
   pull in network-online.target (via a Wants= type dependency) and
   order themselves after it. This target unit is intended to pull in
   a service that delays further execution until the network is
   sufficiently set up. What precisely this requires is left to the
   implementation of the network managing service.

   Note the distinction between this unit and network.target. This
   unit is an active unit (i.e. pulled in by the consumer rather than
   the provider of this functionality) and pulls in a service which
   possibly adds substantial delays to further execution. In contrast,
   network.target is a passive unit (i.e. pulled in by the provider of
   the functionality, rather than the consumer) that usually does not
   delay execution much. Usually, network.target is part of the boot
   of most systems, while network-online.target is not, except when at
   least one unit requires it. Also see Running Services After the
   Network is up[1] for more information.

   All mount units for remote network file systems automatically pull
   in this unit, and order themselves after it. Note that networking
   daemons that simply provide functionality to other hosts generally
   do not need to pull this in.

   Note that 

Re: [systemd-devel] [PATCH] Fix strerror_r segfault on non-glibc systems

[Paul Menzel]

Dear Ioan-Adrian,


Thank you for your patch (from the future `Date: Thu, 29 Mar 2018
14:41:30 +0300`).

I believe systemd moved the development to GitHub [1] and only accepts 
merge/pull requests [1].



Please see our Contribution Guidelines for more information about
filing GitHub Issues and posting GitHub Pull Requests.



Kind regards,

Paul


[1] https://github.com/systemd/systemd/



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to debug why a unit is started when?

[Paul Menzel]

Dear Colin,


On 03/19/2018 07:31 AM, Colin Guthrie wrote:

Paul Menzel wrote on 17/03/18 17:50:



On 03/16/2018 05:04 PM, Andrei Borzenkov wrote:

16.03.2018 18:49, Paul Menzel пишет:



I am trying to get the GDM login screen started earlier on a Dell XPS 13
9370 with Debian Sid/unstable system with systemd 238. Currently, after
selecting the Linux kernel in GRUB it’s only displayed after roughly
eight to ten seconds while Linux takes around two seconds [1].

Using systemd-bootchart I see that GDM is started quite late [1], and I
wondering if there is an option to find out why.

GDM’s service unit [2] has the “dependencies” below.

  After=rc-local.service plymouth-start.service
systemd-user-sessions.service

Is there a debug option, where systemd says, why a certain unit is
started? For example, reached target X and therefore starting Y.


systemctl --after (--recursive) --list-dependencies gdm.service

may be the first step. Or use systemd-analyze chart to see full picture
of what was started when.


I didn’t know about `systemd-analyze plot`. Please find the SVG file
attached.

Looking at the log messages, I kind of think it’s related to the
NetworkManager, but I do not see the dependency. Is it
`rc-local.service`? It seems to depend on the `network.target`.


I didn't look too hard at the data, but from experience,
systemd-user-sessions often has to start after the network is online as
user accounts may be defined in e.g. LDAP etc.

This is the likely chain you need to break and configure accordingly.

e.g. if you have no network filesystems (defined without noauto or
nofail) and no LDAP/NIS users etc., then you may not need
networkmanager-wait-online.service and if you disable this, things might
go a lot faster.

Be careful however, as some old network-listening services may still
need this dodgy delay service to function properly.
Thank you for pointing this out. I actually knew this from the past, but 
forgot about it. I didn’t look further into it though, as I had removed 
the `After=` line (including `systemd-user-sessions.service`). I changed 
more things too though by deinstalling the package *ifupdown*.


```
$ systemctl cat gdm
# /lib/systemd/system/gdm.service
[Unit]
Description=GNOME Display Manager

# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service

# replaces plymouth-quit since it quits plymouth on its own

# Needs all the dependencies of the services it's replacing
# pulled from getty@.service and plymouth-quit.service
# (except for plymouth-quit-wait.service since it waits until
# plymouth is quit, which we do)

# GDM takes responsibility for stopping plymouth, so if it fails
# for any reason, make sure plymouth still stops
OnFailure=plymouth-quit.service

[Service]
ExecStartPre=/usr/share/gdm/generate-config
ExecStart=/usr/sbin/gdm3
KillMode=mixed
Restart=always
RestartSec=1s
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
StandardOutput=syslog
StandardError=inherit
EnvironmentFile=-/etc/default/locale
ExecReload=/usr/share/gdm/generate-config
ExecReload=/bin/kill -SIGHUP $MAINPID
```

But `sudo systemctl disable NetworkManager-wait-online.service` indeed 
changed something, and the GDM service is now started at the same time 
as NetworkManager.


Unfortunately, the GDM session worker is only started after 1.6 seconds 
according to the chart – the updated chart is attached. That is a likely 
a GDM problem though.



```
[…]
Mar 19 10:14:30.440112 xps139370 systemd[1]: Starting GNOME Display Manager...
[…]
Mar 19 10:14:30.475575 xps139370 systemd[1]: Started GNOME Display Manager.
Mar 19 10:14:30.475764 xps139370 gdm3[523]: Successfully connected to D-Bus
[…]
Mar 19 10:14:32.022907 xps139370 gdm3[523]: GdmLocalDisplayFactory: Adding 
display on seat seat0
Mar 19 10:14:32.023006 xps139370 gdm3[523]: GdmDisplay: id: (null)
Mar 19 10:14:32.023011 xps139370 gdm3[523]: GdmDisplay: seat id: (null)
Mar 19 10:14:32.023014 xps139370 gdm3[523]: GdmDisplay: session class: greeter
Mar 19 10:14:32.023017 xps139370 gdm3[523]: GdmDisplay: initial: no
Mar 19 10:14:32.023019 xps139370 gdm3[523]: GdmDisplay: allow timed login: yes
Mar 19 10:14:32.023022 xps139370 gdm3[523]: GdmDisplay: local: yes
Mar 19 10:14:32.023109 xps139370 gdm3[523]: GdmDisplay: session type: wayland
Mar 19 10:14:32.023113 xps139370 gdm3[523]: GdmDisplay: seat id: seat0
Mar 19 10:14:32.023117 xps139370 gdm3[523]: GdmDisplay: initial: yes
Mar 19 10:14:32.023121 xps139370 gdm3[523]: GdmDisplayStore: Adding display 
/org/gnome/DisplayManager/Displays/94611499688528 to store
Mar 19 10:14:32.023234 xps139370 gdm3[523]: GdmDisplay: Managing display: 
/org/gnome/DisplayManager/Displays/94611499688528
Mar 19 10:14:32.023236 xps139370 gdm3[523]: GdmDisplay: Preparing display: 
/org/gnome/DisplayManager/Displays/94611499688528
Mar 19 10:14:32.024422 xps139370 kernel: ath10k_pci :02:00.0: Unknown 
eventid: 118809
Mar 19 10:14:32.025099 xps139370 gdm3[523]: GdmDisplay: Checking kernel command 
buffer

Re: [systemd-devel] How to debug why a unit is started when?

[Paul Menzel]

Dear Tomasz,


On 03/16/2018 04:56 PM, Tomasz Torcz ️ wrote:

On Fri, Mar 16, 2018 at 04:49:28PM +0100, Paul Menzel wrote:



I am trying to get the GDM login screen started earlier on a Dell XPS 13
9370 with Debian Sid/unstable system with systemd 238. Currently, after
selecting the Linux kernel in GRUB it’s only displayed after roughly eight
to ten seconds while Linux takes around two seconds [1].

Using systemd-bootchart I see that GDM is started quite late [1], and I
wondering if there is an option to find out why.


   Not a direct answer to your question, but you can use systemd-bootchart
to get graphical timeline of how long did it take to start different
units.  Then you will have to find box for GDM and see which other
boxes ended at the moment GDM started.


Thank you for your reply, but as written, I tried that, and uploaded the 
chart to the GDM bug report. Unfortunately, I didn’t see any connection, 
that means, no box ended.



Kind regards,

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

[systemd-devel] How to debug why a unit is started when?

[Paul Menzel]

Dear systemd folks,


I am trying to get the GDM login screen started earlier on a Dell XPS 13 
9370 with Debian Sid/unstable system with systemd 238. Currently, after 
selecting the Linux kernel in GRUB it’s only displayed after roughly 
eight to ten seconds while Linux takes around two seconds [1].


Using systemd-bootchart I see that GDM is started quite late [1], and I 
wondering if there is an option to find out why.


GDM’s service unit [2] has the “dependencies” below.

After=rc-local.service plymouth-start.service 
systemd-user-sessions.service


Is there a debug option, where systemd says, why a certain unit is 
started? For example, reached target X and therefore starting Y.



Kind regards,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=794336
[2] https://git.gnome.org/browse/gdm/tree/data/gdm.service.in



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Paul Menzel]

Dear Lennart and others,


Thank you for your prompt replies.


Am 20.02.2018 um 23:12 schrieb Lennart Poettering:

On Di, 20.02.18 20:00, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:



We finally are going to upgrade from a very old systemd version 27 from 2011
to the current systemd v237. (Historical reasons.)

Anyway, I already was told about `systemctl daemon-reexec`, and we got it
working.


While we try to ensure that live upgrades of PID 1 like that work
quite well, this is generally tested only for small steps. Jumping 6
years ahead in one go is not something people typically test.


Indeed, but it seems to work. During the upgrade you have to make sure, 
that both versions are installed in parallel when doing `systemctl 
daemon-reexec`, so the old systemd still finds it dependencies/libraries 
and can terminate properly. Then the old version can be removed.



After that, looking at the output of `systemctl`, there are many units from
the old version, which were removed in the meantime.

```
$ systemctl --state=not-found
   UNIT LOAD  ACTIVE   SUB DESCRIPTION
● dev-hugepages.automount  not-found active   waiting
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting
sys-kernel-debug.automount
● sys-kernel-security.automountnot-found active   waiting
sys-kernel-security.automount
● auditd.service   not-found inactive dead
auditd.service
● console-kit-log-system-start.service not-found active   exited
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead
display-manager.service
● hwclock-load.service not-found active   exited
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead
plymouth-start.service
● remount-rootfs.service   not-found active   exited
remount-rootfs.service
● syslog.service   not-found inactive dead
syslog.service
● systemd-kmsg-syslogd.service not-found active   running
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead
systemd-sysusers.service
● udev-retry.service   not-found active   exited
udev-retry.service
● udev-settle.service  not-found active   exited
udev-settle.service
● systemd-logger.socketnot-found active   listening
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening
systemd-shutdownd.socket
● cryptsetup.targetnot-found active   active
cryptsetup.target
● syslog.targetnot-found active   active
syslog.target


My recommendation: simply reboot. That should clean up everything
properly.

Note that PID 1 itself is probably pretty Ok with such a massive
update in one step, but the unit files have been rearranged quite a
bit since then. Downstream distributions generally expect you to
reboot even between single-step distro updates, but this becomes much
more of a necessity if you jump even further.


But if reboot wouldn’t be an option, is there a way to get rid of 
not-found services?



Note that systemd upstream currently requires kernel 3.13 at least
which was released in 2014. Hence, if you update from a 2011 system
you have to reboot anyway, already to update the kernel...


We already run later Linux Kernels, so that is not a problem. But thank 
you for mentioning it.



Do I need to stop those manually beforehand, or is there another way to
clean up?

Is the recommended update procedure documented somewhere?


Usually distributions document that invididually as systemd is just
one component of many that make up the distribution.


Understood.


Kind regards,

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

[systemd-devel] Hints for upgrading systemd on a running system

[Paul Menzel]

Dear systemd folks,


We finally are going to upgrade from a very old systemd version 27 from 
2011 to the current systemd v237. (Historical reasons.)


Anyway, I already was told about `systemctl daemon-reexec`, and we got 
it working.


After that, looking at the output of `systemctl`, there are many units 
from the old version, which were removed in the meantime.


```
$ systemctl --state=not-found
  UNIT LOAD  ACTIVE   SUB 
DESCRIPTION
● dev-hugepages.automount  not-found active   waiting 
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting 
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting 
sys-kernel-debug.automount
● sys-kernel-security.automountnot-found active   waiting 
sys-kernel-security.automount
● auditd.service   not-found inactive dead 
auditd.service
● console-kit-log-system-start.service not-found active   exited 
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead 
display-manager.service
● hwclock-load.service not-found active   exited 
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead 
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead 
plymouth-start.service
● remount-rootfs.service   not-found active   exited 
remount-rootfs.service
● syslog.service   not-found inactive dead 
syslog.service
● systemd-kmsg-syslogd.service not-found active   running 
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited 
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead 
systemd-sysusers.service
● udev-retry.service   not-found active   exited 
udev-retry.service
● udev-settle.service  not-found active   exited 
udev-settle.service
● systemd-logger.socketnot-found active   listening 
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening 
systemd-shutdownd.socket
● cryptsetup.targetnot-found active   active 
cryptsetup.target
● syslog.targetnot-found active   active 
syslog.target


LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.

21 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
```

Do I need to stop those manually beforehand, or is there another way to 
clean up?


Is the recommended update procedure documented somewhere?


Kind regards,

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

Re: [systemd-devel] Best practices for full disk encryption with dm-crypt/LUKS

[Paul Menzel]

Dear Andrei,


Thank you for your reply.


Am 20.02.2018 um 05:41 schrieb Andrei Borzenkov:

20.02.2018 01:16, Paul Menzel пишет:



Having a system with UEFI, what is the state of the art to use full disk
encryption? I read the article in the Arch Linux wiki [1], and it still
using GRUB. There is an blog post from 2016 using systemd-boot [2].


If your kernel or initrd are located on encrypted filesystem you need
bootloader that can read them.


And can systemd-boot read it?


If there was a way without LVM, I’d prefer that.


It has always been possible, the question is to which extent individual
distributions made it easy to setup. openSUSE Tumbleweed/Leap 15
installer finally offers native encryption of plain partition without LVM.


That’s great news. To my knowledge, the Debian Installer (Debian 9 
(stretch)) isn’t able to do it.



Are there new programs or features in the systemd ecosystem making the
setup easy?


I'd say it is more initramfs implementation question - initramfs is
responsible for actually mounting your root.


What are the options? Initramfs and Dracut, right?


Kind regards,

Paul



[1] https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
[2] 
https://blog.urbanslug.com/posts/2016-09-11-dm-crypt-systemd-boot-and-efi-on-archlinux.html

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

[systemd-devel] Best practices for full disk encryption with dm-crypt/LUKS

[Paul Menzel]

Dear systemd folks,


Having a system with UEFI, what is the state of the art to use full disk 
encryption? I read the article in the Arch Linux wiki [1], and it still 
using GRUB. There is an blog post from 2016 using systemd-boot [2].


If there was a way without LVM, I’d prefer that.

Are there new programs or features in the systemd ecosystem making the 
setup easy?



Kind regards,

Paul


[1] 
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
[2] 
https://blog.urbanslug.com/posts/2016-09-11-dm-crypt-systemd-boot-and-efi-on-archlinux.html

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

[systemd-devel] [RFH] How to analyze long load time of `systemd-timesyncd`?

[Paul Menzel]

Dear systemd folks,


I am trying to figure out why `systemd-timesyncd` takes quite some
time, that means over 100 ms, to start up on several systems [1]. This
is also reproducible with systemd 232 from Debian Sid/unstable.

After adding `log_info()` statements to the source code, as told in
#syst...@irc.freenode.net, it looks like the time is spend before the
`main()` is called. Is the flow documented somewhere? Who prints
`Starting Network Time Synchronization...`, and then what happens?

It’d be awesome if you could help me, how to further debug this issue.

```
$ journalctl -u systemd-timesyncd -o short-monotonic -b
-- Logs begin at Tue 2016-09-13 14:51:22 CEST, end at Tue 2017-04-18 16:14:36 
CEST. --
[7.694166] mysystem systemd[1]: Starting Network Time Synchronization...
[8.942021] mysystem systemd-timesyncd[311]: After log_set_target
[8.942021] mysystem systemd-timesyncd[311]: After log_set_facility
[8.942805] mysystem systemd-timesyncd[311]: After log_parse_environment
[8.943063] mysystem systemd-timesyncd[311]: After log_open
[8.943271] mysystem systemd-timesyncd[311]: After get_user_creds
[8.943465] mysystem systemd-timesyncd[311]: load_clock_timestamp: before 
open /systemd/clock
[9.103315] mysystem systemd-timesyncd[311]: load_clock_timestamp: after 
open /systemd/clock
[9.103493] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after fstat
[9.103642] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
before timespec_load
[9.103790] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after timespec_load
[9.103933] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
before fchmod
[9.104097] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after fchmod
[9.104238] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after fchown
[9.104377] mysystem systemd-timesyncd[311]: load_clock_timestamp: before 
now(CLOCK_REALTIME)
[9.104522] mysystem systemd-timesyncd[311]: load_clock_timestamp: after 
now(CLOCK_REALTIME)
[9.104661] mysystem systemd-timesyncd[311]: load_clock_timestamp: before 
return
[9.104801] mysystem systemd-timesyncd[311]: After load_clock_timestamp
[9.104944] mysystem systemd-timesyncd[311]: After drop_privileges
[9.105086] mysystem systemd-timesyncd[311]: After manager_new
[9.298678] mysystem systemd-timesyncd[311]: After manager_parse_config_file
[9.298894] mysystem systemd-timesyncd[311]: Before sd_notify
[9.299048] mysystem systemd[1]: Started Network Time Synchronization.
```


Thanks,

Paul


[1] https://github.com/systemd/systemd/issues/5024

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Short way to show messages of executable and unit with `journalctl`

[Paul Menzel]

Dear systemd folks,


Is there a shorter way than below to show all messages of an executable
and a unit?

```
$ journalctl _COMM=sudo + _SYSTEMD_UNIT=NetworkManager.service
```

I would be happy about a command, that involves `-u` so that I don’t
have to type the suffix `.service`.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Strange output of `systemd-analyze critical-chain`

[Paul Menzel]

Dear systemd folks,


I am using systemd 232-3 from Debian sid/unstable.

```
$ systemd --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDNar systemd 
folks,
```

On the underpowered ASRock E350M1, startup is quite slow.

The output of `systemd-analyze blame` also looks quite strange.

```
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @3min 6.269s
└─acct.service @6min 32.163s +55ms
  └─basic.target @1min 29.644s
    └─paths.target @1min 29.639s
  └─cups.path @1min 29.634s
    └─sysinit.target @1min 29.554s
  └─systemd-timesyncd.service @1min 29.275s +263ms
    └─systemd-tmpfiles-setup.service @1min 28.575s +620ms
  └─systemd-journal-flush.service @13.493s +1min 15.054s
    └─var.mount @12.408s +1.057s
  └─systemd-fsck@dev-map\x2dvar.service @12.377s +17ms
    └─dev-mapper-speicher\x2dvar.device @12.205s
```

It jumps from 1:30 to 6:32 minutes but the difference is shown as 55
ms.

As written, the systemd is quite underpowered. Might that be the
reason?

Here is the output of `systemd-analyze blame`.

```
5min 39.610s apt-daily.service
1min 21.012s tor@default.service
1min 15.054s systemd-journal-flush.service
 1min 9.497s NetworkManager-wait-online.service
 53.514s libvirt-guests.service
 20.218s libvirtd.service
 16.227s timidity.service
 15.682s accounts-daemon.service
 12.913s NetworkManager.service
 12.889s vdr.service
 11.915s apache2.service
 11.143s ModemManager.service
 10.434s dev-mapper-speicher\x2dusr.device
 10.349s lirc.service
  9.904s dev-mapper-speicher\x2droot.device
  8.397s irqbalance.service
  7.531s exim4.service
  7.164s srv-bilder.mount
  6.602s tor.service
  6.568s lm-sensors.service
  6.542s klogd.service
  6.539s restorecond.service
  6.518s rsyslog.service
  6.509s pppd-dns.service
  6.241s minissdpd.service
  5.343s colord.service
  4.982s ebtables.service
  4.702s kdump-tools.service
  4.631s polkit.service
  4.620s rc-local.service
  3.853s srv-filme.mount
  3.302s binfmt-support.service
  3.235s networking.service
  3.157s lvm2-monitor.service
  3.063s ssh.service
  2.732s keyboard-setup.service
  2.281s boot.mount
  2.151s systemd-tmpfiles-setup-dev.service
  1.915s gdm.service
  1.857s systemd-tmpfiles-clean.service
  1.788s console-setup.service
  1.687s dev-mapper-speicher\x2dswap.swap
  1.681s systemd-cryptsetup@md1_crypt.service
  1.603s home.mount
  1.270s iio-sensor-proxy.service
  1.258s systemd-sysctl.service
  1.063s systemd-random-seed.service
  1.058s systemd-udevd.service
  1.057s var.mount
  1.049s speech-dispatcher.service
  1.031s udhcpd.service
[…]
```

Do you know what is going on?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Depending on services from a service unit template

[Paul Menzel]

Dear Michael, dear Andrei,


Thank you for replying.


Am Montag, den 27.06.2016, 15:37 +0200 schrieb Michael Biebl:
> 2016-06-27 13:49 GMT+02:00 Andrei Borzenkov <arvidj...@gmail.com>:
> > On Mon, Jun 27, 2016 at 9:25 AM, Paul Menzel wrote:

> > > having a template for a service unit like `example@.service`, and
> > > starting several services from it, is there a way, to let another
> > > service unit require all services started from that template?
> > 
> > I do not think it is possible. In other direction it may work with
> > some workaround (i.e. make every instance of template be required
> > by specific services).
> 
> PartOf= in the template service might be what you are looking for.

From the manual page systemd.unit:

>    PartOf=
>    Configures dependencies similar to Requires=, but limited
> to stopping and restarting of units. When systemd stops or restarts
> the units listed here, the action is propagated to this unit. Note
> that this is a one-way dependency — changes to this unit do not
> affect the listed units.

So, it could indeed be what I am looking for. In my use case, it
doesn’t feel right yet though.

There are several instances of a Web application started from
example@.service. In front of it is the proxy HAProxy.

So in my reading, saying that the Web application instances is a *part
of* HAProxy, doesn’t totally feel/sound right to me.

Also, asking for `Requires=` was, that HAProxy seems to check the
configured backends to run, and refuses to start if they don’t. That’s
why, all the Web applications are required before the HAProxy start-up.

If I am not mistaken, `PartOf=` does not solve that problem.

Do you have another suggestion?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Depending on services from a service unit template

[Paul Menzel]

Dear systemd folks,


having a template for a service unit like `example@.service`, and
starting several services from it, is there a way, to let another
service unit require all services started from that template?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

[Paul Menzel]

Dear systemd folks,


the setup is as follows.

Nginx is used as the Web server, which communicates with a Ruby on
Rails application over a socket. Puma [1] is used as the application
server.

Nginx and Puma are managed by systemd service files.

If a new version of the application is installed, the goal is that
there is no downtime. That means, until the application with the new
code isn’t ready yet to serve requests, the old application still
answers them, that means, not only are no requests lost, but during
restart the visitor does not need to wait any longer than normally.

In this case, JRuby is used, which means that application start, `sudo
systemctl start web-application.service` takes more than 30 seconds.

So, `sudo systemctl restart web-application.service` is not enough as
Puma takes some time to be started. (The socket activation described in
the Puma systemd documentation [2] only takes care, that no requests
are lost. The visitor still has to wait.)

Is that possible by just using systemd, or is a load balancer like
HAProxy or a special NGINX configuration and service file templates
needed?

My current thinking would be, that a service file template for the Puma
application server is used. The new code is then started in parallel,
and if it’s done, it “takes over the socket”. (No idea if NGINX would
need to be restarted.) Then the old version of the code is stopped. (I
don’t know how to model that last step/dependency.)

What drawbacks does the above method have? Is it implementable?

How do you manage such a setup?


Thanks,

Paul


[1] http://puma.io/
[2] https://github.com/puma/puma/blob/master/docs/systemd.md

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd as Docker process manager (was: Docker, Supervisor and systemd)

[Paul Menzel]

Dear Lennart,


a late thank you for your reply!


Am Freitag, den 21.02.2014, 19:39 +0100 schrieb Lennart Poettering:
 On Thu, 20.02.14 23:25, Paul Menzel wrote:
  
  Docker, “an open-source project to easily create lightweight, 
  portable, self-sufficient containers from any application”, [1] 
  mostly recommends to use Supervisor [2] to control the processes to 
  be run in the container, like starting and restarting them and 
  logging the output.
  Actually all things systemd also does to my knowledge. Supervisor 
  also needs a configuration file for each process, which it should 
  start.
  
  Has somebody experiences to use systemd for that? Or is there a 
  reason why systemd should not be used for that?
 
 systemd should work fine for that. I figure systemd is not yet
 everywhere hence they suggest an option you can install everywhere...
 
 I had a look at the configuration file language of supervisord. THere
 appears to be nothing interesting we couldn't do already. I mean, 
 there are certain differences, for example they have an XMLRPC API, 
 while ours is via D-Bus, but other than that I don't see much... They 
 have some fcgi hookup, but I don't grok that, and I figure we already 
 can do kinda the same with socket activation, but dunno...

Finally, I looked into this topic again to use systemd as the process
manager for a Docker container. I found Dan Walsh’s great post *Running
systemd within a docker container*, written two month after my message
to the systemd-devel list, talking about some bugs and other issues,
where most of them are solved now with at least Docker 1.6, so systemd
can be used without much problems as the process manager.

To my knowledge there are two issue left. I enumerate these below and
add two more general questions.

1. The capability `SYS_ADMIN` has to be given(?) to the Docker
container.

--cap-add SYS_ADMIN

Otherwise things like `systemctl` do not work and fail with the message
that D-Bus is not available.

Reading the manual page *capabilities* (`man 7 capabilities` [1]) shows
quite an excessive list.

   CAP_SYS_ADMIN
  * Perform a range of system administration operations
including: quotactl(2), mount(2), umount(2), swapon(2),
setdomainname(2);
  * perform privileged syslog(2) operations (since Linux 2.6.37,
CAP_SYSLOG should be used to permit such operations);
  * perform VM86_REQUEST_IRQ vm86(2) command;
  * perform IPC_SET and IPC_RMID operations on arbitrary System
V IPC objects;
  * override RLIMIT_NPROC resource limit;
  * perform operations on trusted and security Extended
Attributes (see xattr(7));
  * use lookup_dcookie(2);
  * use ioprio_set(2) to assign IOPRIO_CLASS_RT and (before
Linux 2.6.25) IOPRIO_CLASS_IDLE I/O scheduling classes;
  * forge PID when passing socket credentials via UNIX domain
sockets;
  * exceed /proc/sys/fs/file-max, the system-wide limit on the
number of open files, in system calls that open files (e.g.,
accept(2), execve(2), open(2), pipe(2));
  * employ CLONE_* flags that create new namespaces with
clone(2) and unshare(2) (but, since Linux 3.8, creating user
namespaces does not require any capability);
  * call perf_event_open(2);
  * access privileged perf event information;
  * call setns(2) (requires CAP_SYS_ADMIN in the target
namespace);
  * call fanotify_init(2);
  * perform KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2)
operations;
  * perform madvise(2) MADV_HWPOISON operation;
  * employ the TIOCSTI ioctl(2) to insert characters into the
input queue of a terminal other than the caller's
controlling terminal;
  * employ the obsolete nfsservctl(2) system call;
  * employ the obsolete bdflush(2) system call;
  * perform various privileged block-device ioctl(2) operations;
  * perform various privileged filesystem ioctl(2) operations;
  * perform administrative operations on many device drivers.

So a container with that capability won’t be that contained anymore.

Do you know of a way to run systemd within the container without adding
the capability SYS_ADMIN?

2. systemd-docker [4][7]

Quoting the systemd-docker README.md [4]:

 Why I wrote this?

 The full context is in Docker Issue #6791 [5] and this mailing list
 thread [6]. The short of it is that systemd does not actually
 supervise the Docker container but instead the Docker client. This
 makes systemd incapable of reliably managing Docker containers
 without hitting a bunch of really odd situations.

Is it planned to solve this in systemd somehow

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Paul Menzel]

Dear poma,


Thank you for the reply with a test and sorry for my late reply. I was
unfortunately unable to test this on the server, as there was no
maintenance window yet. It’s still on my todo list though.

Am Donnerstag, den 09.04.2015, 00:28 +0200 schrieb poma:
 On 08.04.2015 23:05, Lennart Poettering wrote:
  On Wed, 08.04.15 22:13, Paul Menzel wrote:
  
  Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
  turn this on, then replug it, and measuring the time until networkd
  notices the link beat is back?
 
  It would. But this is a rented Hetzner server and I have no access to
  the data center. Do you have another idea. Please keep in mind that I
  also only have remote access using that NIC. ;-)
  
  Then, I figure a udev rule should do. Something like this (untested:)
  
  ACTION==add, SUBSYSTEM==net, KERNEL!=lo, RUN+=/usr/bin/ethtool $name 
  ...
  
  Replace the ... of course with the ethool options you need.
  
  This would then be run immediately when the device appears. If this
  makes a measurable difference, then let us know.

 /etc/udev/rules.d/10-speed1G-enp1s6.rules
 ACTION==add, SUBSYSTEM==net, RUN+=/usr/sbin/ethtool -s enp1s6 advertise 
 0x20
 
 :03 systemd[1]: Starting Network Service...
 :05 systemd-networkd[1612]: enp1s6  : link configured
 :05 systemd-networkd[1612]: enp1s6  : gained carrier
 :06 systemd-networkd[1612]: enp1s6  : lost carrier
 :09 systemd-networkd[1612]: enp1s6  : gained carrier
 
 ~~~
 
 /etc/udev/rules.d/10-speed1G-enp1s6.rules-
 
 :15 systemd[1]: Starting Network Service...
 :17 systemd-networkd[1633]: enp1s6  : link configured
 :17 systemd-networkd[1633]: enp1s6  : gained carrier

So in your case, `gained carrier` is indeed shown earlier saving two
seconds. The next message probably indicates a problem with the driver.

Poma, what Linux kernel do you use?

Lennart, is poma’s test sufficient to show that integrating an
`advertise` command(?) into systemd-networkd would be useful?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Paul Menzel]

Am Dienstag, den 07.04.2015, 18:37 +0200 schrieb Lennart Poettering:
 On Mon, 06.04.15 22:16, Paul Menzel wrote:
 
  Am Freitag, den 03.04.2015, 16:47 +0200 schrieb Lennart Poettering:
   On Thu, 02.04.15 13:11, Paul Menzel wrote:
  
some network cards with certain cables and devices take up to five
seconds so that the link is up [1].

$ sudo journalctl -u systemd-networkd
-- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 
2015-03-22 08:39:39 CET. --
Mär 20 17:39:31 myhostname systemd-networkd[245]: lo
  : gained carrier
Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0  
  : link configured
Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0  
  : gained carrier

This is annoying if the system is up, but you cannot log into a server
because the NIC is so slow configuring the link.

The Linux kernel module developers from the e1000-devel mailing list
suggested the following [2]:

 Both sides either need to be forced or both sides need to be auto-neg.
 Otherwise the auto-negotiation process will usually detect link (the
 physical signal) but fail to find duplex (since one side is not
 talking) and default to the lowest common denominator, e.g. half
 duplex.  So, you could try forcing speed, it may look right on your
 end but if you have no visibility to the other end it could be running
 at half duplex.

 You may be able to speed up the auto negotiation process by
 exclusively advertising 1000 Mbps Full Duplex.

 # ethtool -s ethX advertise 0x20

In the IRC channel #syst...@irc.freenode.net somebody told me to look
into systemd’s network link configuration (`man systemd.link`).

Reading the manual page, it’s not clear to me, if auto-negotiation is
going to be disabled, if the following is set.

BitsPerSecond=1G
Duplex=Full

Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
could I set that up?
   
   BitsPerSecond= and Duplex= are equivalent to ethtool speed and
   ethtool duplex. 
   
   We currently have no setting in .link files that was equivalent to
   ethtool advertise. Maybe we could add that, Tom?
   
   Paul, are you sure that this will really cut 5s from the configuration
   time? Did you try this?
  
  I am not sure and didn’t try this, as I do not know where to integrate
  that `ethtool -s eth0 advertise …` call. In udev or `systemd-networkd`?
  
  If somebody could help me, how I can test this, I’ll report my findings
  back.
 
 Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
 turn this on, then replug it, and measuring the time until networkd
 notices the link beat is back?

It would. But this is a rented Hetzner server and I have no access to
the data center. Do you have another idea. Please keep in mind that I
also only have remote access using that NIC. ;-)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Paul Menzel]

Am Freitag, den 03.04.2015, 16:47 +0200 schrieb Lennart Poettering:
 On Thu, 02.04.15 13:11, Paul Menzel wrote:

  some network cards with certain cables and devices take up to five
  seconds so that the link is up [1].
  
  $ sudo journalctl -u systemd-networkd
  -- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 2015-03-22 
  08:39:39 CET. --
  Mär 20 17:39:31 myhostname systemd-networkd[245]: lo  : 
  gained carrier
  Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0: 
  link configured
  Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0: 
  gained carrier
  
  This is annoying if the system is up, but you cannot log into a server
  because the NIC is so slow configuring the link.
  
  The Linux kernel module developers from the e1000-devel mailing list
  suggested the following [2]:
  
   Both sides either need to be forced or both sides need to be auto-neg.
   Otherwise the auto-negotiation process will usually detect link (the
   physical signal) but fail to find duplex (since one side is not
   talking) and default to the lowest common denominator, e.g. half
   duplex.  So, you could try forcing speed, it may look right on your
   end but if you have no visibility to the other end it could be running
   at half duplex.
  
   You may be able to speed up the auto negotiation process by
   exclusively advertising 1000 Mbps Full Duplex.
  
   # ethtool -s ethX advertise 0x20
  
  In the IRC channel #syst...@irc.freenode.net somebody told me to look
  into systemd’s network link configuration (`man systemd.link`).
  
  Reading the manual page, it’s not clear to me, if auto-negotiation is
  going to be disabled, if the following is set.
  
  BitsPerSecond=1G
  Duplex=Full
  
  Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
  could I set that up?
 
 BitsPerSecond= and Duplex= are equivalent to ethtool speed and
 ethtool duplex. 
 
 We currently have no setting in .link files that was equivalent to
 ethtool advertise. Maybe we could add that, Tom?
 
 Paul, are you sure that this will really cut 5s from the configuration
 time? Did you try this?

I am not sure and didn’t try this, as I do not know where to integrate
that `ethtool -s eth0 advertise …` call. In udev or `systemd-networkd`?

If somebody could help me, how I can test this, I’ll report my findings
back.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Read and publish firmware time stamps and boot time (was: bootloader time on a non-EFI bootloader)

[Paul Menzel]

[CC’ing coreboot, GRUB, SeaBIOS, Syslinux project and Linux kernel]

Am Montag, den 16.03.2015, 11:38 +0100 schrieb Kay Sievers:
 On Mon, Mar 16, 2015 at 11:29 AM, Umut Tezduyar Lindskog wrote:
  I would like to pass the time it was spent in bootloader to systemd.
  Is there a kernel command line to pass this information on non EFI
  bootloader? Or is there an another way?
 
 No, there isn't anything I know of.
 
 The kernel boot protocol should probably be extended to accept a block
 of values to be passed from the loader to the OS, and be exported
 somewhere by the kernel itself to userspace.
 
 Overloading the kernel command line with that does not sound like the
 right approach. We should not support anything like that from systemd.

Could that approach please be discussed with all firmware, payload and
firmware projects? For example, coreboot (and the depthcharge payload
used on Chromebooks and Chromeboxes) already store the time stamps in
its CBMEM, which can be read with the utility `cbmem` with `cbmem -t`
[1] or with GRUB’s `coreboot_boottime` command.

10 entries total:

  10:start of ramstage 9
  30:device enumeration441 (432)
  40:device configuration  95,357 (94,915)
  50:device enable 99,275 (3,918)
  60:device initialization 109,246 (9,971)
  70:device setup done 181,906 (72,659)
  75:cbmem post182,274 (368)
  80:write tables  182,276 (2)
  90:load payload  183,873 (1,597)
  99:selfboot jump 283,779 (99,905)

GRUB also has a `boottime` command outputting times like how long a
module needed to load.

One approach would be, that the Linux kernel has drivers to read the
different implementations on how to store the boot time and then exports
those to userspace.

The other approach, and probably more feasible one, is that all firmware
projects use the same standard/specification.

What is actually needed? Are pairs of

project, stage name, time in milliseconds since start of program

where each project gets assigned a unique ID. Do you need more data?


Thanks,

Paul


[1] 
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=util/cbmem/cbmem.c;h=4314d3077f2f657190d9afd63234d9621c59eb91;hb=HEAD


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Analyzing and debugging userspace services (with e. g. Valgrind)

[Paul Menzel]

Dear systemd folks,


does systemd provide an option to debug userspace services with, for
example, the instrumentation framework Valgrind [1] to find memory leaks
or analyze the memory usage in more detail?

If it does not, should such a feature be added? Would it be useful, to
just have a switch or option `Valgrind=true` or something like it? It’d
also be nice to just have a global switch `systemd.valgrind=1` and
systemd will run each service under Valgrind. Problems lie as always in
the details, like if and how suppression files should be passed.

Or should just the unit/service file be edited?


Thanks,

Paul


[1] http://valgrind.org


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Paul Menzel]

Dear systemd folks,


some network cards with certain cables and devices take up to five
seconds so that the link is up [1].

$ sudo journalctl -u systemd-networkd
-- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 2015-03-22 
08:39:39 CET. --
Mär 20 17:39:31 myhostname systemd-networkd[245]: lo  : 
gained carrier
Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0: 
link configured
Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0: 
gained carrier

This is annoying if the system is up, but you cannot log into a server
because the NIC is so slow configuring the link.

The Linux kernel module developers from the e1000-devel mailing list
suggested the following [2]:

 Both sides either need to be forced or both sides need to be auto-neg.
 Otherwise the auto-negotiation process will usually detect link (the
 physical signal) but fail to find duplex (since one side is not
 talking) and default to the lowest common denominator, e.g. half
 duplex.  So, you could try forcing speed, it may look right on your
 end but if you have no visibility to the other end it could be running
 at half duplex.

 You may be able to speed up the auto negotiation process by
 exclusively advertising 1000 Mbps Full Duplex.

 # ethtool -s ethX advertise 0x20

In the IRC channel #syst...@irc.freenode.net somebody told me to look
into systemd’s network link configuration (`man systemd.link`).

Reading the manual page, it’s not clear to me, if auto-negotiation is
going to be disabled, if the following is set.

BitsPerSecond=1G
Duplex=Full

Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
could I set that up?


Thanks,

Paul


[1] http://sourceforge.net/p/e1000/mailman/message/33623906/
[2] http://sourceforge.net/p/e1000/mailman/message/33635403/


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd: Program terminated with signal SIGFPE, Arithmetic exception.

[Paul Menzel]

Am Montag, den 05.01.2015, 17:57 +0100 schrieb Lennart Poettering:
 On Tue, 30.12.14 16:51, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

  using Debian Sid/unstable with systemd 215-8, I still have problems that
  there are time-outs between systemd and D-Bus, even with the current
  D-Bus 1.8.12 [1]. Experiencing this again, where
  `systemd-logind.service` was not started, I was able to log in on tty1
  but in the end I was unable to run any `sudo systemctl` commands as they
  timed out. I also was unable to reboot or halt the system.
  
  Somewhere in that situation systemd also crashed with an arithmetic
  exception; logged as `Caught FPE` in `/var/log/syslog`.
  
  I created ticket #87349 in the Freedesktop.org Bugzilla bug tracker [2].
  The backtrace is pasted in the original upstream bug report and in this
  message at the end.
 
 Is there any known, easy way to reproduce the issue?

Sorry, I do not know of one and I was not able to reproduce it another
time.

 Is it possible that something in your boot causes the systemd
 configuration to be reloaded?

Sorry, I do not know. Any idea, how I can check that?

 I now made some changes to git
 (9c3349e23b14db27e7ba45f82cf647899c563ea9) that add an explicit
 assert() around the line where the devision by zero happens. Most
 likely the counting of running jobs got confused, hence I reworked
 that code too. Not sure if it fixes the issue, but I can't test this,
 since I have no idea how to trigger it...
 
 Anyway, would be good if you could check current git, to see if things
 are better for you...

Thank you. Do you think it would be good for distributions to backport
it?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fix spell

[Paul Menzel]

Dear Susant,


Am Dienstag, den 30.12.2014, 13:35 +0530 schrieb Susant Sahani:

thank you for the patch.

Could you please fix the summary line? For example use

man: Fix three typos

or

man: Fix spelling

as that also shows that the manual pages are touched.

`git commit --amend` let’s you update the commit message.

 ---
  man/sd_event_add_child.xml  | 2 +-
  man/sd_event_add_signal.xml | 2 +-
  man/systemctl.xml   | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd: Program terminated with signal SIGFPE, Arithmetic exception.

[Paul Menzel]

Dear systemd folks,


using Debian Sid/unstable with systemd 215-8, I still have problems that
there are time-outs between systemd and D-Bus, even with the current
D-Bus 1.8.12 [1]. Experiencing this again, where
`systemd-logind.service` was not started, I was able to log in on tty1
but in the end I was unable to run any `sudo systemctl` commands as they
timed out. I also was unable to reboot or halt the system.

Somewhere in that situation systemd also crashed with an arithmetic
exception; logged as `Caught FPE` in `/var/log/syslog`.

I created ticket #87349 in the Freedesktop.org Bugzilla bug tracker [2].
The backtrace is pasted in the original upstream bug report and in this
message at the end.


Thanks,

Paul


[1] https://bugs.freedesktop.org/show_bug.cgi?id=87424
Time-out problems during boot with systemd
[2] https://bugs.freedesktop.org/show_bug.cgi?id=87349

-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4
ii  libc6   2.19-13
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-4
ii  libgcrypt20 1.6.2-4+b1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-8
ii  mount   2.25.2-4
ii  sysv-rc 2.88dsf-58
ii  udev215-8
ii  util-linux  2.25.2-4

Versions of packages systemd recommends:
ii  dbus1.8.12-3
ii  libpam-systemd  215-8

Versions of packages systemd suggests:
pn  systemd-ui  none

-- no debconf information

-- Backtrace
Thread 1 (Thread 0xb73417c0 (LWP 3020)):
#0  0xb7650d3c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7603bb6 in raise (sig=8) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = optimized out
resultvar = optimized out
pid = optimized out
#2  0xb7686e6b in crash.lto_priv.235 (sig=8) at ../src/core/main.c:158
rl = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615}
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 repeats 32 times}}, sa_flags = 0, 
  sa_restorer = 0x0}
pid = optimized out
__func__ = crash
__PRETTY_FUNCTION__ = crash
#3  signal handler called
No symbol table info available.
#4  0xb772fcdf in manager_print_jobs_in_progress (m=0xb79c6bd0) at 
../src/core/manager.c:170
job_of_n = 0x0
j = optimized out
counter = 0
cylon = 
|\000\000\000\060ᶷ\000\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\001\000\000
time = 
\002\000\000\000\003\000\000\000\005\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\000M\362\261\v\000\000\000\210P\245\267\071Hk\267h:{\267\005\000\000\000\v\000\000\000\210P\245\267
limit = no limit, '\000' repeats 55 times
x = optimized out
i = 0x0
cylon_pos = optimized out
#5  manager_dispatch_jobs_in_progress (source=0xb7b64fe8, usec=432972905, 
userdata=0xb79c6bd0) at ../src/core/manager.c:1846
m = 0xb79c6bd0
r = optimized out
next = optimized out
__PRETTY_FUNCTION__ = manager_dispatch_jobs_in_progress
#6  0xb76a157d in source_dispatch (s=0xb7b64fe8) at 
../src/libsystemd/sd-event/sd-event.c:2024
r = optimized out
__PRETTY_FUNCTION__ = source_dispatch
__func__ = source_dispatch
#7  0xb76a6b94 in sd_event_run (e=optimized out, timeout=optimized out) at 
../src/libsystemd/sd-event/sd-event.c:2314
ev_queue = optimized out
ev_queue_max = optimized out
p = optimized out
r = optimized out
i = optimized out
m = 1
timedout = false
__PRETTY_FUNCTION__ = sd_event_run
#8  0xb7731f13 in manager_loop (m=0xb79c6bd0) at ../src/core/manager.c:1912
wait_usec = 18446744073709551615
rl = {interval = 100, begin = 432639580, burst = 5, num = 26074}
__PRETTY_FUNCTION__ = manager_loop
__func__ = manager_loop
#9  0xb7685062 in main (argc=1, argv=0xbfe55314) at ../src/core/main.c:1743
m = optimized out
---Type return to continue, or q return to quit---
r = optimized out
retval = 1
before_startup = optimized out
after_startup = optimized out
timespan =  
!4\267@\373d\267\234u_\267\070tE\267\364^_\267\001\000\000\000\000\000\000\000 
\364e\267\210Q\345\277\000\060g\267dO\345\277 \372d\267 

Re: [systemd-devel] Small fixes to accelerometer

[Paul Menzel]

Dear Robert,


thank you for your patch. You should tag patches with [PATCH] in the
subject. Your MUA (mail client) Claws Mail can probably even import the
mbox file `git format-patch -1` creates, which you attached.


Am Dienstag, den 30.12.2014, 09:23 +0100 schrieb Robert Milasan:
 From 7aaa2c1b6b6a6d0ef391610e932d6eff010dea41 Mon Sep 17 00:00:00 2001
 From: Robert Milasan rmila...@suse.com
 Date: Tue, 30 Dec 2014 09:20:42 +0100
 Subject: [PATCH] accelerometer: drop unused -x option, display short options
  too.

As you can see from the line break in the summary, it is too long, which
in this case stems from the fact, that you have one commit for two
issues. It’s good measure to send one patch for one problem.

Could you please submit two patches instead? `git add -p` helps here.
Please ask if you need help splitting the commit up.

 ---
  src/udev/accelerometer/accelerometer.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/udev/accelerometer/accelerometer.c 
 b/src/udev/accelerometer/accelerometer.c
 index dd4b7dc..9c13d97 100644
 --- a/src/udev/accelerometer/accelerometer.c
 +++ b/src/udev/accelerometer/accelerometer.c
 @@ -198,8 +198,8 @@ static void test_orientation(struct udev *udev,
  static void help(void)
  {
  printf(Usage: accelerometer [options] device path\n
 - --debug debug to stderr\n
 - --help  print this help text\n\n);
 + -d,--debug debug to stderr\n
 + -h,--help  print this help text\n\n);

Should there be a space after the `,`? Do the descriptions still align
well.

  }
  
  int main (int argc, char** argv)
 @@ -229,7 +229,7 @@ int main (int argc, char** argv)
  while (1) {
  int option;
  
 -option = getopt_long(argc, argv, dxh, options, NULL);
 +option = getopt_long(argc, argv, dh, options, NULL);

Good find!

  if (option == -1)
  break;


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] accelerometer: display short options too

[Paul Menzel]

Am Dienstag, den 30.12.2014, 18:58 +0100 schrieb Robert Milasan:
 ---
  src/udev/accelerometer/accelerometer.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Awesome! Thank you for splitting these up and submitting a v2!

 diff --git a/src/udev/accelerometer/accelerometer.c
 b/src/udev/accelerometer/accelerometer.c index 23d6f78..9c13d97 100644
 --- a/src/udev/accelerometer/accelerometer.c
 +++ b/src/udev/accelerometer/accelerometer.c
 @@ -198,8 +198,8 @@ static void test_orientation(struct udev *udev,
  static void help(void)
  {
  printf(Usage: accelerometer [options] device path\n
 - --debug debug to stderr\n
 - --help  print this help text\n\n);
 + -d,--debug debug to stderr\n
 + -h,--help  print this help text\n\n);

1. I still wonder if the description is aligned after this patch is
applied.
2. A space after the comma, `-d, --debug` would be helpful in my
opinion.

  }
  
  int main (int argc, char** argv)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] LUKS passphrase asked twice when using plain device names

[Paul Menzel]

Dear systemd and dracut folks,


with Debian Sid/unstable, using plain device names like `/dev/sda1` in
`/etc/fstab` and `/etc/crypttab` the LUKS passphrase has to be entered
twice. Once it asked by dracut and once by systemd. I did not yet try
with UUIDs and ask first if that is an error?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting CUPS very late on a desktop and non-server system

[Paul Menzel]

Dear Michael,


thank you for your answer.


Am Freitag, den 21.02.2014, 00:21 +0100 schrieb Michael Biebl:
 This might be of interest to you:
 http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-February/001433.html
 
 So, the cups maintainer is already looking into this. It has to be
 said CUPS is not the most trivial wrt proper systemd support.

Indeed, that addresses my question. Updating to CUPS package 1.7.1-6,
which includes these changes, `systemd-analyze plot` suggests that
`cups-browsed.service` now only takes 33 ms.

The whole user space supposedly takes around 1.5 s, which I hope will
improve even further in the future. Though the “experienced” time,
meaning until GDM’s login screen was there, was around five seconds.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Docker, Supervisor and systemd

[Paul Menzel]

Dear systemd folks,


Docker, “an open-source project to easily create lightweight, portable,
self-sufficient containers from any application”, [1] mostly recommends
to use Supervisor [2] to control the processes to be run in the
container, like starting and restarting them and logging the output.
Actually all things systemd also does to my knowledge. Supervisor also
needs a configuration file for each process, which it should start.

Has somebody experiences to use systemd for that? Or is there a reason
why systemd should not be used for that?


Thanks,

Paul


[1] https://www.docker.io/
[2] http://supervisord.org/


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Starting CUPS very late on a desktop and non-server system

[Paul Menzel]

Dear systemd folks,


after Debian’s CTTE chose systemd as the default init system for the
next Debian release, I installed it on one of the systems.

Looking at the output `systemd-analyze plot`, I noticed that CUPS takes
700 ms to start and as this is a desktop system where not a lot is
printed and when, then only after the user has logged in, I wonder how
that can be dealt with systemd. Like starting it only after user login?
Or is that something which is not nicely doable because CUPS runs as a
system daemon?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core/main.c: only reopen /dev/console if we switch-root to a custom init

[Paul Menzel]

Dear Harald,


thank you for the patch.


Am Donnerstag, den 12.07.2012, 08:43 +0200 schrieb har...@redhat.com:
 From: Harald Hoyer har...@redhat.com

What happens otherwise? Is there an error message?

 ---
  src/core/main.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/core/main.c b/src/core/main.c
 index 6f6b565..a7172c1 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1672,9 +1672,6 @@ finish:
   * rebooted while we do that */
  watchdog_close(true);
  
 -/* Reopen the console */
 -make_console_stdio();
 -
  if (switch_root_dir) {
  r = switch_root(switch_root_dir);
  if (r  0)
 @@ -1711,6 +1708,9 @@ finish:
  execv(args[0], (char* const*) args);
  }
  
 +/* Reopen the console */
 +make_console_stdio();
 +
  /* Try the fallback, if there is any, without any
   * serialization. We pass the original argv[] and
   * envp[]. (Well, modulo the ordering changes due to


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

[Paul Menzel]

Am Montag, den 02.07.2012, 13:04 -0700 schrieb David Strauss:
 On Fri, Jun 29, 2012 at 4:00 PM, Paul Menzel wrote:
  Additionally `After=nss-lockup.target` should be set, so that the NTP

Ah, nice typo I got here: s/lockup/lookup/.

  daemon actually finds a NTP server.
 
 Also, is this necessary? Can't chronyd just fail to sync NTP until it
 works? There's value to an NTP daemon running even if it lacks
 upstream sync sources for a while.

Which? But it might be true.

 I'm also generally skeptical of After= without a corresponding
 Requires= entry because it only affects the ordering if the other unit
 is already present in the working set of services then being started.

I did not get that. The manuals are waiting for me.

 If something's required to happen before a unit, you need both.

Understood.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

[Paul Menzel]

Am Dienstag, den 03.07.2012, 00:55 +0200 schrieb Kay Sievers:
 On Tue, Jul 3, 2012 at 12:44 AM, Paul Menzel wrote:
  I'm also generally skeptical of After= without a corresponding
  Requires= entry because it only affects the ordering if the other unit
  is already present in the working set of services then being started.
 
  I did not get that. The manuals are waiting for me.
 
  If something's required to happen before a unit, you need both.
 
  Understood.
 
 $ man systemd.unit
 
 Before=, After=
 Configures ordering dependencies between units. If a unit foo.service
 contains a setting Before=bar.service and both units are being
 started, bar.service's start-up is delayed until foo.service is
 started up.

So »started up« does not mean is started up and finished with execution?

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

[Paul Menzel]

Dear systemd folks,


Am Samstag, den 30.06.2012, 01:00 +0200 schrieb Paul Menzel:

 Am Freitag, den 22.06.2012, 11:57 +0200 schrieb Paul Menzel:
 
  Fedora ships systemd service files for chrony [1][2].
  
  • chrony-wait.service:
  
 1 [Unit]
 2 Description=Wait for chrony to synchronize system clock
 3 After=chronyd.service
 4 Requires=chronyd.service
 5 Before=time-sync.target
 6 Wants=time-sync.target
 7 
 8 [Service]
 9 Type=oneshot
10 # Wait up to ~10 minutes for chronyd to synchronize and the remaining
11 # clock correction to be less than 0.1 seconds
12 ExecStart=/usr/bin/chronyc waitsync 60 0.1
13 RemainAfterExit=yes
14 
15 [Install]
16 WantedBy=multi-user.target
  
  • chronyd.service:
  
 1 [Unit]
 2 Description=NTP client/server
 3 After=syslog.target ntpdate.service
 4 Conflicts=ntpd.service
 5 BindTo=systemd-timedated-ntp.target
 6 
 7 [Service]
 8 Type=forking
 9 EnvironmentFile=-/etc/sysconfig/chronyd
10 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey
11 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS
12 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers
13 
14 [Install]
15 WantedBy=multi-user.target
  
  Do these look good enough to get upstream? `systemd-arch-units` refused
  a pull request [3].
 
 It was pointed out that the service files above are very Fedora
 specific. Mantas pointed out that Arch Linux now ships unit files
 directly [4]
 
 [Unit]
 Description=Chrony Network Time Daemon
 
 [Service]
 Type=forking
 ExecStart=/usr/sbin/chronyd
 PIDFile=/var/run/chronyd.pid
 
 [Install]
 WantedBy=multi-user.target
 
 and therefore the pull request above was rejected. Furthermore David had
 some great ideas whose result is quite similar to the service file in
 Arch Linux.
 
 [Unit]
 Description=Chrony Network Time Daemon
 After=nss-lockup.target syslog.target
 
 [Service]
 ExecStart=/usr/sbin/chronyd -n
 
 [Install]
 WantedBy=multi-user.target
 
 David suggested that a separate system user could be used for this
 daemon too and systemd should do this.
 
 But it looks like that Arch Linux or Debian assume `chronyd` is run as
 `root` and do not set up devices or certain files for time setting to be
 used by a different user than root.
 
 Additionally `After=nss-lockup.target` should be set, so that the NTP
 daemon actually finds a NTP server.
 
 And lastly, in the directory `units/` of the systemd source tree
 contains `time-sync.target` and the Fedora services use that too. But
 reading the manual of systemd.special, my take on this is this is just a
 compatibility file and should not be used in a systemd service file.
 
 So does the last service file look reasonable and should be used for
 upstream inclusion?

Another problem, upstream cannot decide and each distribution has to, is
that when chronyd starts it starts as offline. I have not found a way to
start the daemon as online.

Therefore normally some kind of init.d script is run to read the
password from `/etc/chrony/chrony.keys` (in Debian) and to execute the
client `chronyc` and passes the command online to put the NTP server
sources online [5].

I do not know how Arch Linux is doing this, but in their Wiki suggests
to put some scripts under `/etc/NetworkManager/dispatcher.d/`
NetworkManager can execute when an interface goes up or down [6].

Under Debian NetworkManager ships a compatibility script to run scripts
`/etc/network/if-{up,down}.d/` and I successfully put some scripts in
there to put chrony online or offline.

But these are some problems I see that upstreaming unit files which all
distributions can use will be difficult.


Thanks,

Paul


  [1] 
  http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chrony-wait.service;h=3958160098eae926aaf7136d7b5b8bab42a6aa35;hb=HEAD
  [2] 
  http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chronyd.service;h=167332e37511f19019aabc32f82a47ef80656cd5;hb=HEAD
  [3] https://github.com/falconindy/systemd-arch-units/issues/98
 [4] 
 https://projects.archlinux.org/svntogit/community.git/tree/trunk/service?h=packages/chrony
[5] http://chrony.tuxfamily.org/manual.html#Usage-reference
[6] 
https://wiki.archlinux.org/index.php/Chrony#Using_NetworkManager_to_let_chronyd_go_online


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd numbers for Debian Sid/unstable system

[Paul Menzel]

Am Mittwoch, den 27.06.2012, 12:35 +0200 schrieb Lennart Poettering:
 On Wed, 27.06.12 12:18, Paul Menzel wrote:

[…]

 540ms chrony.service
 515ms rc.local.service
 
 The rc-local generator should be smart enough to pull this in only if it
 exists. It's a really slow service and most likely just a NOP anyway.

Right. The default file `/etc/rc.local` just contains `exit 0`. So I
masked that service file.

$ sudo systemctl mask rc.local.service

 509ms vdr.service
 487ms sysfsutils.service
 
 What is this? This stuff sounds like something that can just go away...

I was surprised too. It looks like this was installed by
`grml-debootstrap` and I removed it using the following command.

$ sudo aptitude purge --purge-unused sysfsutils

[…]

 191ms screen-cleanup.service
 
 Something for tmpfiles?

I have to look into that.

 167ms systemd-tmpfiles-setup.service
 147ms pulseaudio.service
 
 Hmm, as a system service? Meh..

Well, no. Debian still ships an init.d script which reads
`/etc/default/pulseaudio` and there system mode is disabled by default.
So I masked this one too.

$ sudo systemctl mask pulseaudio.service

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cryptsetup: add keyfile-offset= support

[Paul Menzel]

Dear Tom,


Am Freitag, den 29.06.2012, 13:40 +0200 schrieb Tom Gundersen:
 This is useful if your keyfile is a block device, and you want to
 use a specific part of it, such as an area between the MBR and the
 first partition.
 
 This feature is documented in the Arch wiki[0], and has been supported
 by the Arch initscripts, so would be nice to get this into systemd.

please document that libcryptsetup ≥ 1.4.2 is needed in the commit
message.

 [0]:
 https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition

Please no line break here.

 ---
  configure.ac|  2 +-
  man/crypttab.xml| 13 +
  src/cryptsetup/cryptsetup.c | 11 ++-
  3 files changed, 24 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index e0a2526..e1876cc 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -333,7 +333,7 @@ AC_SUBST(AUDIT_LIBS)
  have_libcryptsetup=no
  AC_ARG_ENABLE(libcryptsetup, AS_HELP_STRING([--disable-libcryptsetup], 
 [disable libcryptsetup tools]))
  if test x$enable_libcryptsetup != xno; then
 -PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup ],
 +PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup = 1.4.2 ],
  [AC_DEFINE(HAVE_LIBCRYPTSETUP, 1, [Define if libcryptsetup 
 is available]) have_libcryptsetup=yes], have_libcryptsetup=no)
  if test x$have_libcryptsetup = xno -a x$enable_libcryptsetup = 
 xyes; then
  AC_MSG_ERROR([*** libcryptsetup support requested but 
 libraries not found])
 diff --git a/man/crypttab.xml b/man/crypttab.xml
 index f3bde71..e54f78c 100644
 --- a/man/crypttab.xml
 +++ b/man/crypttab.xml
 @@ -131,6 +131,19 @@
  
 
  varlistentry
 +
 termvarnamekeyfile-offset=/varname/term

Wrong indentation?

 +
 + listitemparaSpecifies the number
 +of bytes to skip at the start of
 +the keyfile; see
 +
 citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
 +for possible values and the default
 +value of this
 +option. /para/listitem

No space after full stop and merge with line before?

 +/varlistentry
 +
 +
 +varlistentry
  termvarnamehash=/varname/term
  
  listitemparaSpecifies the hash to
 diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
 index b26fcca..f570724 100644
 --- a/src/cryptsetup/cryptsetup.c
 +++ b/src/cryptsetup/cryptsetup.c
 @@ -37,6 +37,7 @@
  static const char *opt_type = NULL; /* LUKS1 or PLAIN */
  static char *opt_cipher = NULL;
  static unsigned opt_key_size = 0;
 +static unsigned opt_keyfile_offset = 0;
  static char *opt_hash = NULL;
  static unsigned opt_tries = 0;
  static bool opt_readonly = false;
 @@ -79,6 +80,13 @@ static int parse_one_option(const char *option) {
  return 0;
  }
  
 +} else if (startswith(option, keyfile-offset=)) {
 +
 +if (safe_atou(option+15, opt_keyfile_offset)  0) {
 +log_error(keyfile-offset= parse failure, 
 ignoring.);
 +return 0;
 +}
 +
  } else if (startswith(option, hash=)) {
  char *t;
  
 @@ -462,7 +470,8 @@ int main(int argc, char *argv[]) {
   argv[3]);
  
  if (key_file)
 -k = crypt_activate_by_keyfile(cd, argv[2], 
 CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
 +k = crypt_activate_by_keyfile_offset(cd, 
 argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size,
 +opt_keyfile_offset, flags);
  else {
  char **p;

Otherwise this looks good.

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

[Paul Menzel]

Dear systemd folks,


I got some private (I do not know why) replies regarding this service
files giving me some hints.


Am Freitag, den 22.06.2012, 11:57 +0200 schrieb Paul Menzel:

 Fedora ships systemd service files for chrony [1][2].
 
 • chrony-wait.service:
 
1 [Unit]
2 Description=Wait for chrony to synchronize system clock
3 After=chronyd.service
4 Requires=chronyd.service
5 Before=time-sync.target
6 Wants=time-sync.target
7 
8 [Service]
9 Type=oneshot
   10 # Wait up to ~10 minutes for chronyd to synchronize and the remaining
   11 # clock correction to be less than 0.1 seconds
   12 ExecStart=/usr/bin/chronyc waitsync 60 0.1
   13 RemainAfterExit=yes
   14 
   15 [Install]
   16 WantedBy=multi-user.target
 
 • chronyd.service:
 
1 [Unit]
2 Description=NTP client/server
3 After=syslog.target ntpdate.service
4 Conflicts=ntpd.service
5 BindTo=systemd-timedated-ntp.target
6 
7 [Service]
8 Type=forking
9 EnvironmentFile=-/etc/sysconfig/chronyd
   10 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey
   11 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS
   12 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers
   13 
   14 [Install]
   15 WantedBy=multi-user.target
 
 Do these look good enough to get upstream? `systemd-arch-units` refused
 a pull request [3].

It was pointed out that the service files above are very Fedora
specific. Mantas pointed out that Arch Linux now ships unit files
directly [4]

[Unit]
Description=Chrony Network Time Daemon

[Service]
Type=forking
ExecStart=/usr/sbin/chronyd
PIDFile=/var/run/chronyd.pid

[Install]
WantedBy=multi-user.target

and therefore the pull request above was rejected. Furthermore David had
some great ideas whose result is quite similar to the service file in
Arch Linux.

[Unit]
Description=Chrony Network Time Daemon
After=nss-lockup.target syslog.target

[Service]
ExecStart=/usr/sbin/chronyd -n

[Install]
WantedBy=multi-user.target

David suggested that a separate system user could be used for this
daemon too and systemd should do this.

But it looks like that Arch Linux or Debian assume `chronyd` is run as
`root` and do not set up devices or certain files for time setting to be
used by a different user than root.

Additionally `After=nss-lockup.target` should be set, so that the NTP
daemon actually finds a NTP server.

And lastly, in the directory `units/` of the systemd source tree
contains `time-sync.target` and the Fedora services use that too. But
reading the manual of systemd.special, my take on this is this is just a
compatibility file and should not be used in a systemd service file.

So does the last service file look reasonable and should be used for
upstream inclusion?


Thanks,

Paul


 [1] 
 http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chrony-wait.service;h=3958160098eae926aaf7136d7b5b8bab42a6aa35;hb=HEAD
 [2] 
 http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chronyd.service;h=167332e37511f19019aabc32f82a47ef80656cd5;hb=HEAD
 [3] https://github.com/falconindy/systemd-arch-units/issues/98
[4] 
https://projects.archlinux.org/svntogit/community.git/tree/trunk/service?h=packages/chrony


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd numbers for Debian Sid/unstable system

[Paul Menzel]

Am Donnerstag, den 28.06.2012, 07:54 +0200 schrieb Tollef Fog Heen:
 ]] Lennart Poettering 
 
  On Wed, 27.06.12 21:59, Tollef Fog Heen (tfh...@err.no) wrote:

   ]] Lennart Poettering 
   
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
   
   We use the X11 keyboard definitions.  Are you sure you want to
   completely reimplement console-setup? :-)
  
  Ah, hmm. I heard of that. Can you explain how precisely that works? Do
  you actually use the same keybaord definitions, i.e. have converted them
  to console definitions? Or do you just share the same naming namespace?
 
 console-setup reads the xkb definitions and downsamples them to
 something the console can understand.  IIRC, it doesn't work for the
 most complex keymaps and the cases where you have multiple keymaps
 defined which you can switch between, but it works well in the simple
 case of one language.  (IIRC, this is due to kernel limitations in how
 many keys can be defined and such.  Also, I don't think the kernel
 understands Compose.)
 
  Any docs available for this?
 
 There might be some in
 http://ftp.debian.org/debian/pool/main/c/console-setup/console-setup_1.78.tar.gz

You can also clone the Git repository.

$ debcheckout -d console-setup
typegit
url git://git.debian.org/d-i/console-setup.git
top-bases   
topgit  no


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How do I disable old init.d scripts?

[Paul Menzel]

Dear systemd folks,


how can I disable init.d scripts which systemd loads for compatibility
reasons?

$ ls /etc/init.d/motd  (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
   543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] `systemd-analyze blame`indicates GDM3 takes longer to start with service file than with init.d script

[Paul Menzel]

Dear systemd folks,


after a system start I save the output of `systemd-anlyze blame`.

With Debian Sid/unstable, GDM 3.4.1 and the shipped init.d script on
average it took about 120 ms. For example:

124ms gdm3.service

Adding the following service file

$ more /lib/systemd/system/gdm3.service[Unit]
Description=GNOME Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/sbin/gdm3 --nodaemon
Type=dbus
BusName=org.gnome.DisplayManager

[Install]
WantedBy=graphical.target

I now get 190 ms on average, for example:

188ms gdm3.service

Can you think of a reason for that? It should at least not take more
time, should not it?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I disable old init.d scripts?

[Paul Menzel]

Am Montag, den 25.06.2012, 15:38 +0200 schrieb Lennart Poettering:
 On Mon, 25.06.12 15:25, Paul Menzel wrote:

[…]

  how can I disable init.d scripts which systemd loads for compatibility
  reasons?
  
  $ ls /etc/init.d/motd  (or any other init.d script)
  /etc/init.d/motd
  $ systemd-analyze blame | grep motd
 543ms motd.service
  $ sudo systemctl disable motd.service
  Failed to issue method call: No such file or directory
 
 On Fedora we defer to chkconfig automatically for sysv services.

Looking at the code

$ git grep -i chkconfig

this seems to happen for the following distributions.

#if defined (HAVE_SYSV_COMPAT)  (defined(TARGET_FEDORA) || 
defined(TARGET_MANDRIVA) || defined(TARGET_SUSE) || defined(TARGET_MEEGO) || 
defined(TARGET_ALTLINUX) || defined(TARGET_MAGEIA))

 This hookup is currently missing for Debian, but I'd be willing to merge a
 patch for that.

If I am not mistaken, Debian uses `update-rc.d` for that purpose.

Does someone know if it is feasible to just change the one variable (and
options) containing the path to the utilities and reuse the error
handling or will that not work?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel