Re: [systemd-devel] Systemd logo usage

[Colin Guthrie]

Paul Oberosler wrote on 07/03/2023 21:42:

Hi devs,

i i'm currently creating a WinUI 3 based Systemd ".service" file editor 
for Windows (10/11) administartors for easy editing and creation of 
complex service configurations.
I wonder if it's allowed to use the new sytemd logo (great work by the 
way) as the app logo for recognizability of what this dekstop app does?
I would of course mention the creator/designer mentioned on your 
"brand.systemd.io" page in the settings - about section and also in the 
Microsoft Store description.


Not actually noticed the branding before. I immediately thought it 
looked like Pingu's head when he does his "noot noot" noise!


https://media.tenor.com/bUe5f8xAVckC/pingu-noot-noot.gif

A penguin reference seems appropriate too!

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] user unit with delayed users homes mount - ?

[Colin Guthrie]

Andrei Borzenkov wrote on 14/10/2022 12:56:

On Fri, Oct 14, 2022 at 2:48 PM lejeczek  wrote:



Is it possible and if so then how, to make "systemd" account for such a 
"simple" case - where home dir is net mounted very late?


Without knowing how exactly your home directories are mounted it is
rather hard to answer. Are they mounted from within /etc/fstab?

Homes are mounted by other daemons started later(by systemd).



Have you tried to set those daemons Before=systemd-logind.service?



Or perhaps Before=systemd-user-sessions.service?

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] systemd has not the same behaviour following the version of the kernel ; StopWhenUnneeded no longer works

[Colin Guthrie]

 Vernon (France)
+33.(0)2.78.77.03.46

www.sysnav.com <http://www.sysnav.com/en/>





--

Colin Guthrie

Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?

[Colin Guthrie]

Yuri Kanivetsky wrote on 18/09/2022 13:08:


Also, I've created a simple perl server:

https://gist.github.com/x-yuri/45f53c16a99337ba0716a988290491bd

And if I put perl-server.socket and perl-server.service into
/usr/lib/systemd/user, and symlink perl-server.socket into
/usr/lib/systemd/user/sockets.target.wants, it autoactivates on boot.

The confusing thing though is:

$ systemctl --user is-enabled perl-server.socket
disabled


Unless your per-server.socket unit has an [Install] section that 
corresponds to the manual symlinks you've made, the is-enabled test will 
fail.


Ultimately the [Install] section is just instructions to "systemctl 
[--user] enable|disable" to create/delete these symlinks for you as needed.


These same hints are used by is-enabled to check whether it is enabled. 
If you don't have the correct [Install] section, it won't know by which 
route it ultimately becomes enabled if you do the links manually.


Hope that helps explain things.

Col


--

Colin Guthrie

Re: [systemd-devel] Antw: Antw: [EXT] SRe: VirtualBox VM as a unit failures

[Colin Guthrie]

Ulrich Windl wrote on 02/09/2022 10:08:

"Ulrich Windl"  schrieb am 02.09.2022

um
10:12 in Nachricht <6311bafe02a10004d...@gwsmtp.uni-regensburg.de>:

Hi!

The other thing that came to my mind was the ASCI power button: The system


Time for the week-end: s/ASCI/ACPI/


might actually block or ignore it (or asking for the admin password). So I
think it would be a good idea to have a "second line of defense" causing a
hard
stop (power off) if the first method fails within a reasonable timeout.
That's how cluster VM resources are managed, typically.


The script snippet I posted does that.


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

[systemd-devel] SRe: VirtualBox VM as a unit failures

[Colin Guthrie]

dless --comment RHEL7 
--startvm f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config


sep 01 14:22:06 munster.belkin.home systemd[3452]: Starting 
vbox_vm_start@RHEL7.service - VirtualBox VM RHEL7...
sep 01 14:22:06 munster.belkin.home VBoxManage[378730]: VBoxManage: 
error: The machine 'RHEL7' is already locked by a session (or being 
locked or unlocked)
sep 01 14:22:06 munster.belkin.home VBoxManage[378730]: VBoxManage: 
error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component 
MachineWrap, interface IMachine, callee n>
sep 01 14:22:06 munster.belkin.home VBoxManage[378730]: VBoxManage: 
error: Context: "LaunchVMProcess(a->session, sessionType.raw(), 
ComSafeArrayAsInParam(aBstrEnv), progress.asOutPar>
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Control process exited, code=exited, 
status=1/FAILURE
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Failed with result 'exit-code'.
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Unit process 378386 (VBoxXPCOMIPCD) remains 
running after unit stopped.
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Unit process 378392 (VBoxSVC) remains 
running after unit stopped.
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Unit process 378442 (VBoxHeadless) remains 
running after unit stopped.
sep 01 14:22:06 munster.belkin.home systemd[3452]: Failed to start 
vbox_vm_start@RHEL7.service - VirtualBox VM RHEL7.


This the unit file:
× vbox_vm_start@RHEL7.service - VirtualBox VM RHEL7
      Loaded: loaded 
(/home/sergio/.config/systemd/user/vbox_vm_start@.service; enabled; 
vendor preset: disabled)
      Active: failed (Result: exit-code) since Thu 2022-09-01 14:22:06 
-03; 7s ago
     Process: 378730 ExecStart=/usr/bin/VBoxManage startvm RHEL7 --type 
headless (code=exited, status=1/FAILURE)

       Tasks: 40 (limit: 38236)
      Memory: 25.7M
         CPU: 3.338s
      CGroup: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-vbox_vm_start.slice/vbox_vm_start@RHEL7.service

              ├─ 378386 /usr/lib/virtualbox/VBoxXPCOMIPCD
              ├─ 378392 /usr/lib/virtualbox/VBoxSVC --auto-shutdown
              └─ 378442 /usr/lib/virtualbox/VBoxHeadless --comment RHEL7 
--startvm f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config


sep 01 14:22:06 munster.belkin.home systemd[3452]: Starting 
vbox_vm_start@RHEL7.service - VirtualBox VM RHEL7...
sep 01 14:22:06 munster.belkin.home VBoxManage[378730]: VBoxManage: 
error: The machine 'RHEL7' is already locked by a session (or being 
locked or unlocked)
sep 01 14:22:06 munster.belkin.home VBoxManage[378730]: VBoxManage: 
error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component 
MachineWrap, interface IMachine, callee n>
sep 01 14:22:06 munster.belkin.home VBoxManage[378730]: VBoxManage: 
error: Context: "LaunchVMProcess(a->session, sessionType.raw(), 
ComSafeArrayAsInParam(aBstrEnv), progress.asOutPar>
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Control process exited, code=exited, 
status=1/FAILURE
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Failed with result 'exit-code'.
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Unit process 378386 (VBoxXPCOMIPCD) remains 
running after unit stopped.
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Unit process 378392 (VBoxSVC) remains 
running after unit stopped.
sep 01 14:22:06 munster.belkin.home systemd[3452]: 
vbox_vm_start@RHEL7.service: Unit process 378442 (VBoxHeadless) remains 
running after unit stopped.
sep 01 14:22:06 munster.belkin.home systemd[3452]: Failed to start 
vbox_vm_start@RHEL7.service - VirtualBox VM RHEL7.


This is the unit file:
[Unit]
Description=VirtualBox VM %i
After=network.target vboxdrv.service
Before=runlevel2.target shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=no

#ExecStart=/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --startvm 
f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config

ExecStart=/usr/bin/VBoxManage startvm %i --type headless
ExecStop=/usr/bin/VBoxManage controlvm %i acpipowerbutton

[Install]
WantedBy=default.target

(End of file)

What is the proper way to configure this kind of unit?

Thanks in advance



--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org <http://www.lpi.org>



--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] Running actual systemd-based distribution image in systemd-nspawn

[Colin Guthrie]

Andrei Borzenkov wrote on 15/06/2022 16:56:

I tried it (loop mounting qemu image):

systemd-nspawn -D ./hd0 -b

and it failed miserably with "Timeout waiting for device
dev-disk-by...". Which is not surprising as there are no device units
inside of container (it stops in single user allowing me to use sysctl
-t device).

Is it supposed to work at all? Even if I bind mount /dev/disk it does
not help as systemd does not care whether device is actually present or not.


I've not tried "booting" a real install inside nspawn before (just 
images installed by mkosi mostly), but could this just be a by-product 
of it trying to do what /etc/fstab (or other mount units) say to do?


Can you try something like:

touch blank
systemd-nspawn --bind-ro=./blank:/etc/fstab -D ./hd0 -b

to override the /etc/fstab (there may be other more elegant ways to 
disable fstab processing!) and see if that helps?


If you have specific .mount units you may have to add specific 
workarounds to block them too.


HTHs

Col

Re: [systemd-devel] Antw: [EXT] Re: Q: Start network in chroot?

[Colin Guthrie]

Ulrich Windl wrote on 13/06/2022 14:42:

Colin Guthrie  schrieb am 13.06.2022 um 14:58 in

Nachricht :

Ulrich Windl wrote on 13/06/2022 09:09:

Hi!

Two questions:
1) Why can't I use "systemctl start network" in a chroot environment (e.g.

mounting the system from a rescue medium to fix a defective kernel)? When I
try I get: "Running in chroot, ignoring command 'start'"

2) How can I start the network using systemd?


You may wish to consider "booting" the container rather than just chrooting.


No container involved; an unbootable system instead, and I'd like to have 
networking available for repair.
So obviously I cannot boot. Without systemd it wouldn't be a problem.


So you're not running an init system but you want the (not-running) init 
system to run something for you?


If you're wanting to repair a system, and you need networking then bring 
up the network in the repair image before chrooting surely? (i.e. what 
Mantas said)


If you want to run the network inside the (broken) system you're trying 
to repair, then just run the networking scripts or program manually. 
i.e. run whatever /etc/init.d/network says or whatever ExecStart= says 
in /usr/lib/systemd/network.service says (paths may vary).


There will be loads of other stuff that the init system does that won't 
be in place (e.g. tmpfiles, etc.) which you may or may not need to setup 
manually too, but you can likely get it running.


> Without systemd it wouldn't be a problem.

Sure when "init" was just a bundle of scripts, you could run one of the 
scripts it runs and hope for the best. You can generally still do that, 
but just don't expect asking a non-running program to do it for you to work!


Col

Re: [systemd-devel] Q: Start network in chroot?

[Colin Guthrie]

Ulrich Windl wrote on 13/06/2022 09:09:

Hi!

Two questions:
1) Why can't I use "systemctl start network" in a chroot environment (e.g. mounting the 
system from a rescue medium to fix a defective kernel)? When I try I get: "Running in chroot, 
ignoring command 'start'"
2) How can I start the network using systemd?


You may wish to consider "booting" the container rather than just chrooting.

Combined with IPVLAN or similar (which systemd-nspawn makes easy) you 
can bring up a namespaced network interface inside the container 
completely isolated from the host.


I do this for various setups and it works pretty well.

Col

[systemd-devel] mkosi: Empty rpmdb after building older RPM distro on Fedora 36 host

[Colin Guthrie]

Reported here https://github.com/systemd/mkosi/issues/993 but after 
upgrading to Fedora 36 as a host, I'm unable to use mkosi to install RPM 
distros which don't use the /usr/lib/sysimage/rpm path (and/or sqlite) 
as this results in an empty rpmdb post install (tested with mkosi git)


Posting here to see if anyone has any suggestions which they/I can add 
to the issue.


Cheers

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie

Re: [systemd-devel] No space left errors on shutdown with systemd-homed /home dir

[Colin Guthrie]

Hi,

Neal Gompa wrote on 01/02/2022 19:55:

On Tue, Feb 1, 2022 at 2:02 PM Colin Guthrie  wrote:


Goffredo Baroncelli wrote on 30/01/2022 09:27:

On 29/01/2022 19.01, Chris Murphy wrote:

On Sat, Jan 29, 2022 at 2:53 AM Goffredo Baroncelli
 wrote:


I think that for the systemd uses cases (singled device FS), a simpler
approach would be:

   fstatfs(fd, )
   needed = sfs.f_blocks - sfs.f_bavail;
   needed *= sfs.f_bsize

   needed = roundup_64(needed, 3*(1024*1024*1024))

Comparing the original systemd-homed code, I made the following changes
- 1) f_bfree is replaced by f_bavail (which seem to be more
consistent to the disk usage; to me it seems to consider also the
metadata chunk allocation)
- 2) the needing value is rounded up of 3GB in order to consider a
further 1 data chunk and 2 metadata chunk (DUP))

Comments ?


I'm still wondering if such a significant shrink is even indicated, in
lieu of trim. Isn't it sufficient to just trim on logout, thus
returning unused blocks to the underlying filesystem?


I agree with you. In Fedora 35, and the default is ext4+luks+trim
which provides the same results. However I remember that in the past the
default
was btrfs+luks+shrunk. I think that something is changed i.

However, I want to provide do the systemd folks a suggestion ho change
the code.
Even a warning like: "it doesn't work that because this, please drop it"
would be sufficient.



Out of curiosity (see other thread on the systemd list about this), what
it the current recommendation (by systemd/btrfs folks rather then Fedora
defaults) for homed machine partitioning?



I'd probably recommend Btrfs with the /home subvolume set with
nodatacow if you're going to use loops of LUKS backed Btrfs homedir
images. The individual Btrfs loops will have their own COW anyway.

Otherwise, the Fedora defaults for Btrfs should be sufficient.


Thought I'd wait for Fedora 36 to be released with everything I need to 
test this setup.


Fell at the first hurdle of transferring my data in!

I transferred a subset of my data (240Gb) onto an external disk and used:

  homectl with colin -- rsync ...


The transfer worked but the colin.home file grew to 394Gb. Only about 
184Gb used (I presume due to compression).


Ultimately, this was then unmounted and while it said it could shrink 
the filesystem with a "Ready to..." message this either didn't happen or 
the backing file wasn't shrunk to match it. I did receive a message later


I'm not sure now where it's at with recovery but as nothing is strictly 
needed to make this work, I think I'll leave my playing with homed there 
for now and try again at some later date.


I love the whole idea but it's still a bit to bleeding edge and quirky 
for my daily driver just yet!



I've attached various logs in case they are useful (will post separately 
if the list removes this!)



Cheers

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/May 31 09:30:11 colins-laptop systemd-homed[865]: colin: changing state inactive → activating-for-acquire
May 31 09:30:11 colins-laptop systemd-homework[8653]: Provided password unlocks user record.
May 31 09:30:11 colins-laptop systemd-homework[8653]: Successfully locked image file '/home/colin.home'.
May 31 09:30:11 colins-laptop systemd-homework[8653]: Backing file is fully allocated already.
May 31 09:30:11 colins-laptop systemd-homework[8653]: Setting up loopback device /dev/loop0 completed.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Setting up LUKS device /dev/mapper/home-colin completed.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Provided password unlocks user record.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Probing file system completed (found btrfs).
May 31 09:30:12 colins-laptop systemd-homework[8653]: File system check completed.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Mounting file system completed.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Discovered used loopback device /dev/loop0.
May 31 09:30:12 colins-laptop systemd-homework[8653]: offset = 1048576, size = 423003255296, image = 423004320768
May 31 09:30:12 colins-laptop systemd-homework[8653]: Ready to resize image size 393.9G → 458.1G, partition size 393.9G → 458.1G, file system size 393.9G → 458.0G.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Couldn't change image size.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Read embedded .identity file.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Provided password unlocks user record.
May 31 09:30:12 colins-laptop systemd-homework[8653]: Reconciling user identities completed (host and header version were identical).
May 31 09:30:12 colins-laptop systemd-homework[8653]: Reconciling embedded use

Re: [systemd-devel] homed: Issues with LUKS storage on btrfs

[Colin Guthrie]

Hi,

Just wondering if anyone has the latest advice for a future proof setup 
here on Fedora 35 regarding recommendations of base FS etc.


Happy to roll custom systemd installs on top to get latest features etc, 
but don't want to create an inefficient system generally.


Cheers

Col

Colin Guthrie wrote on 06/01/2022 14:42:

Hi,

Sebastian Wiesner wrote on 28/12/2021 00:04:

Hello,

I've experimented with homectl today, and noticed two issues when
creating LUKS-lookback-backed home areas on top of a btrfs filesystem:

1) homectl resize doesn't work reliably on btrfs: It looks as if on
btrfs resizing a home area requires more free space on the underlying
btrfs filesystem than I expected.  I assumed that resizing from X to Y
only requires Y-X extra free space on the underlying device, but on
btrfs it seems to require Y free space, i.e. it looks as if homectl
attempts to allocate the entire home area anew.

I've found https://github.com/systemd/systemd/issues/19398 which looks
like the problem, but went nowhere.

2) homectl creates loopback files which have COW-enabled.  As far as I
understand btrfs it's not recommended to enable COW for large files
which frequently get updated in-place which as far as I see it would
include the backing loopback files for LUKS home areas.

Shouldn't homectl explicitly disable COW for new home areas if the
underlying file system is btrfs?

I can work around 2) by setting -C on /home/ but I haven't figured out
a solution for 1)

Is LUKS on btrfs supported by homectl?  Or should I rather use e.g.
ext4 as underlying file system for /home/?


I'm migrating to a similar setup with a new laptop so would be 
interested in guidance/recommendations on this too if it's available. 
Reddit/other google results seem a little dated.


Managed to get it working on Fedora 35 install with a little PAM 
fighting and selinux tweaks.


Col






--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] homed: Issues with LUKS storage on btrfs

[Colin Guthrie]

Hi,

Sebastian Wiesner wrote on 28/12/2021 00:04:

Hello,

I've experimented with homectl today, and noticed two issues when
creating LUKS-lookback-backed home areas on top of a btrfs filesystem:

1) homectl resize doesn't work reliably on btrfs: It looks as if on
btrfs resizing a home area requires more free space on the underlying
btrfs filesystem than I expected.  I assumed that resizing from X to Y
only requires Y-X extra free space on the underlying device, but on
btrfs it seems to require Y free space, i.e. it looks as if homectl
attempts to allocate the entire home area anew.

I've found https://github.com/systemd/systemd/issues/19398 which looks
like the problem, but went nowhere.

2) homectl creates loopback files which have COW-enabled.  As far as I
understand btrfs it's not recommended to enable COW for large files
which frequently get updated in-place which as far as I see it would
include the backing loopback files for LUKS home areas.

Shouldn't homectl explicitly disable COW for new home areas if the
underlying file system is btrfs?

I can work around 2) by setting -C on /home/ but I haven't figured out
a solution for 1)

Is LUKS on btrfs supported by homectl?  Or should I rather use e.g.
ext4 as underlying file system for /home/?


I'm migrating to a similar setup with a new laptop so would be 
interested in guidance/recommendations on this too if it's available. 
Reddit/other google results seem a little dated.


Managed to get it working on Fedora 35 install with a little PAM 
fighting and selinux tweaks.


Col

Re: [systemd-devel] Run reboot as normal user

[Colin Guthrie]

Mohamed Ali Fodha wrote on 30/11/2021 10:35:
Thank you for the answers, I am working on an embedded system and the 
polkit is not installed (not enabled at all in yocto build).
I have a systemd service that run as a normal user and for some use case 
it requires to do a reboot
I simulate it just for now as a dbus-send as shown below (just for debug 
- dbus-send will be replaced by a binary which will do the reboot)
Previously the guest user was in sudoers (so to run reboot the systemd 
service uses "sudo") but actually our customer wants to remove the guest 
user from sudoers.

Adding capabilities doesn't give me required permissions

/[Service]
User=guest
ExecStart=dbus-send --system --print-reply 
--dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 
org.freedesktop.systemd1.Manager.StartUnit string:reboot.target 
string:replace-irreversibly

AmbientCapabilities=CAP_SYS_BOOT CAP_SYS_ADMIN
CapabilityBoundingSet=CAP_SYS_BOOT CAP_SYS_ADMIN
/
/[Install]
WantedBy=multi-user.target/


If you will have a binary to do the commands then you should just do 
that. It has to be a proper compiled binary (e.g. a simple C program).


Make sure the binary is owned by root and group-owned by the same group 
as your user (hopefully it has a private group) with group r+x 
permission. "Other" should be nothing to prevent abuse. Make sure the 
binary is marked as setuid.


In the binary, ensure you call the appropriate commands to obtain root 
privs (setruid()/setuid() etc. - can't remember off hand what to use)


Then simply exec out to "systemctl reboot".

That way although your user calls the binary, the binary then has 
permission to become root and then "talk" to systemd to tell it to issue 
the reboot.


Capabilities shouldn't come into I don't think as all you're doing is 
talking to systemd which does all the grunt work.


HTHs

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] Run reboot as normal user

[Colin Guthrie]

Mantas Mikulėnas wrote on 30/11/2021 08:42:
On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha 
mailto:fodha.mohamed@gmail.com>> wrote:


Hello,

I want to run reboot as normal user using the following command:
dbus-send --system --print-reply --reply-timeout=2000
--type=method_call --dest=org.freedesktop.login1
/org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot
boolean:false

but I got a Permission denied error.

I checked that verify_shutdown_creds (in logind-dbus.c) calls
bus_verify_polkit_async, could it be the reason why I got permission
denied error while polkit is not installed?


Yes. Polkit is the authorization system that decides whether to allow 
normal users to do privileged actions or not.


I don't want to use Polkit or sudo, is there any solution ?

No.


When you say you don't want to use polkit, are you just saying you want 
to run dbus-send directly rather than prefixing it with pkexec or that 
you really don't want polkit installed at all?


If you don't mind having polkit installed and configured (doesn't have 
to run all the time) then running dbus-send as above will just work as 
you want (no need to run it via a pkexec wrapper). That's literally the 
job of polkit - to allow certain privileged operations to users.


If this isn't what you want you'll need to write your own suid wrapper 
binary that calls the commands for you.


Col

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

[Colin Guthrie]

Mitchel Humpherys wrote on 26/10/2021 21:16:
On my Manjaro and Ubuntu systems I'm not seeing all of the "pizza" lines 
(logs pasted here [3]). On Debian I see the "pizza" and "pie" lines 
interleaved as expected. It also works as expected when I run the script 
without systemd on Manjaro.


Any ideas what's going on here? Why am I not seeing all of the output 
from `tee' on some systems?


[2] https://github.com/mgalgs/systemd-tee-output-issue 


Looking at the output there, the only thing I can see that's slightly 
odd is that the "pie" output comes from the service's main pid (as 
expected) but as tee is forked off the output there that *is* captured 
is from a different pid each time.


So I wonder if this is some kind of cgroup race thing? i.e. the forked 
off process is not (always) detected as being part of the unit in 
question and thus isn't logged against the unit? If this is the case is 
the a bash trick you can use to buffer the output back to the parent 
process - e.g. just surrounding the command in parenthesis or something? 
(I'm not a bash expert so no idea if this would work as a workaround!). 
Appreciate any code change to work around this isn't ideal anyway, but 
just trying to help debug the underlying problem.


This is just a random guess and might not at all be how the logging or 
cgroup handing works!


Col

--

Colin Guthrie

Re: [systemd-devel] [systemd]: How to set systemd not to generate loop0.device and mtdblockx.device?

[Colin Guthrie]

Hi,

www wrote on 09/10/2021 04:27:
In our system, the whole machine starts too slowly. We want to do some 
optimization. I found that two services( *loop0.device and 
mtdblock5.device*) started slowly. I want to remove them (I personally 
think our system are not need them). I want to ask you how to avoid 
generating these two device files and not start them?


I am looking forward to your reply.


Something in your configuration will be causing them to be mounted. 
Likely something in fstab or a mount unit etc.


These are super generic devices so it's impossible to say how to stop it 
happening with out knowing the configuration that triggers it. Of course 
if you know that config, then you can fix the issue!


If it's in fstab but not "essential" for boot but still desirable, 
consider adding e.g. nowait or similar as a mount option.


Col

Re: [systemd-devel] fstab automount of a mdns samba share

[Colin Guthrie]

Julian Sikorski wrote on 28/09/2021 07:37:

W dniu 27.09.2021 o 16:38, François Cami pisze:

Hi,

On Mon, Sep 27, 2021 at 4:05 PM Julian Sikorski  
wrote:


Hi list,

I am trying to set up an automount of my samba share. It works when I go
by the IP address, i.e.

//192.168.0.220/julian /mnt/openmediavault    cifs
credentials=/home/julas/.credentials,uid=julas,gid=julas,vers=3.1.1,nobrl,auto 


0 0


If this is in fstab, it's different from autofs/automount.
Try adding _netdev to mount options.

François


Yes, this is in fstab. _netdev has helped, thanks! Would you mind 
explaining why it was not required when the IP address was being used? 
Network is needed either way.


I suspect it's just a race condition related to timeouts etc. Perhaps 
the retry/timeout logic of mounting via IP is better than name lookup 
timeouts etc.


_netdev is definitely the right fix here but depending on the 
portability of the machine (i.e. if it's a laptop) you may also want to 
look at x-systemd.automount option too to make it mount the path only 
when you try to access it rather than at boot. If not automount, then 
perhaps "x-systemd.mount-timeout=infinity,retry=" is also useful to 
make things more robust (although I'm not sure how these work with cifs).


See man systemd.mount for some more info.

HTHs

Col




--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] when mount is delayed - start unit which depends on it - ?

[Colin Guthrie]

Mantas Mikulėnas wrote on 18/09/2021 09:41:


On Fri, Sep 17, 2021 at 2:40 PM lejeczek <mailto:pelj...@yahoo.co.uk>> wrote:


Hi guys.

I'm trying to have unit to start...
well,
I have a luks device which waits for manual passphrase
input, when that happens 'systemd' mounts, without user
intervention(which is great), that luks device.
fstab:
/dev/mapper/luks.devs /devs   ext4
noatime,nobarrier,noatime,x-systemd.device-timeout=2,nofail 1 2
and now I'll have many units/services which depend on that
mount, because they need to get to paths to get their
configs & other bits.

Question - how do I make such a unit to re/start when
'systemd' does the mount? Naturally, ideally without any
ways external to 'systemd'.


If units need this mount, then *actually* make them depend on this mount 
– as in, "Requires=devs.mount" and "After=devs.mount" in each service's 
[Unit].


I agree this is correct, but I don't think it does what the user wants. 
i.e. when the mount eventually happens (e.g. after all the jobs have 
timed out and the user manually mounts it), the rest of the transaction 
continues where it left off rather than just sitting their failed/unstarted.


I think there is possibly something you could do with a udev rule, a 
custom target unit and PartOf= in the dependant services?


Or perhaps a path unit based on a file inside the mounted filesystem 
which again triggers a target (again coupled with PartOf in the 
dependant services).



HTHs


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] Xorg or Wayland Environment

[Colin Guthrie]

Ed Greshko wrote on 19/09/2021 12:11:

OK..

I think I see the problem now.  I don't need Environment=.  But the 
issue is that, I assumed, "plasma-core.target" would be

reached only after a user logged in to plasma.

I was wrong and the user's service is run earlier when the login screen 
appears.


I'm slightly confused by the logic here. Why is a user's systemd even 
running before they've logged in? If the user has lingering enabled, 
then it might have a systemd instance from that, but it certainly 
shouldn't reach any plasma-core.target as the login GUI should be 
running as a different user to your user I would have thought?


e.g. under gnome, the login GUI runs as the "gdm" user. That user has a 
systemd --user instance, and runs various things but only once a real 
user has logged in will it's own systemd instance start and reach the 
appropriate targets.


I need to find a way such that the service only runs when a user logs on 
to the plasma GUI.


It seems a bit odd to me that your users' plasma-core.target has been 
run when your user hasn't even logged in yet. I think something is odd 
there, possible combined with user lingering and perhaps plasma-core 
being the default target for your user when it shouldn't be...


Hope this helps you debug things.

Col




--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] mkosi: rpm using host machine's users/groups

[Colin Guthrie]

Colin Guthrie wrote on 01/09/2021 14:40:

Colin Guthrie wrote on 01/09/2021 14:30:

   rpm -qa | xargs rpm --setugids >/dev/null 2>&1


Correction: --restore is actually needed over --setugids as although 
only the latter is strictly needed, it seems without the former the 
setuid bits on e.g. /usr/bin/su etc are also reset, so --restore is the 
required option to not break things in different ways! Sadly it's even 
slower than --setugids (takes almost twice as long)




To get a little more exposure on this issue, I've opened 
https://github.com/systemd/mkosi/issues/805


Cheers

Col

Re: [systemd-devel] systemd | Requires statement with an instantiated service

[Colin Guthrie]

Leon Fauster wrote on 02/09/2021 15:39:

On 02.09.21 15:12, Andrei Borzenkov wrote:

On 02.09.2021 15:10, Leon Fauster wrote:

On 02.09.21 08:00, Andrei Borzenkov wrote:

On 02.09.2021 01:19, Leon Fauster wrote:

Example:

a@.service
b.service

a@.service is started as a@host1.service and b.service must be started
after a@host1.service but the unit will be differently parameterized
(depended of the region). So I want to generalize the requires
statement.


If you need to manually instantiate a@.service, you can just as well
manually add necessary Requires at the same time. E.g.

a@.service:

[Install]
RequiredBy=b.service

systemctl enable a@your-region.service




Indeed that was also what I tried but it seems that my problem is
that b.service needs a device from a.service, and that seems to need
some time to come up. Systemd is here to "fast". Just for the sake


It has nothing to do with being fast. Either a@.service should not
complete activation until device became available or you are solving the
wrong problem, because you actually want to order b.service against
device, not some random service.


of progress I implemented a workaround,

b.service.d/dep.conf
[Service]
ExecStartPre=/bin/sleep 3



I lost you here. If device appears as result of ExecStart in a.service,
no amount of delay *before* ExecStart is going to change anything. If
device appears independently of a.service, you are again solving the
wrong problem.



Let me rephrase it: "a" starts and systemd goes on and starts "b".
The "a" has Type=notify. My understanding (I'm not a systemd dev)
is that "a" completes from the point of systemd, therefore "b" is then
started. But the actual implementation of "b" needs a resource (device)
of "a" that obviously is not there when "b" is started.
So, "ExecStartPre=/bin/sleep 3" in b.service forces a pause and after
this pause the resource of "a" is available and "b" starts successfully.

I'm sure that this could be solved differently with all participating
components but in real world the human resources are limited and the
budget of the customer as well. ExecStartPre solves our problem and
some testing shows that different scenarios are covered as well. When
I find time I will take a closer look at the components especially the 
"Type=notify" entry ...


Indeed. The correct way to solve this is to make "a" only notify that it 
has completed starting up when it's finished creating everything that 
any dependant service will need. This includes opening and listening on 
any sockets or creating any devices etc.


Ultimately the problem here is "a" is notifying too early.

Whether you solve this properly (i.e. fix "a") or with some duct tape 
and good will (i.e. a sleep 3 in "b") is up to you :-)



Cheers

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] mkosi: rpm using host machine's users/groups

[Colin Guthrie]

Colin Guthrie wrote on 01/09/2021 14:30:

   rpm -qa | xargs rpm --setugids >/dev/null 2>&1


Correction: --restore is actually needed over --setugids as although 
only the latter is strictly needed, it seems without the former the 
setuid bits on e.g. /usr/bin/su etc are also reset, so --restore is the 
required option to not break things in different ways! Sadly it's even 
slower than --setugids (takes almost twice as long)


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

[systemd-devel] mkosi: rpm using host machine's users/groups

[Colin Guthrie]

Hi,

So I didn't appreciate this before, but it seems a long standing RPM 
issue where, when using --root the packages will be installed with the 
uid/gid mappings from the host machine rather than the passwd/group 
files from the root.


This makes for a problem using mkosi as it doesn't make the builds 
repeatable and very much dependant on the host machine.


For now, I've added the following to my mkosi.postinst:

  rpm -qa | xargs rpm --setugids >/dev/null 2>&1

(for an RPM based target distro this is fine, but obviously others will 
presumably have similar commands).


This, however, isn't cheap. It takes ~1 minute on a small package list 
on my semi-recent SSD laptop. That's pretty much the same time it takes 
to install the packages in the first place.


So my question is, is there a better work around for this?

Upstream RPM issue:
https://github.com/rpm-software-management/rpm/issues/882

While I don't think it helps, the user namespaces may be a useful work 
around (e.g. semi related to 
https://github.com/systemd/mkosi/issues/716) but I think the real fix is 
likely in glibc/rpm.


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount

[Colin Guthrie]

Andrei Borzenkov wrote on 25/08/2021 13:44:

On Wed, Aug 25, 2021 at 2:26 PM Manuel Wagesreither  wrote:


Hello all,

this is my first post on this mailing list and, first of all, I'd like to thank 
you and appreciate your work on systemd in general. I admire the logic, the 
completeness of the manpages and in general how beautifully things are 
engineered. I'm no unix graybeard and systemd saved me from having to learn all 
that legacy stuff systemd replaces. Compared to fstab, /etc/network/interfaces 
and init.d, systemd is a piece of art.

---

I'm working on an embedded device which should access and scan connected usb 
drives for certain files. I seem to witness a race condition with my current 
solution. I would ask for advice on how to implement this functionality in a 
better way.

When a device /dev/sdb1 is connected, the udev rule below starts BOTH
* a systemd-service "start-standalone-mender-deployment@media-sdb1.service"
* `systemd-mount --no-block --automount=no --options=ro --collect /dev/sdb1 
/media/sdb1`

The service then starts a shell script accessing the usb drive. Occasionally, 
it says the directory the usb drive is mounted at is empty. When checking 
manually, I see it's not. I strongly suspect the script accessed the directory 
before the usb drive got mounted there.

Here's the udev rule:
```
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*", ENV{ID_FS_USAGE}=="filesystem", 
TAG+="systemd", ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service", RUN{program}+="/usr/bin/systemd-mount 
--no-block --automount=no --options=ro --collect $devnode /media/$name"
```

And here's the systemd service:
It is templated and gets instantiated with "media-sdb1". It therefore has an 
"After=media-sdb1.mount". I suspect Systemd-udevd executes the ENV{SYSTEMD_WANTS} part before the 
RUN{program} part. Hence, "media-sdb1.mount" doesn't yet exist when the service gets started, as it 
gets created a tad later by systemd-mount.

```
[Unit]
Description=Start standalone Mender deployment (%i)
After=%i.mount

[Service]
Type=oneshot
Restart=no
ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
```

Can you confirm my theory?



This sounds reasonable. Yet again the same confusion - dependencies
are between jobs. "After=%i.mount" actually means "wait until start
job for %i.mount completes before selecting start job for your unit".
If the start job for your unit happens to be selected for execution
before the start job for %i.mount was queued (it is quite possible as
systemd-mount invocation takes time), there is no start job to wait
for and After becomes noop.


The only alternative I see is to invoke systemd-mount without --no-block from 
the shell script itself. Instead of communicating the mount point (media-sdb1) 
via unit template parameter, I would communicate the device path (/dev/sdb1) to 
the template unit and pass it on to the shell script, which would determine 
mount point based on that.



Yes, there is no nice solution. Systemd was not designed for dynamic
dependencies like in your case. While it is possible to add
Wants=%i.mount to your unit, there is no guarantee that this unit
definition will be present (due to the same race condition).

Sometimes in this case a unit definition file is created and
"systemctl daemon-reload" is invoked. This has its own can of worms so
can hardly be recommended.

So your approach is probably the most practical one.

Hmm ... if systemd-mount --property accepts Wants and Before, your
mount unit could pull in your service unit. I cannot test right now.



Not sure how well it works when mount points are involved but would a 
.path unit work here?


e.g. move the start of the 
start-standalone-mender-deployment@media-sdb1.service out of the udev 
rule and instead worry about the mount path, not the device name?


So the udev rule just worries about mounting, then the path unit 
triggers the start of the mender deployment?


Just a thought and not 100% how well it works with mount points as I 
said as I've really not played much with them.


Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

[Colin Guthrie]

Hiya,

As has been said, this is racy. "Sufficiently early" is just a hope, 
rather than a guarantee. Perhaps something in the kernel made things 
more or less efficient (try booting with the old kernel to see if it 
helps, but as this is a race, it may only work some of the time.). Or 
perhaps some unit ordering changed so make this better? Perhaps udev 
settle units have now been dropped and thus the boot is faster and 
things happen in a more hotplug oriented way? Lot's of possibilities for 
why this no longer works (and even before it definitely wasn't a 
guaranteed or recommended approach).


As has been said, you're best to pick a different "namespace" lan0 wan0 
wan1 etc. if you can but if you can't change this due to some legacy 
scripts, at least pick sufficiently high ethN numbers to stay out of the 
way of the kernel, e.g. if you have three eth cards, then pick your 
names starting from e.g. 5: eth5, eth6, eth7 and thus you can avoid this 
dance with temporary names (although I'd still recommend using different 
names altogether if you can).


Hope that helps.

Col

Amish wrote on 16/08/2021 13:38:


On 16/08/21 5:39 pm, Lennart Poettering wrote:

On Mo, 16.08.21 17:31, Amish (anon.am...@gmail.com) wrote:


On 16/08/21 5:25 pm, Lennart Poettering wrote:

On Mo, 16.08.21 16:09, Amish (anon.am...@gmail.com) wrote:


Some old scripts that we have expect interface names starting with eth. But
those names are not predictable.

So to get predictable names starting with eth*, first I temporarily rename
all interface with tmpeth*. This is done via udev rules.

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
NAME="tmpeth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
NAME="tmpeth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:ZZ",
NAME="tmpeth2"

Then I have a small service (script) which runs before network-pre.target to
convert these names back to eth*

#search for network interface with name starting from "tmpeth" and rename
them to "eth"
/usr/bin/find /sys/class/net -maxdepth 1 -name "tmpeth[0-9]" -type l -printf
"%f\n" | while read tmpiface; do /usr/bin/ip link set dev "$tmpiface" name
"$(echo $tmpiface | sed s/tmpeth/eth/)"; done

This ensures that I have predictable names starting with eth*. And it is
working fine from 2-3 years. Even with current issue, name assignment is
working fine.

This cannot work and is necesarily race. Stay out of the ethXYZ
namespace, that's the kernel's namespace. Pick any other names,
i.e. "foobar0", "foobar1", but otherwise you just have a racy racy
mess, because the kernel might take the name whenever it pleases.

No I dont think this is race. Because my script runs after Udev has finished
assigning the interfaces names.

device probing can take any time it wants. there isn't a point in time
where everything is probed.


These are internal PCI LAN cards. I believe these gets probed (and 
named) sufficiently early.


And then we can expect names assigned by Udev to remain same.

And I can see in the logs that names are not changed after my script runs.

Also this has been working successfully for me from 2 or more years.

But after today's update, something is breaking all the systems.

Additionally just now on other system I see eth2 (instead of eth1) being 
renamed to eth0.


I just want to know what changed and where? (Kernel or Systemd?).

*Also another point is, I have set ConfigureWithoutCarrier=yes in 
network files and all are static IPs, so systemd-networkd should have 
configured the devices even if links are not up. But its not doing that 
anymore either after today's update.*


Regards

Amish.


Lennart

--
Lennart Poettering, Berlin



--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

[systemd-devel] systemd on RHEL 8/CentOS 8 adding leading / to mount What= values

[Colin Guthrie]

Hi all,

I've been running happily on CentOS 8.3 for a while but did an update 
recently to 8.4 and systemd-239-45.el8_4.1.x86_64 (old version but with 
a ton of backports as I'm sure you know/can imagine)


Since then my mount units for VirtualBox Shared Folders stopped working.

I traced this down to the fact that when "mount" is eventually called, 
the What= value specified in the mount unit has been mangled to add a 
preceding /


e.g. my mount unit is:

[Unit]

Before=local-fs.target



[Mount]

Where=/SharedFolderName
What=SharedFolderName
Type=vboxsf



[Install]

WantedBy=local-fs.target




The mount command that is eventually called is:

  mount /SharedFolderName /SharedFolderName -o rw

whereas it *should* be:

  mount SharedFolderName /SharedFolderName -o rw


Does anyone recall if this is a known bug that has occurred at some 
point and the RHEL systemd maintainers need to also backport it's fix? 
Or is it perhaps a bug in libmount? If anyone has any recollection that 
would be ace.


Also if it is a systemd bug and a backport is needed, can I make a 
friendly request to any RHEL systemd maintainers reading this to also 
include the fix for https://github.com/systemd/systemd/issues/10526 so I 
can use squashfs container images in my dev setup. Would be much 
appreciated :-)


Cheers

Col







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

Re: [systemd-devel] Only start a tomcat server when you are sure that time-sync.target is online

[Colin Guthrie]

Jan Hugo Prins wrote on 25/03/2021 14:11:

Hi,


> Does systemd give me a different way to check if the time is in sync?
> Is there a way to create this dependency without implying a restart when
> ntpd restarts?
https://unix.stackexchange.com/questions/388586/systemd-requires-vs-wants 



just replace "Requires" with "Wants", it does exactly the same but your
Tomcat would also get started if "time-sync.target" is missing *but* it
would not be stopped just because ntpd is stopped

there are really very few cases when Requires is really what someone wants


We first tried it with wants, but wants does start the application 
server even if the time-sync.target does not work.


 From the man page:
    Units listed in this option will be started if the 
configuring unit is. *However, if the listed units fail to start or 
cannot be added to the**
**   transaction, this has no impact on the validity of the 
transaction as a whole*, and this unit will still be started. This is 
the recommended
    way to hook the start-up of one unit to the start-up of 
another unit.


We don't want tomcat to start when time-sync doesn't succeed, but when 
ntpd restarts it should not influence tomcat.


How about using Wants as Reindl suggests, but also adding an:

ExecStartPre=systemctl is-active -q time-sync.target

Or something similar which ensures that ntp has run and is working. e.g. 
you may want to ensure that whatever you run here waits a bit after NTP 
started to ensure stabilisation of the time if drift compensation takes 
a little time to sync up )or however that works). Essentially a bit like 
networkd-wait-online where the network can be physically connected (cf. 
ntp started) but nothing is routable yet (cf. clock not yet actually 
sync'ed)


This approach is such that way you get the failure when starting the 
service, but it won't affect runtime ongoing.


Just a thought.

Col

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

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

[Colin Guthrie]

Phillip Susi wrote on 11/02/2021 16:29:


Colin Guthrie writes:


Are those journal files suffixed with a ~. Only ~ suffixed journals
represent a dirty journal file (i.e. from an unexpected shutdown).


Nope.


Journals rotate for other reason too (e.g. user request, overall space
requirements etc.) which might explain this wasted space?


I've made no requests to rotate and config is default, which afaics
means only rotate when the log hits max size of 128MB.  Thus I wouldn't
expect to really see any holes in the log, especially in the middle.


I think the defaults are more complex than just "each journal file can 
grow to 128M" no?


I mean there is SystemMaxUse= which defaults to 10% of the partition on 
which journal files live (this is for all journal files, not just the 
SystemMaxFileSize= which refers to just one file).


The default semantics are described in man journald.conf(5)

Again, could be a red herring, so just my first thought.

Col



--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

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

[Colin Guthrie]

Phillip Susi wrote on 11/02/2021 14:19:

Looking at the archived journals though, I wonder why am I seeing so
many unwritten areas?  Just the last extent of this file has nearly 4 mb
that were never written to.  This system has never had an unexpected
shutdown.  Attached is the extent map.


Are those journal files suffixed with a ~. Only ~ suffixed journals 
represent a dirty journal file (i.e. from an unexpected shutdown).


Journals rotate for other reason too (e.g. user request, overall space 
requirements etc.) which might explain this wasted space?


Just a thought.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] service kills application differently on shutdown vs on stop

[Colin Guthrie]

John wrote on 14/12/2020 12:52:
> Note that it looks
> like I will need to add some udev rules to allow the kodi user to
> shutdown the system which it could do when the PAMName=login was
> present.

Just a small hint, but it might be policykit rules you need to add
rather than udev rules.

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

Re: [systemd-devel] mkosi question: third party repos + dnf modules

[Colin Guthrie]

Hi Daan,

Daan De Meyer wrote on 07/12/2020 20:41:
> --repositories in mkosi is currently a bit limited. For Fedora and
> CentOS, we only support passing names of existing repositories that
> should be enabled. https://github.com/systemd/mkosi/issues/536
> reported a similar problem. We should definitely make this work better
> than it does now but it's going to require a bit of thinking on how to
> properly support this in a way that works for all major supported
> distros. For now, I think postinst is the best solution.

Thanks for the pointer to the issue. At least I'm not going insane.

I suspect supporting the modules system in DNF would be a bit tricky
too, so I'm happy enough going with an mkosi.prepare script for now.

Slightly annoyingly it means I have to actually install dnf and it's
deps inside the container built to run that, but I can always remove it
again after.

Have subscribed to the issue.

Cheers

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] mkosi question: third party repos + dnf modules

[Colin Guthrie]

Reindl Harald wrote on 07/12/2020 21:34:
> and how is that systemd relevant at all?

https://github.com/systemd/mkosi

   ^^^

Maybe that bit? The fact that mkosi is a systemd project?

If you don't have anything positive to add, it's a lot less effort to just do 
nothing!

Col

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

Re: [systemd-devel] Help with Systemd + Apache 2.4 - CentOS 7

[Colin Guthrie]

Lucas Possamai wrote on 23/11/2020 21:57:
> I don't find any extra info in the Apache Logs. The attached error message
> is the only log I can see.

You will get more info by running e.g. systemctl status httpd.

As others have hinted at, if the systemd unit for httpd is using
Type=notify, you must make sure that the mod_systemd httpd module is
loaded and installed (it should be installed).

If this is the cause, you should see appropriate error messages in the
status output from above and the start command should take some time to
fail (usually a timeout of 1.5minutes or so.

On CentOS 7 this configuration is from
/etc/httpd/conf.modules.d/00-systemd.conf so perhaps double check you've
not disabled this configuration somehow with your setup?

Also, make sure that you've not manually started apache outside of
systemd. If it's running already (but not managed by systemd) systemd
will try and start it again, but won't be able to as the bound TCP ports
are already grabbed by the other instance.

Anyway, it'll take more info for someone to help you but it's very much
a configuration/usage issue rather than a fundamental systemd bug or
problem.

Good luck.

Col


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

Re: [systemd-devel] Workaround for system upgrade bug suggestions

[Colin Guthrie]

Barry wrote on 02/11/2020 22:20:
> What is the work around until the bug is fixed?

I'd imagine you could just disable lingering for the users in question
before running the dnf upgrade command? Not ideal but it's a workaround
as you asked!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] systemctl reboot/halt with non-privilege user

[Colin Guthrie]

Hello,

An Liu wrote on 28/10/2020 11:40:
> Hi, folks, 
> 
> I used to type systemctl reboot with non-privileged users, and to my
> surprise, the system goes down for the reboot. 
> 
> I've tested in both debian and centos 7, they act the same, however,
> systemctl halt will prompt you to enter administrator password to continue. 
> 
> Is it default behavior by design? I dont think a non-privileged user
> could reboot the system as he/she wishes. 
> 
> btw, I'm in an HPC related domain, if this behavior of systemctl is
> allowed, every single user could reboot the whole cluster as they wish,
> it's a disaster. 

It really depends on the policykit setup.

e.g. if the user is in the wheel group, they may have additional
privileges by virtue of that.

On my systems (centos 8 here) policykit will prompt for the root password:


[user@host ~]$ systemctl poweroff

 AUTHENTICATING FOR org.freedesktop.login1.set-wall-message 

Authentication is required to set a wall message

Authenticating as: root

Password:



I can't recall off hand, but if the user was in the wheel group, then I
think it would still prompt for a password, but would ask for the user
password.


These are via SSH, but policykit also has overrides for users logged in
locally. As these guys have physical access to the machine, they might
be allowed to do certain things, like reboot etc. as they have access to
the plug anyway, it's not really any additional security concern.

So, ultimately, my advice is to check your policykit setup and see what
the policy is.


Col

PS, I did spot an awesome security bug in an old redhat security tool a
few years back (I think it was called sectool) which installed a bogus
policy file which basically gave users full rights to things like
service management and reboot etc, so it's possible a rogue/buggy policy
file from an unrelated package is causing this behaviour too.




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
https://colin.guthr.ie/

Day Job:
  Tribalogic Limited https://www.tribalogic.net/


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

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

[Colin Guthrie]

Alvin Šipraga wrote on 08/09/2020 22:54:
> Hi,
>
> On 9/8/20 4:12 PM, Colin Guthrie wrote:
>
>> 2. Set your /etc/ master image to make /etc/localtime to be a symlink to
>> /run/localtime and then ensure /run/localtime is a symlink to the
>> appropriate file in /usr during early boot (e.g. in initramfs). Then
>> when you want to to change the timezone, just update the /run/ symlink.
> This might not work as expected - systemd sometimes assumes that
> /etc/localtime is a symlink into /usr/share/zoneinfo and will not
> understand double symlinks. See src/basic/time-util.c:get_timezone() for
> at least one example.

But that really depends on what you define as "not work". Sure
timedatectl may not report correctly, but that shouldn't matter too much
if you're not using to query or update (the latter obviously won't work
anyway), but for the purposes of software *using* the timezone, I don't
tihnk anything will actually break.

Just my take on it, and could indeed be wrong. Just seems like a lot of
discussion over quite a minor point! :-)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/


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

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

[Colin Guthrie]

e, please notify the sender immediately and do not
> > disclose the contents to anyone or make copies thereof.
> >
> >
> > On Fri, Sep 4, 2020 at 6:16 PM Shravan Singh
> mailto:shra...@bluesparq.com>> wrote:
> >
> >> What constitutes a configuration?
> >> And please read my email subject. I can't have writable /etc, mender
> >> dosen't allow that.
> >>
> >> In today's mobile computing age you really think users shouldn't
> change
> >> timezone?
> >> You keep saying " I for one am certainly not convinced that the
> timezones"
> >> but you don't explain why?
> >> Are you looking at this system as a static machine? That can
> never change
> >> timezone?
> >>
> >> And please don't use profanity. I have not and you shouldn't either.
> >>
> >> Regards,
> >> Shravan Singh
> >> (239) 243-0838
> >>
> >> Blue Sparq, Inc.
> >> 928 NE 24th Lane unit 4 and 5.
> >> Cape Coral, FL 33993
> >>
> >> IMPORTANT: The contents of this email and any attachments are
> >> confidential. They are intended for the named recipient(s) only.
> If you
> >> have received this email by mistake, please notify the sender
> immediately
> >> and do not disclose the contents to anyone or make copies thereof.
> >>
> >>
> >> On Fri, Sep 4, 2020 at 6:05 PM Lennart Poettering
> mailto:lenn...@poettering.net>>
> >> wrote:
> >>
> >>> On Fr, 04.09.20 15:54, Shravan Singh (shra...@bluesparq.com
> <mailto:shra...@bluesparq.com>) wrote:
> >>>
> >>> > Yes, But help me understand.
> >>> > I think you said that you are not convinced as to why that has
> to done.
> >>> >
> >>> > My argument is very simple shouldn't a Linux environment allow
> change in
> >>> > timezone easily?
> >>>
> >>> Oh we do. But if your want configuration to be changable, then mount
> >>> /etc writable.
> >>>
> >>> You have two contradicting goals: you want immutable config, but
> then
> >>> you want to change config. So how's that gonna work?
> >>>
> >>> If you want your persistent config changable then make it changable,
> >>> i.e. mount /etc/ writable.
> >>>
> >>> > Now I am not an expert in Linux kernel development. But I see
> that some
> >>> of
> >>> > the files, even though they reside in /etc  are linked to file
> in /run
> >>> > Like *resolv.conf.  *Which allows dynamic changes.
> >>>
> >>> I explained this already. DNS server data today is much less config
> >>> than state, acquired dynamically via DHCP, hence most distros don#t
> >>> configure it in /etc so much anymore, but manage it in /run (where
> >>> transient state is generally kept), and only keep a compat
> symlink in
> >>> /etc. If you try to convince people though that the local timezone
> >>> should just be transient state and not persistent config you'll
> have a
> >>> hard time. I for one am certainly not convinced that the
> timezones are
> >>> state...
> >>>
> >>> I mean, the line between persistent configuration and transient
> state
> >>> is blurry, but in the case of DNS settings and timezone settings I
> >>> certainly can draw a line easily.
> >>>
> >>> > timezone activity change is a very basic change one that needs
> to be
> >>> > supported by the system. Why guard it with so much.
> >>>
> >>> We don't do that. Just make /etc/ writable ffs, if you want stuff in
> >>> /etc to be changable.
> >>>
> >>> Lennart
> >>>
> >>> --
> >>> Lennart Poettering, Berlin
> >>>
> >>
> 
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shutdown order in systemd

[Colin Guthrie]

Just FYI and for the sake of cross referencing, the inhibition logic was
mentioned on the list today in a thread: "systemd-inhibit don't work".

A developer says he will work on the patch for this RFE shortly.

Col

Zheng SHAO wrote on 04/08/2020 13:39:
> Hello,
>
> First thanks for your advise.
>
> I didn’t know inhibit before, today I read the document
> and did few simple tests, here is one of these.
>
> $ sudo systemd-inhibit --what=shutdown --who=graceful-shutdown
> --why="Keep application working" --mode=“block” /bin/sleep 60
>
> Unfortunately once ACPI G2 soft off signal comes, the system begin to
> shutdown immediately, I’m still figuring out why systemd-inhibit did
> not block the shutdown process.
>
> At the same time, I found an interesting project which try to block
> shutdown completely.
> https://github.com/ryran/reboot-guard
>
> Thanks!
>
>> On Aug 4, 2020, at 4:01, Colin Guthrie > <mailto:gm...@colin.guthr.ie>> wrote:
>>
>> Zheng SHAO wrote on 03/08/2020 13:31:
>>> Hello,
>>>
>>> We are finding a robust way to handle ACPI G2 soft off signal to
>>> graceful shutdown our application.
>>> To simplifier the problem, consider our instance is running with
>>> Nginx behind a load balancer.
>>> When the ACPI G2 soft off signal comes to the Nginx instance, we
>>> want to do these jobs
>>>
>>> 1. Keep current HTTP connection works.
>>> 2. Fail the health check in load balance side.
>>> 3. Make sure new connection not comes from load balancer.
>>> 4. Kill long connections if any connection exceeds to 60 seconds.
>>> 5. Continue shutdown process.
>>>
>>> We are considering to achieve this by 2 options,
>>> 1. Add a custom handler for `HandlePowerKey` in
>>> /etc/systemd/logind.conf.
>>> 2. Add a system service so when systemd starting shutdown, this
>>> service will be run first and block other service to be killed.
>>
>> Have you considered writing a service that takes a systemd-inhibit
>> shutdown lock?
>>
>> This might not work but looking very quickly at
>> https://www.freedesktop.org/wiki/Software/systemd/inhibit/ it would
>> appear you get a PrepareForShutdown signal which could kick off your
>> steps.
>>
>> Depending on how things work, you could just introduce a "delay" inhibit
>> rather than a "block", e.g. a 70s delay could give you a bit of headroom
>> to trigger fail the LB's health check.
>>
>> Or perhaps you could take a block lock, then when the
>> prepareForShutdown() signal comes in, fail the LB, then when that is
>> confirmed, add a new 60s delay inhibit (not sure if this works after
>> shutdown has been triggered), then release the block inhibit and just
>> wait for everything else to run it's course? Alternatively just keep the
>> block inhibit right up until you want step 5 to begin.
>>
>> Again, this is pure speculation and the default handler for
>> HandlePowerKey may bypass login (tho' I suspect not) and others may
>> explain other reasons why this approach may not work.
>>
>> Good luck
>>
>> Col
>>
>>
>>> The method[2] is a preferred way, but we can not find a correct
>>> implement for this.
>>>
>>> ```
>>> [Unit]
>>> Description=Delay shutdown
>>> After=network-online.target network.target rsyslog.service
>>> After=google-instance-setup.service google-network-daemon.service
>>> After=systemd-user-sessions.service sshd.service
>>> google-fluentd.service user.slice system.slice
>>> nss-user-lookup.target logind.service
>>> Wants=network-online.target network.target rsyslog.service
>>> google-instance-setup.service google-network-daemon.service
>>> systemd-user-sessions.service sshd.service google-fluentd.service
>>> user.slice system.slice multi-user.target nss-user-lookup.target
>>> logind.service
>>>
>>> [Service]
>>> Type=oneshot
>>> ExecStart=/bin/true
>>> ExecStop=/root/shutdown.sh
>>> RemainAfterExit=yes
>>> KillMode=none
>>> TimeoutStopSec=0
>>> StandardOutput=journal+console
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>> ```
>>>
>>> /root/shutdown.sh
>>> ```
>>> #!/bin/bash
>>>
>>> echo start shutdown
>>> echo sleep 300
>>> sleep 300
>>> echo end shutdown
>>> ```
>>>
>>> We checked console output shows as follow,
>>> 

Re: [systemd-devel] Shutdown order in systemd

[Colin Guthrie]

.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Aug  3 21:23:09 
> shao-redis-prd-base systemd: Stopped ACPI Event Daemon.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Authorization Manager.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Job spooling tools.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Getty on tty1.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Serial Getty on ttyS0.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped NTP client/server.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Google OSConfig Agent.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Command Scheduler.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Unbound recursive Domain 
> Name Server.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Removed slice 
> system-serial\x2dgetty.slice.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Starting Show Plymouth Power Off 
> Screen...
> Aug  3 21:23:09 shao-redis-prd-base systemd: Removed slice system-getty.slice.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Session 2 of user kuma.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Removed slice User Slice of kuma.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopping Login Service...
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Login Service.
> [  236.662420] shutdown.sh[1265]: start shutdown
> [  236.662802] shutdown.sh[1265]: sleep 300
> Aug  3 21:23:09 shao-redis-prd-base shutdown.sh: start shutdown
> Aug  3 21:23:09 shao-redis-prd-base shutdown.sh: sleep 300
> Aug  3 21:23:09 shao-redis-prd-base GCEMetadataScripts[1266]: 2020/08/03 
> 21:23:09 GCEMetadataScripts: Starting shutdown scripts (version 20200706.00).
> Aug  3 21:23:09 shao-redis-prd-base GCEMetadataScripts[1266]: 2020/08/03 
> 21:23:09 GCEMetadataScripts: No shutdown scripts to run.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Google Compute Engine 
> Shutdown Scripts.
> Aug  3 21:23:09 shao-redis-prd-base systemd: Received SIGRTMIN+20 from PID 
> 1276 (plymouthd).
> 
> [  OK  ] Started Show Plymouth Power Off Screen.
> 
> Aug  3 21:23:09 shao-redis-prd-base systemd: Started Show Plymouth Power Off 
> Screen.
> 
> [  OK  ] Stopped Dynamic System Tuning Daemon.
> 
> Aug  3 21:23:09 shao-redis-prd-base systemd: Stopped Dynamic System Tuning 
> Daemon.
> ```
> 
> It seems other system services are also start shutdown at same time, is there 
> a better to do this?
> 
> Any advice is welcome.
> 
> Thanks,
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/6] RFC: Initial implementation of mount table handling using libmount kernelwatch

[Colin Guthrie]

Ian Kent wrote on 29/07/2020 01:57:
> On Tue, 2020-07-28 at 16:13 +0200, Lennart Poettering wrote:
>> On Mo, 27.07.20 12:57, Ian Kent (ik...@redhat.com) wrote:
>>
>>> Further to my post about using the new mount table notifications in
>>> systemd I'd like to start by posting a few patches for discussion
>>> to
>>> hopefully get a better understanding of some aspects of how systemd
>>> mount unit state handling works, and also to get guidance on
>>> systemd
>>> coding style, and generally how I should be doing things in systemd
>>> as well as how best to debug problems.
>>
>> Thank you for working on this!
>>
>> We do reviews exclusively on github these days, could you please
>> submit this as PR on github?
> 
> Thanks Lennart, will do.
> 
> Although I was hoping for some generic discussion on this to set
> me going in the right direction.
> 
> If that's not ok then I'll submit a PR when I think it's ready.

Although I'm not as familiar with the development process as I used to
be, you can file it now, even in it's current state for that discussion
process. It can be an RFC Pull request. Just means the discussion can
all take place in Github and can go through various iterations there.

So, in short, don't worry about it being fully "ready" before pushing
and doing a pull requests.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Accpetance of Environment Variables in Attributes

[Colin Guthrie]

Ulrich Windl wrote on 26/06/2020 10:43:
>>>> Roman Odaisky  schrieb am 25.06.2020 um 14:35 in
> Nachricht
> <2175_1593088566_5EF49A35_2175_217_1_5367023.DvuYhMxLoT@xps>:
>>>  [Service]
>>> User=nobody
>>
>> May I interject that DynamicUser=yes is generally superior to User=nobody.
> 
> And I always thought the user is named nobody, because no process ever using
> it (as UID to run with)...
> Using it may have unwanted security implications.

Could be wrong, but I think it's more to do with running *multiple*
unrelated services as nobody. They could, in theory, mess with each
other in some cases (deleting each others temporary files, sockets etc).
 So one dodgy/vulnerable "nobody" service could then interfere with a
more robust "nobody" service just because they are running as the same user.

Running as different users can avoid that vector.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] Issue on Ordering of systemd services during boot

[Colin Guthrie]

I presume B.socket is some kind of network socket rather than filesystem
path? Either that or A.service provides the filesystem for the socket path?

That being the case, you've got an ordering cycle here as B.socket has
WantedBy=sockets.target which is order before multi-user.target which is
needed by A.service.

Take the WantedBy out of the B.socket (and ensure you remove any
symlinks that were created when it was installed/enabled - better to do
"systemctl disable B.socket" before editing the unit!) and replace it
with multi-user.target too (like A.service) and this should remove the
ordering cycle and give more deterministic behaviour.

HTHs

Col


TARANA, YASHASHVI wrote on 10/12/2019 07:07:
> Hi,
> 
>  
> 
> I have a systemd service /A.service/ and socket /B.socket /and its
> corresponding service /B./service with the following content:
> 
>   
> 
>    /A.service/
> 
>   [Unit]
> 
>   Description=A.service
> 
>  
> 
>   [Service]
> 
>   ExecStart=/root/test start
> 
>   RemainAfterExit=true
> 
>       ExecStop=/root/test stop
> 
>   Type=simple
> 
>  
> 
>   [Install]
> 
>   WantedBy=multi-user.target
> 
>  
> 
>    /B.socket/
> 
>   [Unit]
> 
>   Description=B.socket
> 
>   *After=A.service*
> 
> *BindsTo=A.service*
> 
>  
> 
>   [Socket]
> 
>   ListenDatagram=
> 
>   Accept=No
> 
>  
> 
>   [Install]
> 
>   WantedBy=sockets.target
> 
>  
> 
>   
> 
>    /B.service/
> 
>   [Unit]
> 
>   Description=B.service
> 
>   Requires=B.socket
> 
>  
> 
>   [Service]
> 
>   Type=simple
> 
>   ExecStart=/root/test1
> 
>   StandardInput=socket
> 
>  
> 
>   [Install]
> 
>   WantedBy=multi-user.target
> 
>  
> 
>  
> 
> I need /B.socket/ to start only after /A.service/ during boot. However,
> even after setting */After=A.service/*//and */BindsTo=A.service/*//in
> /B.socket/, sometimes /B.socket/ is starting before /A.service/.
> 
>  
> 
> Please let me know if I am missing something.
> 
>  
> 
>  
> 
> Thanks and Regards,
> 
> Yashashvi
> 
>  
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to control the login prompt from my application service unit file?

[Colin Guthrie]

Moji, Shashidhar wrote on 15/10/2019 05:15:
> Hi,
> 
> We have VMware vApp based solution. Our application gets installed
> during first boot.
> 
> Till now we had SLES11 OS based VM and we upgraded to SLES12. Now we
> have systemd instead of init scripts for service handling.
> 
> In SLES11, we had service dependency configured in init scripts that was
> holding back the login prompt until our application installation is
> done. But in SLES12, we get the login prompt before our application is
> installed.
> 
>  
> 
> How to hold the login prompt until our application installation is
> complete? We tried adding /Before=getty@.service/  in our application
> install unit file, but its not helping.
> 
>  
> 
> ~
> 
> [Unit]
> 
> Description=ADG runonce apg_install
> 
> DefaultDependencies=no
> 
> After=local-fs.target network-online.target
> 
> Before=getty@.service
> 
> Wants=network-online.target
> 
> Wants=network-onine.target
> 
>  
> 
> [Service]
> 
> Type=forking
> 
> ExecStartPre=/bin/touch /etc/no-login-console
> 
> ExecStart=/bin/sh -c "/opt/ADG/runonce/scripts/apg_install"
> 
> ExecStartPost=/opt/ADG/runonce/bin/runonce removeflag apg_install
> 
> ExecStartPost=/bin/rm /etc/no-login-console
> 
> KillMode=process
> 
> Restart=no
> 

Just as a slightly different approach, you may want to consider using
pam_nologin instead.

Systemd does it itself (it creates a /run/nologin files using
/usr/lib/tmpfiles.d/systemd-nologin.conf) which prevents login by anyone
other than root.

Systemd user sessions daemon removes the /run/nologin file but I presume
it would be possible to create your own /run/apgnologin file and
configure pam with file=/run/apgnologin file in addition to the default.

You could then create this file with tmpfiles (as systemd does with it's
file) and then remove it with your service.

This doesn't prevent the getty from appearing (and the root user can
still login) but if any user tries to login, the contents of the file
can explain to the user why they cannot login (rather than them just
sitting there with a delay).

Just a thought about an alternative approach that you may want to explore.

Col





-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command

[Colin Guthrie]

Andy Pieters wrote on 08/10/2019 11:41:
> forget about the stop.  that was the context into which I discovered it.
> 
> I am not saying stop should disable I am saying stop should not accept
> now and silently ignore it


FWIW I'd tend to agree with you.


[colin@jimmy Channel (master)]$ sudo systemctl stop --fodslkjsf httpd

systemctl: unrecognized option '--fodslkjsf'

[colin@jimmy Channel (master)]$ sudo systemctl stop --now httpd

[colin@jimmy Channel (master)]$


If --now is irrelevant to the verb, then it should be the equiv of an
unrecognized option.

Bonus points if it issued a git-style "did you mean systemctl disable
--now ..." error response.

Col
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] org.freedesktop.systemd1.manage-units - which unit?

[Colin Guthrie]

Mantas Mikulėnas wrote on 02/10/2019 16:37:
> On Wed, Oct 2, 2019 at 5:58 PM Ian Pilcher  <mailto:arequip...@gmail.com>> wrote:
> 
> On 9/26/19 11:49 AM, Mantas Mikulėnas wrote:
> > In JS-based polkit rules, the action usually comes with 'unit' and
> > 'verb' polkit variables -- according to src/core/dbus-unit.c:
> >
> >      if (action.id <http://action.id> <http://action.id> ==
> > "org.freedesktop.systemd1.manage-unit" && action.lookup("unit") ==
> > "foo.service") { return polkit.Result.YES; }
> >
> > In older polkit versions which use .pkla rules, variables are not
> > available at all.
> 
> They don't seem to be available on CentOS 7, which has systemd 219,
> either (even though it does use JavaScript rules).  :(
> 
> 
> Ah yes, according to NEWS it's a v226 change.

Yeah, in CentOS 7 I had to do something like this:

/etc/polkit-1/rules.d/foo.rules:


polkit.addRule(function(action, subject) {
  if (action.id.indexOf("org.freedesktop.policykit.exec") != 0 ||
subject.user != 'my-permitted-user')
return polkit.Result.NOT_HANDLED;

  var cmd =  action.lookup('command_line').split(' ');
  if (cmd.length == 4 && cmd[0] == '/usr/bin/systemctl' && cmd[1] ==
'start' && cmd[2] == '--no-block' && cmd[3].indexOf('my-template-unit@')
== 0) {
var job = cmd[3].substr(16).split('.')[0];
var valid = /^tl[A-Z][a-zA-Z0-9_]*$/;
if (job.match(valid))
  return polkit.Result.YES;
  }

  return polkit.Result.NOT_HANDLED;
});


Then run I could run:

 pkexec /usr/bin/systemctl start --no-block my-template-unit@whatever

as "my-permitted-user" without any prompt.

It's a nasty work around, but for me it was all wrapped up in a script
rather than manually run, so it didn't matter too much really.

You can adjust that to suit make it more tolerant to other arguments
etc, but it's definitely no where near as nice or elegant as the proper
approach (esp with the pkexec prefix!)

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Colin Guthrie]

Colin Walters wrote on 01/10/2019 20:33:
> On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote:
> 
>> i.e maybe write down a spec, that declares how to store settings
>> shared between host OS, boot loader and early-boot kernel environment
>> on systems that have no EFI NVRAM, and then we can make use of
>> that. i.e. come up with semantics inspired by the boot loader spec for
>> finding the boot partition to use, then define a couple of files in
>> there for these params.
> 
> I like the idea in general but it would mean there's no mechanism to "roll 
> back" to a previous configuration by default, which is a quite important part 
> of OSTree (and other similar systems).   (Relatedly this is also why ostree 
> extends the BLS spec with an atomically-swappable /boot/loader symlink, 
> though I want to get away from that eventually)

Just out of curiosity, when /boot is the EFI (as is recommended in the
BLS) how do you deal with symlinks when the FS is FAT based?


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] systemd prerelease 242-rc4

[Colin Guthrie]

For the casual bystanders, would it be possible to include the git
changelog for the rcN releases (where N > 1 and changelog for (N-1)..N)
or at least a GH link to where such a changelog can be viewed?


It's nice to get a feel for what rc2 fixes on top of rc1 for example.

Just a thought on making the emails a more useful if it's not much
effort from a coding perspective.

Col


systemd tag bot wrote on 09/04/2019 11:10:
> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
> tarball here:
> 
> https://github.com/systemd/systemd/archive/v242-rc4.tar.gz
> 
> NOTE: This is ☠️ pre-release☠️ software. Do not run this on production 
> systems, but please test this and report any issues you find to GitHub:
> 
> https://github.com/systemd/systemd/issues/new?template=Bug_report.md
> 
> Changes since the previous release:


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

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

[Colin Guthrie]

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

As I understand it, you want /var/log to be tmpfs but /var/log/journal
to be persistent (as journald's write behaviour is considerate enough
for you not to worry about backing store fatigue etc)?

Just as a less complex suggestion, you're presumably bootstrapping
/var/log to be on tmpfs at some point in early boot (i.e. before
journald is started or at least before it's being told to start writing
to /var/log/journal). If this is the case, then why don't you just amend
that bootstrapping to bind mount /var/log/journal to persistent storage
rather than letting it be just a subdir on the tmpfs? That way you can
get your mem-only syslog (or native logging) setup as you do now and get
persistent journal logs with only very minor changes (this could all be
done with appropriate systemd units and deps AFAICT).

I can't remember off the top of my head what makes journald start
writing to /var/log/journal, so you

Re: [systemd-devel] How to suppress "A start job is running for offline-updates" knight-rider status output?

[Colin Guthrie]

Hans de Goede wrote on 27/02/2019 19:12:
> On 27-02-19 17:04, Lennart Poettering wrote:
>> Another option is to do this in your soruces btw:
>>
>> ```c
>> (void) kill(1, SIGRTMIN+21);
>> ```
>>
>> Sending SIGRTMIN+21 to PID 1 will disable the status output
>> explicitly. If you are sure you don't want it you can just do that, in
>> one line.
>>
>> Plymouth also sends that signal, hence make sure you don't run into
>> races with that.
> 
> That won't work, the primary use-case for the offline-updates
> status display is a user pressing ESC while plymouth is showing this:
> https://fedorapeople.org/~jwrdegoede/flickerfree-videos/installing.png
> 
> So that the user can see details if he/she wants that. In this case
> plymouth will send SIGRTMIN+22 when switching back to text-mode to
> have systemd resume its status messages, so having pk-offline-update send
> SIGRTMIN+21 when it starts will not help.

Could the plymouth theme somehow suppress the sending of SIGRTMIN+22?
e.g. in the case of the offline updates it's presumably integrating with
the pk-offline-update to get progress reports anyway, so it knows the
context in which it's run. I could simply suppress the sending of
SIGRTMIN+22 and leave just the pk-offline-update messages?

Obviously would need a tweak to plymouth, but perhaps it's not too
crazy? Just a thought.


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fail to load network modules properly

[Colin Guthrie]

Łukasz Słaboń wrote on 28/01/2019 19:23:
> Yes, as far as I know it should load firmware. Is there a possibility to
> force loading wl driver and module only after partition is mounted? I
> assume that something systemd scripts needs to be changed to force
> different boot sequence. 

Firmware is usually stored in the /usr tree. systemd typically requires
that /usr is available from early boot (i.e. before modules are
initialised).

If /usr is a separate partition, it is the job of the initrd to ensure
/usr is mounted prior to pivoting into systemd on the filesystem.

If the module is compiled into the kernel or included in the initrd,
then the firmware file would also typically have to be included in the
initrd too.

dracut takes care of all this for you, not sure about other initrd
generators.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: access to disk devices does not work on centos 7/systemd 219

[Colin Guthrie]

Mailing List SVR wrote on 16/01/2019 21:03:
> Il 16/01/19 19:24, Lennart Poettering ha scritto:
>> On Mi, 16.01.19 09:20, Mailing List SVR (li...@svrinformatica.it) wrote:
>>
>>> Well, this command will make the sd devices readable inside the
>>> container on
>>> centos 7 too
>>>
>>> echo 'b 8:* rw' >
>>> /sys/fs/cgroup/devices/machine.slice/machine-bionic\\x2druntime.scope/devices.allow
>>>
>>>
>>> now I'll will search how to pass to systemd-nspawn using a command line
>>> argument
>> Use --property=DeviceAllow=…
> 
> thanks but this does not seems available in systemd 219, the version
> shipped with centos 7, it fails with unrecognized option error.
> 
> Newer systemd versions work out of the box probably because they have
> DevicePolicy=auto as default,
> 
> so basically I ended up writing a systemd-nspawn wrapper that, launched
> from a systemd service, wait for
> /sys/fs/cgroup/devices/machine.slice/machine-.scope to appear and
> then it sets the required permissions in devices.allow.
> 
> If I use the reboot command inside the container then the cgroup dir is
> recreated and the permissions are lost since my wrapper is not called
> 
> luckily I can control the container and so I changed the reboot command
> so it shutdowns the container instead and I set Restart=always in the
> systemd service so the container is restarted automatically after the
> shutdown,
> 
> so the only way to shutdown the container is using systemctl stop  service> but this is better than nothing,

FWIW (and orthogonal to the actual problem), I think Facebook maintain a
backported systemd package for CentOS 7 that might be worth
investigating. Last time I looked there were still some manual deps you
had to build yourself (or just copy the packages) from Fedora which is a
bit rubbish but not impossible with a bit of jiggery pokery. There is
some degree of confidence that at least the package is used in a "fairly
large" deployment :-p

Worth having a little look over (I haven't had the need yet - like
yourself I've found workarounds for the itches I need to scratch that
are fixed in newer systemds - but may do at some point)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[Colin Guthrie]

Jérémy ROSEN wrote on 16/01/2019 08:24:
> yes... adding a "this is the start of the freeze" tag sounds like a low
> hanging fruit... it's almost no work for the core team to do, and it
> would be a clear signal that the freeze period is starting...
And automated mails to the list when this happens would be nice too, as
some folk will likely still follow the list more than they login to
github (and for those that do login to github they may have many other
projects so it could get lost in the noise)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] Global nspawn container settings

[Colin Guthrie]

Lennart Poettering wrote on 16/10/18 15:23:
> On Di, 16.10.18 14:15, Gervais, Francois (fgerv...@distech-controls.com) 
> wrote:
> 
>> Hi,
>>
>> I saw the .nspawn files which can be used to add settings to a specific 
>> machine.
>>
>> I'd like to know if there is a way to add settings to all machines at once.
>>
>> For example, I'd like all machines to bind-ro my .bashrc so I feel more at 
>> home :) 
> 
> No, this is not available currently. Sorry!

You could presumable add a drop in in
/etc/systemd/system/systemd-nspawn@.service.d/bashrc.conf

which has
ExecStart=
ExecStart=/usr/bin/systemd-nspawn ... --bind-ro=/home/francios/.bashrc

Or something similar?

Sure you'd have to ensure you stay up-to-date with any ExecStart changes
from upstream and it wouldn't apply to any manual call of systemd-nspawn
on the command line, but it would get it for machines started from
template units or via machinectl so may get you most of the way there.

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd behavior during shutdown

[Colin Guthrie]

Tiwari, Hari Sahaya wrote on 19/09/18 06:01:
> Hi,
> 
>  
> 
> I am facing one issue with systemd where systems socket is not opening a
> new connection during shutdown.
> 
> I get below logs,
> 
>  
> 
> Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Incoming traffic
> Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Suppressing connection
> request since unit stop is scheduled.
> 
>  
> 
> I have one systemd service which is trying to open a new connection
> during shutdown sequence but looks like systemd sockets stop accepting
> new connections as soon as they are marked for stop.
> 
> I tried putting various combination of dependencies but that didn’t
> help. Everytime getting the above message.

What dependence did you try?

Ultimately the service attached to this socket should be ordered
"before" the service which is trying to use it. This should mean that
the stop is not performed until after the unit that's using it.

I'm not 100% sure how the socket activation stuff works in this
scenario, but you may need to make sure the service unit of for the
socket is actually started rather than relying on socket activation...

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CPU usage limit to systemd-nspawn container is not working

[Colin Guthrie]

patlollamahi...@yahoo.co.in wrote on 18/07/18 21:04:
> *override.conf* is effective when it is placed in
> */etc/systemd/system/systemd-nspawn@service.d/*

I think you missed a . above:
/etc/systemd/system/systemd-nspawn@.service.d/*

> 
> If I have file
> *systemd-nspawn@appscont.service *in 
> */etc/systemd/system.control/systemd-nspawn@appscont.service.d,
> *it is not effective, it's using the template file.

there is no system.control folder.

You should place a file called override.conf (or anything.conf) in a
folder: /etc/systemd/system/systemd-nspawn@appscont.service.d/ if you
want the overrides defined in the .conf file to only apply to that one
machine.

All the best and HTHs

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Encrypted partitions not decrypted at boot time when using key-file.

[Colin Guthrie]

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).
> #
> #
> /dev/mapper/victor-odos /   ext4errors=remount-ro 0   1
> /dev/mapper/victor-archos /boot   ext2defaults0   2
> /dev/mapper/victor-oikia /home   ext4defaults0   2
> /dev/mapper/victor-trophe /usrext4defaults0   2
> ##
> 
> In that case, I obviously rub out the "noauto" option from the option
> list. No messages are produced. m_passdev is not invoqued.
> 
> This bug does not occur with kernel 3.13.0-106-generic (Ubuntu Trusty)
> xenial kernel is 4.13.0-36-generic.
> 
> Arbiel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd-wait-online should know if there is anything to wait for

[Colin Guthrie]

Dimitri John Ledkov wrote on 26/03/18 11:34:
> Hello,
> 
> When systemd-networkd-wait-online was originally introduced, it was
> the only tool that correctly waited and blocked the boot, until after
> networking is configured.
> 
> These days, however, all/most network configurations tools ship
> appropriate wait-online integration. E.g. there is network-manager
> wait online service and ifupdown wait online, on Debian/Ubuntu.
> 
> These other helpers, seem to be slightly smarter than
> systemd-networkd-wait-online. Specifically, all other helpers exit
> straight away, if they have no devices configured / managed. Whilst
> systemd-networkd-wait-online, doesn't appear to know if it expects any
> devices / can manage any devices. Ideally, if no devices are
> configured / no devices match .network files, maybe it should exit
> straight away? Or for example, do so if no devices are found in
> "configuring/pending/not yet processed by udev".
> 
> (code wise, it is to change one_ready to true by default, and only
> continue blocking the, if there is anything pending configuration).
> 
> I'm considering doing this by default, or for-example, doing it if
> there are no /run/systemd/network/*.network
> /etc/systemd/network/*.network files.
> 
> The use cases when it matters:
> 
> - installer ISO booted without any NICs attached
> (or NICs require special drivers / firmware loaded etc)
> 
> - cloud-image booted and cloud-init failed to find network-config and
> generate networkd stanzas

But how do you differentiate a device which is not present vs. one which
is slow to appear?

If the system isn't online then surely any dependant units don't need to
be started anyway. If the system requires being online to operate
properly then all this behaviour is correct.

If you don't use systemd-networkd then you possibly don't want
systemd-networkd-wait-online either and thus it can be happily disabled.

So I don't really appreciate why this is an issue. Unless, you're trying
to use a kind of hybrid environment (e.g. using networkd for wired
networks (perhaps USB dongles) and NetworkManager for wifi and you'd
want networkd-wait-online to be a no-op when the USB dongle is not there?)

I guess it's possible to know if networkd is configured to not manage
any devices *at all*, but perhaps there isn't much point in enabling the
networkd-wait-online service at all in that case anyway?

Struggling to understand the "why" question here, but could easily be
missing something! :-)

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Idea: adding WantsFileBefore= and WantsFileAfter=?

[Colin Guthrie]

Perhaps you missed Lennart's reply?

I have to say it doesn't sound like the right place to fix things.
Really the daemon needs to be fixed.

What you suggest sounds quite racy generally (at least the
WantsFileBefore= bit anyway) and really is just to paper over a badly
written daemon that also breaks (at least in theory) on SysV. I'd say
effort would be better spent making the daemon work.

Failing that (i.e. if the daemon code is not available), I'd just write
a very simple wrapper around your binary that implements the appropriate
waiting around the execution and keep the hack localised to this daemon
(or just stick with your ExecPreStart/PostStart and your "wait-for-file"
script solution). Probably not a general purpose approach that should be
encouraged :-)

Col

Ryan Gonzalez wrote on 24/03/18 01:35:
> I know everyone here is super busy, but I just wanted to bump this a sec
> before letting it die to make sure it didn't just get lost or something.
> (If someone agrees that it should be a feature, I'd happily try to work
> on it.)
> 
> On Tue, Mar 20, 2018 at 4:08 PM, Ryan Gonzalez <rym...@gmail.com> wrote:
>> Hello!! Recently, I was trying to help out someone on IRC move some
>> sysvinit scripts over to systemd units, and there was one interesting
>> issue that came up. Many older daemons will create sockets at some
>> unspecified point in their startup sequence, with no indication of
>> when this occurs. In this case, it was a bit after the pid file, so
>> systemd started running units that required this socket ready before
>> it was actually ready. Using socket activation here would be great,
>> but again, this is an older daemon, and AFAIK socket activation
>> *always* requires a deamon to read the socket path over stdin. Here's
>> my idea: what if there were WantsFileBefore= and WantsFileAfter=
>> options, that could be used like this: [Service] Type=oneshot
>> ExecStart=/usr/bin/my-service
>> WantsFileBefore=this-file-should-be-existant-before-running-service
>> WantsFileAfter=systemd-should-wait-until-this-file-exists-before-continuing
>> In short, WantsFileBefore=file would be roughly equivalent to
>> ExecPreStart=wait-for-file file, and WantsFileAfter=file would be
>> roughly equivalent to ExecPostStart=wait-for-file file. Of course, now
>> there would be no need to useless shell commands. Thoughts?
>> -- 
>> Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki
>> Sawano >> everyone else https://refi64.com/
> 
> --
> Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano
>>> everyone else https://refi64.com/
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
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?

[Colin Guthrie]

Paul Menzel wrote on 17/03/18 17:50:
> Dear Andrei,
> 
> 
> 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.

HTHs

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-logind failing due to dbus error on org.freedesktop.systemd1

[Colin Guthrie]

If it's ybbind that's causing issues, then chances are it's related to
the NSS setup, i.e. /etc/nsswitch.conf and other related config specific
to Yellow Pages stuff (I forget what they are as it's been > 10years
since I used it!)

It could be the NSS system is asking for user/group info via YP and this
is timing out or hanging due to lack of network etc. because the units
are misconfigured (the same issues exist with NSS-LDAP but this is
likely setup better as it's more commonplace these days).

Col

Gustavo Sousa wrote on 01/02/18 12:11:
> Hello, Michal.
> 
> After some trial an error I was able to find the culprit: the ypbind daemon.
> 
> - If I have it enabled, then it seems to me that, for some reason,
> systemd can not take ownership of the dbus names (/me not sure if that
> is the correct terminology).
> - If I leave it disabled, then the problem disapears. Now I need to
> find out why that is happening. The service file I got from my
> distro's package is pasted at https://pastebin.com/vVEXLcb9.
> 
> With that, would I be right to say that this isn't a problem with
> systemd itself?
> 
> Thank you!
> 
> Best regards,
> Gustavo Sousa
> 
> 
> On Wed, Jan 31, 2018 at 6:28 PM, Gustavo Sousa
> <gustavo.jo.so...@gmail.com> wrote:
>> On Wed, Jan 31, 2018 at 3:52 PM, Michal Koutný <mkou...@suse.com> wrote:
>>>
>>>
>>> On 01/31/2018 03:55 PM, Gustavo Sousa wrote:
>>>> Unfortunately, no. I didn't actually wait for the auto restart, I
>>>> tried myself with 'systemctl restart systemd-logind'.
>>> It seems like systemd-logind was thus properly connected to dbus and
>>> there may be other issue.
>>>
>>> Could you please post logs preceding the snippet you sent previously?
>>> (It seems something must went wrong at/before 8:38:51.)
>> I looked at the logs preceding that, but they logged the same error
>> (probably due to retries and me logging in?).
>> Then I decided to look at the logs from the beginning and realized a
>> different systemd error message (the snippet can be checked at
>> https://pastebin.com/kcAVcUQz):
>>
>> Jan 30 14:18:09 systemd[1]: Failed to subscribe to NameOwnerChanged
>> signal for 'org.freedesktop.login1': Connection timed out
>>
>> I also noticed that
>>
>>> Also since it
>>> happened after reboot and systemd-logind restart didn't help, does it
>>> mean it's reproducible or still present?
>> Yes, it is still present. About it being reproducible, it is in my
>> environment, but I'm not sure how easily that could be reproduced in a
>> different environment.
>>
>>> Can you see 'org.freedesktop.systemd1' name owned in the `busctl` output?
>> I'm not really familiar with dbus, but if by "owned" you mean that it
>> does have a process associated to it, then I would say no. Here is a
>> link for the output of `busctl`  https://pastebin.com/VqT38tya
>>
>>
>>> Does `kill -SIGUSR1 1` help you?
>> Nope. The issue persists (and the output of `busctl` keeps the same).
>>
>> Regards,
>> Gustavo Sousa
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

[Colin Guthrie]

Franck Bui wrote on 25/01/18 08:11:
>> Well, traditionally "auto" was a boolean (and it is in the /bin/mount
>> sources still): "auto" means on, "noauto" means off. And the default
>> was "auto". Redefining this to make something else the default, or
>> even treating this as a tri-state now of "on", "off",
>> "something-in-between" sounds like a bigger redefinition than the
>> change systemd made there...
>>
> I disagree here.
> 
> Initially "noauto" is interpreted only (?) by "mount -a" which was done
> during boot and can still be re-played later by admin. But in the later
> case the command is *initiated* by him so there's no magic here.
> 
> systemd redefined this though: "auto" is equivalent to "run 'mount -a'
> automatically when a backend device appears on udev's radar" which is
> totally different. And it's the default: if neither "noauto" nor "auto"
> is specified then the redefined "auto" is assumed.
> 
> The proposed change keeps the old default behavior: if neither "auto"
> nor "noauto" is specified, do the equivalent of "mount -a" during boot only.
> 
> If "auto" is explicitly specified then keep the behavior introduced by
> systemd too minimize the incompatible changes.
> 
> But honestly I would be in favor to remove it completely, see below.

Isn't the whole "mount -a during boot" a fundamentally fuzzy concept? I
mean, "in the past" this only worked because there were artificial
delays introduced to make sure all devices were probably available
before trying to mount them.

As systemd is more reactive (i.e. hotplug friendly) what's to say a
device plugged in 2s after boot is not a device plugging in at boot but
which takes a while to appear on the bus and filter through to become a
device node?

I don't think it would make technical sense to define a period in time
which flips systemd over to behaving differently. That would be very
confusing and hard to define and convey to users. At least the current
way is consistent even if it does have some other issues to contend with.

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


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

Re: [systemd-devel] How to stop systemctl --user processes before backup runs then restart

[Colin Guthrie]

Barry Scott wrote on 31/12/17 17:41:
> I think that for my backups to run for a user I will need to stop their 
> systemd user services.

Out of curiosity, why do you think that the process needs to be stopped
for the backups to run?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to run forking daemon with systemd in correct way, without errors?

[Colin Guthrie]

Gena Makhomed wrote on 23/11/17 12:38:
> On 23.11.2017 12:53, Michael Chapman wrote:
> 
>> Many other deficiencies with the BSD daemon() function are documented
>> in systemd's daemon(7) manpage.
> 
> Michael, thank you for reference to daemon(7) manpage,
> this is exactly that I am looking for.
> 
> I will try to ask nginx developers for implementing
> changes required by systemd from SysV Daemons.
> 
>> I would suggest ignoring some other commenters suggestions that PID
>> files are unnecessary with systemd. Indeed, there's even a TODO item
>> for a Type=pid-file service that would, presumably, allow even
>> non-forking services to signal readiness by writing a PID file. I
>> would find something like that very useful.
> 
> From TODO file "ExecRestartPre=" feature will be very useful
> for protecting users which edit nginx or httpd configuration files
> and restarts nginx or httpd to apply changes. If someone make error
> in configuration file and restart service - nginx or httpd
> will not start after stop and service will be not working.
> 
> "ExecRestartPre=" feature will help to protect from such situations:
> 
> https://lists.freedesktop.org/archives/systemd-devel/2014-July/021642.html
> 
> Record in TODO file exists, even issue on github exists:
> 
> https://github.com/systemd/systemd/issues/2175
> 
> with comment from nginx.org packages maintainer Konstantin Pavlov:
> 
> https://github.com/systemd/systemd/issues/2175#issuecomment-343481962
> 
> But as I understand, feature "ExecRestartPre=" will not be included
> in the upcoming CentOS 8 / RHEL 8 system, because nobody
> of systemd developers have time to implement this feature.
> 
> Or anybody of systemd developers has time to implement this feature?
> 

I know this is somewhat tangential but in many of the cases you describe
here, a "reload" is more appropriate than a "restart". The config
parsing logic could either be specified in the systemd unit (just as one
of many ExecReload= entries) or could be handled internally in the
binary itself (presumably when the mainpid has received some signal).

That's not to take away from the usefulness of an ExecRestartPre=
directive of course, it's just that with nginx and httpd restarting is
not something you would ideally want to do in production unless you can
use full socket activation supported by systemd so as not to create a
small window when connections from clients are refused.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 回复： 回复： 回复： 回复： 回复： 回复： 回复： [systemd-d e vel] sys temctl can't executestopactually,whenservice isstarted by other way

[Colin Guthrie]

Lennart Poettering wrote on 01/11/17 10:17:
> On Mi, 01.11.17 17:59, 清辰 (624001...@qq.com) wrote:
> 
>> Hi Lennart,
>> That is important for me. Could you tell me that?
> 
> I am sorry, but I don't understand the question? 
> 
>> This documentation says I can set by
>> LimitCORE="0;0"
>>
>>
>> But my request is:
>> For example, now system hard limit of core is infinity, I want to set soft 
>> limit to infinity.
>> But when hard limit is 0, I want to set soft limit to 0.
>> when hard limit is 100, I want to set soft limit to 100.

From how I read it, the OP is asking for the syntax to set the soft
limit in the .service file to whatever the current system-wide hard
limit is.

I'm afraid I'm not sure of the underlying concepts there to say whether
this is supported (or indeed sensible)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] restricting resource of a process within a service

[Colin Guthrie]

Armen Baloyan wrote on 18/10/17 02:21:
> Hi,
> 
> I need to restrict CPU usage for a process that runs in a service. The
> service has over 10 processes running but I need to put restrictions
> only on 1 of those processes.
> Is it possible to move this process to a separate cgroup or it cannot be
> removed its service's cgroup?

I don't think this is supported.

Depending on how your "master" process works and communicates with it's
10 processes, you may want to consider splitting your service out into
separate systemd units. They can all be dependant on each other or,
depending on your IPC mechanisms, you can use socket or bus activation.
This then lets you have separate systemd units for each and apply
whatever accounting and restrictions you may wish on each.

HTHs

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Formatting Execstart= for readability

[Colin Guthrie]

Kai Hendry wrote on 16/08/17 08:52:
> Hi there,
> 
> I maintain a service file with a lot of switches in the ExecStart
> https://github.com/kaihendry/pingprom/blob/master/prometheus%40.service#L8
> 
> I want to almost document each switch ... e.g.
> -storage.local.retention=8544h  # keep data for a year
> 
> I know inline comments do *not* work in bash IIUC:
> https://gist.github.com/kaihendry/ff751622c6454176837b1c340b5cfccb
> 
> And similarly when I try break up lines on something like
> https://s.natalian.org/2017-08-16/test.service
> 
> [Service]
> ExecStart=/usr/bin/curl -X POST 
> -d "fizz=systemd"  # some docs
> -d "some=else"  # more docs
>  https://requestb.in/19v8a0m1
> 
> 
> It also doesn't work. Am I missing a tool or way to better
> format/document process arguments like I want?
> 
> Many thanks!

Write a companion man page and/or web page and reference it in
Documentation=

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Colin Guthrie]

Reindl Harald wrote on 04/07/17 19:50:
>> When new configuration options are added, the same unit file can
>> almost always be used with older systemd, and it'll just warn & ignore
>> the parts it doesn't understand. Similarly, various configuration
>> options might be unavailable on some architectures and with some
>> compilation options. The current behaviour of warn provides
>> for "soft degradation" in those cases.
> 
> frankly a new option on the left side is a completly different thing
> than a invalid value - just silently continue with invalid values of
> existing options is playing a danergous game in a crucial component like
> systemd

It's a rare thing :p but I have to agree with you here!

I'd say if "User=-notauser" then silently failing and using root is
acceptable as per the usual semantics of "- prefix suppresses errors",
but "User=notauser" should fail IMO.

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] start user-service only with UID greater than 1000

[Colin Guthrie]

Michael Biebl wrote on 09/05/17 20:11:
> 2017-05-09 20:35 GMT+02:00, Lennart Poettering <lenn...@poettering.net>:
>> On Tue, 09.05.17 17:06, Jakob Schürz (wertsto...@nurfuerspam.de) wrote:
>>
>>> Hi There!
>>>
>>> I have two services running in systemd --user, which should only be
>>> startet for login-users.
>>> If i put the service-file by a deb-package in /usr/lib/systemd/user, the
>>> service will also be started for Debian-exim, Debian-gdm and other users
>>> with a UID below 1000. And this is not "good"...
>>
>> These users should not have a PAM session normally, and hence no
>> logind session either, and hence no systemd --user instance
>> either. There's something really strange if you actually do get PAM
>> sessions for these... Any idea why you get them?
>>
>
> Afaics, the logind/PAM session for gdm/Debian-gdm is deliberate. gdm
> spawns that via gdm-launch-environment, see
> /etc/pam.d/gdm-launch-environment, which in turn includes
> pam_systemd.so


And I think this is needed and desirable for stuff like pulseaudio for
audio feedback for the login window etc. which would be launched via
socket activation from the systemd --user session ideally.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] VERY slow systemd startup

[Colin Guthrie]

Ed Peschko wrote on 19/12/16 23:26:
> All,
> 
> I'm getting very slow systemd startup times in centos7.1.1503, and centos
> 
> From systemd-analyze plot:
> 
>  Startup finished in 553ms (kernel) + 3.414s (initrd) + 26min
> 15.064s (userspace) = 26min 19.032s
> 
> and looking at the underlying svg, I see that the vast majority of the
> userspace time is spent in the very start, ie: unlabeled (it shows
> kernel, then initrd, then 25 *minutes* of unlabeled systemd before
> hitting the first systemd services, namely:
> 
> user.slice (< 1 ms)
> systemd-ask-password-wall.path (< 1ms)
> ...etc
> 
> In other words it seems to be hanging for an computer eternity, then
> snapping out of it and going with the first service.
> 
> To me, its odd, too that this time is not labeled.
> 
> Any ideas what is going on, or extra checks that I could put in to
> track the problem further?


This would suggest that you're being asked to input a password and it's
waiting for user input. I suspect this relates to an encrypted partition
that is referenced in /etc/fstab It's perhaps not essential for booting,
e.g. it's marked as nofail or similar but a mount will still be
attempted at startup (cf noauto)

Perhaps you're not seeing the password prompt because other output is
clobbering it, e.g. you have "debug" specified or you do not have
"quiet" specified on the kernel command line. Or perhaps you have some
graphical thing (e.g. plymouth) but for some reason it's built without
password entry support.

Hope this helps

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Spurious failures starting ConnMan with systemd

[Colin Guthrie]

Hi,

Daniel Wagner wrote on 15/11/16 15:02:
> Hi Colin,
> 
> On 11/15/2016 03:46 PM, Colin Guthrie wrote:
>> Hope you're keeping well?
> 
> Doing fine! How is live in the north? 

Grand thank you! :)

>> So, by default, dbus should be socket activated. That means that when

>> If socket activation is used, then there shouldn't be any need to
>> mention dbus.socket/service in connman.service at all.
> 
> """
> [Unit]
> Description=Connection service
> DefaultDependencies=false
> Conflicts=shutdown.target
> RequiresMountsFor=/var/lib/connman
> After=dbus.service network-pre.target systemd-sysusers.service
> Before=network.target multi-user.target shutdown.target
> Wants=network.target
...
> Hmm, now I am confused...

There may be valid reasons for not wanting some of the default
dependants but there are probably some you still want.

e.g. maybe you should do After=sockets.target (and perhaps
Requires=sockets.target although practically speaking I'm not sure if
this is needed), this would be sufficient. sockets.target is pretty low
level and can start quite early on. I suspect starting after that should
still allow connman to function as you require but without this sporadic
dbus connection issue.

HTHs

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Spurious failures starting ConnMan with systemd

[Colin Guthrie]

he above
>> command shows Requires=basic.target, which depends on sockets.target,
>> which depends on dbus.socket. I think that's why I didn't have any
>> trouble with v1.30.
>>
>> In 09aa024 (first change to the service file after v1.30 release),
>> DefaultDependencies was set to false. According to
>> https://www.freedesktop.org/software/systemd/man/systemd.special.html,
>> an After= dependency on basic.target is added automatically if
>> DefaultDependencies is set to yes, so this is missing now. The After=
>> dependency on dbus.service is still there, but it is not Required. Out
>> of curiosity, I've removed the dbus.service dependency completely to
>> check if Type=dbus is enough as is documented. Turns out it is not.
>> Neither the output of "systemctl show connman.service" nor that of
>> "systemctl list-dependencies connman.service" show _any_ dependencies
>> on dbus.service/dbus.socket in this case.
>>
>> Why the automatically added After= dependency on basic.target has
>> turned into a Requires= dependency with the v1.30 file, but the
>> explicit After=dbus.service dependency in the file from 09aa024
>> remains an After= dependency is beyond me. My guess is that
>> DefaultDependencies does a little bit more than is documented, or
>> maybe it's just a bug in my version of systemd (v225). Maybe it's some
>> strange interaction between unit files that I am unable to see.
>>
>> A comment from someone with a little more experience with systemd
>> would be most welcome.
> 
> Any recommendation from systemd folks?
> 
> cheers,
> daniel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] assign variable to some service item

[Colin Guthrie]

As others have said, this is not possible.

It is however possible to configure it via a dropin file.

e.g. if your unit is called foo.service, then just mkdir
/etc/systemd/system/foo.service.d/ and create a file cpu-affinity.conf
inside that folder (any filename will do).

In this file put:

[Service]
CPUAffinity=0-2


Then just reload systemd (systemctl --system reload) and your value
should be available.

It's not an environment file, but it's still an easy file for
administrators to hack on without affecting packaged units in /usr

Note, to make life easier for you, you can simply call "systemctl edit
foo.service" and an editor will open and let you customise it.

HTHs

Col



Vasiliy Tolstov wrote on 29/09/16 09:25:
> I have CPUAffinity inside service file and want to configure it via
> EnvironmentFile, but
> CPUAffinity=$CPUAffinity does not work with message Failed to parse
> CPU affinity '$CPUAffinity'
> Environment file contains CPUAffinity="0-2"
> Does it possible to assign cpu affinity via env variable ?
> Thanks!
> 
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Reboot hangs at the very last step

[Colin Guthrie]

Andrei Borzenkov wrote on 20/07/16 11:54:
> On Wed, Jul 20, 2016 at 12:20 PM, Colin Guthrie <gm...@colin.guthr.ie> wrote:
> 
>>
>> Is it enough to just add the "_netdev" option to the fstab mounts in
>> question?
> 
> The problem is triggered by manual mounts; here _netdev is irrelevant.

Fair enough. I thought the manual mounts were still triggered from a
"noauto" entry in fstab and thus _netdev would still result in
appropriate After= deps added to the generated unit, but I can see how
the problem would arise in cases where there is no fstab entry at all
and the mounts are added manually.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Colin Guthrie]

Jan Alexander Steffens wrote on 06/07/16 10:44:
> On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie <gm...@colin.guthr.ie
> <mailto:gm...@colin.guthr.ie>> wrote:
> 
> Martin Pitt wrote on 04/07/16 23:08:
> >> > Why would you call it graphical-<$DE>.slice as opposed to
> simply <$DE>.slice
> >> > which is part of the <$DE>.target and graphical target is link
> to that
> >> > <$DE>.target  ( if shipped upstream it needs to be generic
> enough to cater
> >> > whatever is out there right )
> > target units don't work well as they don't stop their dependencies on
> > stop, as I explained -- unless there's a trick which I'm missing?
> 
> Not commenting on the general approach (which I did read and broadly
> agree with without giving it too much thought!), but could you use
> PartOf= here to make the target approach work? It might be more hacky as
> each user .service would have to declare themselves to be PartOf the
> corresponding .target. This does mean that if the target is stopped, the
> units are stopped too.
> 
> I'm not sure how this would work regarding things like g-s-d which you
> want in multiple DEs.. perhaps the gnome.target would have to be split
> up into gnome-base.target and gnome.target to allow for this use case?
> Or perhaps g-s-d could just become bus activated and not need any direct
> starting?
> 
> 
> How about a top-level, generic graphical.target that defines no
> dependencies itself, but is Required by anything graphical. Then
> stopping graphical.target would terminate the desktop, no matter which
> environment was set up.
> 
> I was thinking of a direct Requires on all units, but maybe transitive
> Requires via intermediate targets would be useful, too.

I didn't read the whole thread :( The suggestion of adding a
DependenciesPartOf=yes|no directive to target units is a good suggestion
IMO and solves this same problem too (if I understand correctly - the
target can just add a Requires= check for each accordingly, e.g.
xfce.target can Require=g-s-d.service quite happily)

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Colin Guthrie]

Martin Pitt wrote on 04/07/16 23:08:
>> > Why would you call it graphical-<$DE>.slice as opposed to simply 
>> > <$DE>.slice
>> > which is part of the <$DE>.target and graphical target is link to that
>> > <$DE>.target  ( if shipped upstream it needs to be generic enough to cater
>> > whatever is out there right )
> target units don't work well as they don't stop their dependencies on
> stop, as I explained -- unless there's a trick which I'm missing?

Not commenting on the general approach (which I did read and broadly
agree with without giving it too much thought!), but could you use
PartOf= here to make the target approach work? It might be more hacky as
each user .service would have to declare themselves to be PartOf the
corresponding .target. This does mean that if the target is stopped, the
units are stopped too.

I'm not sure how this would work regarding things like g-s-d which you
want in multiple DEs.. perhaps the gnome.target would have to be split
up into gnome-base.target and gnome.target to allow for this use case?
Or perhaps g-s-d could just become bus activated and not need any direct
starting?

Col

-- 
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?

[Colin Guthrie]

Lennart Poettering wrote on 30/05/16 17:47:
> hence an acceptable alternatively might be to
> introduce /efi and mount the esp there, and simply not have /boot on
> legacy free systems.

This might be the pragmatic way to get this schema more widely adopted.
kernel-install could be modified to detect which is used and copy the
kernel to the appropriate directory (or copy it to both).

I really like the ESP as /boot approach but it's hard to get people to
buy into it :(

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Colin Guthrie]

Andrei Borzenkov wrote on 11/03/16 03:36:
> 11.03.2016 00:11, Orion Poplawski пишет:
>> Uoti Urpala  pp1.inet.fi> writes:
>>
>>>
>>> On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
>>>> Orion Poplawski  cora.nwra.com> writes:
>>>>>  
>>>>> # systemctl restart firewalld
>>>>> Failed to restart firewalld.service: Transaction contains
>>>>> conflicting jobs
>>>>> 'restart' and 'stop' for fail2ban.service. Probably contradicting
>>>>> requirement dependencies configured.
>>>
>>>> It appears that this is a trigger for this issue.  Removing the
>>>> conflicts=iptables.service removes it.  This seems like a bug to me
>>>> though -
>>>> why is iptables being brought in if the PartOf= is a one-way dep?
>>>
>>> I guess it's because it's because firewalld.service has
>>> "Conflicts=iptables.service", and thus (re)starting firewalld.service
>>> stops iptables.service; fail2ban.service has PartOf to both, thus both
>>> the restart and stop are propagated, and conflict.
>>
>> Can't the stop of iptables be dropped because the service is already stopped
>> (or more likely not even present)?
>>
>>> Claiming a PartOf relationship to both of two conflicting services is
>>> the problem here. I doubt such a use case was what PartOf was designed
>>> to support.
>>
>>
>> The problem is that fail2ban can work with either iptables.service or
>> fail2ban.service, and we don't know which one the use wants to use.  And we
>> need fail2ban to be restarted if either firewalld or iptables is restarted.
>> If there is some other supported way of achieving this, that would be
>> welcome.  Otherwise this strikes be as something that should be able to be
>> handled as is.
> 
> 
> One possible implementation is to have firewall.target and make all
> otehr services (firewalld, iptables and fail2ban) PartOf this target.
> You would then start/stop firewall.target instead of individual services.

That's certainly more the kind of configuration PartOf= was originally
developed to support. I wasn't even aware you could use it with .service
units, thought it was only for .targets if I'm honest.

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Colin Guthrie]

Dave Reisner wrote on 12/02/16 01:09:
> On Thu, Feb 11, 2016 at 10:26:51PM +0100, Reindl Harald wrote:
>>
>> Am 11.02.2016 um 22:19 schrieb Dave Reisner:
>>> On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
>>>> I just tagged the v229 release of systemd. Enjoy!
>>>>
>>>> CHANGES WITH 229:
>>>>
>>>> 
>>>>
>>>> * When the stacktrace is extracted from processes of system users, 
>>>> this
>>>>   is now done as "systemd-coredump" user, in order to sandbox this
>>>>   potentially security sensitive parsing operation. (Note that when
>>>>   processing coredumps of normal users this is done under the user 
>>>> ID
>>>>   of process that crashed, as before.) Packagers should take notice
>>>>   that it is now necessary to create the "systemd-coredump" system 
>>>> user
>>>>   and group at package installation time.
>>>>
>>>
>>> Why is it left to downstream to create this user? What makes it
>>> different from the other 4 users which systemd already creates?
>>
>> systemd don't create any user. nowhere, rpm-scritrs downstream does
> 
> You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf 
> and
> systemd-sysusers(8). The curious absence of systemd-coredump from
> sysusers.d/systemd.conf is what I'm asking about here.

Seems odd indeed. It's perhaps because the user needs to own directories
that are packaged (e.g. in /var) which is somewhat tricky with sysusers
- you need to have the user available before the package is installed -
i.e. an RPM %pre script.  Just a guess at why it was left out.

Personally, I'd just make such folders ghosts and them have them created
by tmpfiles after package install (and thus after sysusers has run to
create the user who will own the folders)

This is something that I think should be automated in RPM packaging
(i.e. the creation of ghosts automatically by parsing packaged tmpfiles
snippets), but this is off-topic.

Col




-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Colin Guthrie]

Lennart Poettering wrote on 11/02/16 17:49:
> On Thu, 11.02.16 18:29, Matthias Urlichs (matth...@urlichs.de) wrote:
> 
>> Hi,
>>
>> Lennart Poettering:
>>> 5) Here's the controversial one I think: support for booting up
>>>without /var.
>>
>> Meh. I have quite a few multi-boot systems with a common /var/log
>> partition. Plus, unlike the other "spring cleaning" changes this would
>> cause a boot failure after update.
> 
> Again: this does not break systems with split off /var, as I tried to
> make very clear in my original mail. All that's needed is that the
> initrd mounts /var before handing off control to the main system.
> 
> The initrd already does that for / and for /usr, hence /var is just
> one more step.

Hmmm, has all the split-usr code been fully removed from systemd now? A
quick grep suggests not.

While I don't personally have a problem with this removal, I do think
that comparing it to /usr is bogus.

While you may not *support* /usr being split out and mounted by /, it
does still work and systemd *is* still sympathetic to that.

The situation with /var is much more brutal. You're suggesting that it
would now be something that *has* to be done by the initrd and if you go
down that route, you may as well ditch all the split-usr stuff too as if
the initrd *has* to mount /var, it may as well do /usr too now even if
there were some hold outs.


Like I say, I get your reasoning for wanting to do this, but it's not
really comparable to /usr support.


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Colin Guthrie]

Armin K. wrote on 12/02/16 09:56:
> On 12.02.2016 10:54, Colin Guthrie wrote:
>> Dave Reisner wrote on 12/02/16 01:09:
>>> On Thu, Feb 11, 2016 at 10:26:51PM +0100, Reindl Harald wrote:
>>>>
>>>> Am 11.02.2016 um 22:19 schrieb Dave Reisner:
>>>>> On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
>>>>>> I just tagged the v229 release of systemd. Enjoy!
>>>>>>
>>>>>> CHANGES WITH 229:
>>>>>>
>>>>>> 
>>>>>>
>>>>>> * When the stacktrace is extracted from processes of system 
>>>>>> users, this
>>>>>>   is now done as "systemd-coredump" user, in order to sandbox 
>>>>>> this
>>>>>>   potentially security sensitive parsing operation. (Note that 
>>>>>> when
>>>>>>   processing coredumps of normal users this is done under the 
>>>>>> user ID
>>>>>>   of process that crashed, as before.) Packagers should take 
>>>>>> notice
>>>>>>   that it is now necessary to create the "systemd-coredump" 
>>>>>> system user
>>>>>>   and group at package installation time.
>>>>>>
>>>>>
>>>>> Why is it left to downstream to create this user? What makes it
>>>>> different from the other 4 users which systemd already creates?
>>>>
>>>> systemd don't create any user. nowhere, rpm-scritrs downstream does
>>>
>>> You're mistaken. See 
>>> /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
>>> systemd-sysusers(8). The curious absence of systemd-coredump from
>>> sysusers.d/systemd.conf is what I'm asking about here.
>>
>> Seems odd indeed. It's perhaps because the user needs to own directories
>> that are packaged (e.g. in /var) which is somewhat tricky with sysusers
>> - you need to have the user available before the package is installed -
>> i.e. an RPM %pre script.  Just a guess at why it was left out.
>>
>> Personally, I'd just make such folders ghosts and them have them created
>> by tmpfiles after package install (and thus after sysusers has run to
>> create the user who will own the folders)
>>
>> This is something that I think should be automated in RPM packaging
>> (i.e. the creation of ghosts automatically by parsing packaged tmpfiles
>> snippets), but this is off-topic.
>>
>> Col
>>
>>
>>
>>
> 
> I don't see the problem. The user is already in sysusers.d/systemd.conf.m4
> 
> https://github.com/systemd/systemd/blob/master/sysusers.d/systemd.conf.m4
> 
> I do appreciate that he mentioned a new user had to be created, because,
> you know, not everyone uses systemd-sysusers.

Indeed. In my package here, it successfully created the user via
sysusers on update. I should have double checked rather than blindly
believing Dave's statement which, as it turns out, is incorrect (tho' I
can see why he make the assumption due to the original wording).

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trying to set up DNS server.

[Colin Guthrie]

Motokazu Nakai wrote on 27/01/16 09:11:
> Could you please help me how to fix this?

As Mantas stated previously, this isn't a systemd problem (systemd and
the journal are just the tools to view the logs and such like) and thus
this is something you should seek guidance on from the appropriate
community resource. You can perhaps ask via your distribution
support/community channels or see help from the upstream named community
or perhaps stack overflow or other general purpose community support forum.

HTHs

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can one service receive SD_NOTIFY (Ready) message of another service?

[Colin Guthrie]

Pathangi Janardhanan wrote on 26/01/16 20:41:
> Hi All,
> 
>  The use case I have is following:
> 
>  I have a service B, which for its operation depends on Service A. Using
> systemd feature, I can make systemd start service B after service A has
> indicated ready.
> 
>  The issue is service B also does a lot of initialization which is
> independent of service A (which also has length initialization code).
> After that initialization it needs to know of service A availability,
> before service B can declare itself ready.
> 
>  I see two choices:
> 
> 1. Use systemd and have it start service B after service A is fully
> ready, even if that means that the service B intialization is not being
> done in parallel
> 
> 2. Let systemd start service A and B together, and have some specific
> messaging/mechanism from service A and B
> 
>  The third option I was looking for but which I could not find, was to
> 
>  have systemd start both independently, and then have service B
> query/wait on systemd service till service A sends a SD_NOTIFY with
> ready message?
> 
>  is something like that possible, or is option 2 the best way for me to
> proceed?

Option 1 is likely the easiest.

Depending on how the services actually work, then you could just use
socket activation and thus the services only depend on the sockets that
active each service and not the services themselves directly.

e.g. if service A talks to service B via a socket, then just ensure that
service B can be socket activated and then you can technically start
them both in parallel.


Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] known but not-listed units

[Colin Guthrie]

Mikhail Kasimov wrote on 14/01/16 15:27:
> 'systemctl list-unit-files --user': to display units-files from
> /etc/systemd/system dir

I wouldn't use --user here as "systemctl --user" has an existing meaning.

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github issue progress stalled

[Colin Guthrie]

Philip Müller wrote on 08/12/15 11:16:
> However I can still see that your "quest" is still open:
> 
> Try connecting with gdb to PID 1 and see which event causes it to wakeup
> all the time. for that set a breakpoint on source_dispatch and look at
> s->description which hopefully contains a short string that tells you
> which source is being triggered there ...

I think I've supplied all that information on the issue no?

Is there something I'm missing?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

[systemd-devel] Github issue progress stalled

[Colin Guthrie]

Hi,

I've been trying to document my progress and give requested feedback on
a rather major regression that's badly affecting my system.

The issue seems to have stalled, and I'm receiving no further updates
despite providing the requested details.

https://github.com/systemd/systemd/issues/1579

There also seems to be no way to remove a "needs-reporter-feedback" tag
after I've provided feedback so it'll probably be getting ignored in any
workflows you use that exclude bugs with that tag.

How is this workflow with GH issues supposed to work?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] Detect if a script runs during bootup

[Colin Guthrie]

Zbigniew Jędrzejewski-Szmek wrote on 11/11/15 15:55:
> On Wed, Nov 11, 2015 at 04:39:23PM +0100, Frank Steiner wrote:
>> Isn't there an easy way to figure out if this script is running
>> inside the boot process? Some variable set or not yet set?
> You can use systemctl is-system-running (see the man page).

I guess another option would just be to write out a flag file into /run
tree when you do the first call. First call the file won't exist, all
subsequent calls it will.

That might fit better with a scripted solution than calling out to an
exec, but YMMV.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] [packaging] split of systemd package

[Colin Guthrie]

Zbigniew Jędrzejewski-Szmek wrote on 11/11/15 13:38:
>>> > > systemd-machine (machined,nspawn,importd)
>> > 
>> > We call that package "systemd-container", but it has exactly those, so
>> > "check".
> I think we (Fedora) should follow this, for inter-distro consistency.


I prefer that name to systemd-nspawn. As Lennart's original comment on
the systemd-machine package name suggestion was "the name of the daemon
doesn't matter", I'd argue that the name of the binary also doesn't
matter too much! After all, the "nspawn" itself doesn't mean anything
unless you know what nspawn is, and if you know what it is, then you
know what a container is, so the name systemd-container makes sense there.

So +1 from me for that name as a general recommendation.

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Colin Guthrie]

Kai Hendry wrote on 02/11/15 10:44:
>> > well, systemd-journal-gatewayd serves that already, you can just use
>> > that...
> Ah! Perfect. Oh but I need a way to setup CORS so I can access it from
> my Webapp:
> http://s.natalian.org/2015-11-02/systemd-journal-gatewayd.png
> 
> Shall I file a bug?

I suspect that you'd probably want to hide this behind some kind of
proxy for security reasons. That proxy could add appropriate
authentication (e.g IP restrictions, user auth etc) and add in any
additional headers).

I could be wrong with this suggestion, but this would be my first guess
at how you would solve this problem.

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] checking predictable interface names

[Colin Guthrie]

Michał Zegan wrote on 17/10/15 20:32:
> Hello.
> On non systemd systems, or on systems with disabled ifnames, is it
> possible to somehow check what would be the interface name after rename
> by default?
> I would need this for example in case when I installed a system into a
> chroot environment, while the host is for example not a systemd system,
> and I want to configure network because I will have no other access to
> the newly installed os after reboot.

Does this work for you?

udevadm test-builtin net_id 

?

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Setting the shell to the system locale

[Colin Guthrie]

Hi,

David Adam wrote on 15/10/15 07:18:
> Hi,
> 
> I work on fish shell, which is a non-POSIX command-line shell. I'm
> trying to work out whether we should ship something in our source that 
> tries to set the locale for our users. Alternatively, it might be 
> something that needs to be left to distributions as it seems to be handled 
> very differently.
> 
> Is /etc/locale.conf appropriate for consumption by clients other than 
> systemd - such as shells? That is, is the format stable? If not, is there 
> a way of querying the default system locale if there is no `LANG` (etc.) 
> set in the environment - through `localectl` or otherwise?
> 
> A broader question is: which process should be responsible for setting the 
> locale? Are the comments in the log message for 1640944a84 still 
> appropriate?
> 
>> Eventually we probably want to drop this again since the system locale
>> should be read and set at one place, and not at multiple, and that one 
>> place should be PID 1.
> 
> I am not sure there is a good answer to this question, but I would be 
> interested in hearing about the rationale for the different approaches. 
> For example, Debian sets up PAM to source /etc/default/locale for all 
> sessions, while Fedora drops a script in /etc/profile.d for command-line 
> shells. Most graphical shells seem to use their own defaults.

I think, if you can, you should ask localed via dbus for the locale
information (rather than parsing /etc/locale.conf directly). This way
the details of how it's set can be changed and you just use that API
directly.

I think a while back, David Herrmann hinted towards localed in the user
session (i.e. there would be a system instance for system-wide locale
and a per-user one for user preferences. Not sure if this ended up
happening or not tho'. It may be worth looking at the console stuff in
systemd to see how it sets locales?

Not much info from me but hopefully helps a bit!

Col




-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems

[Colin Guthrie]

Hendrik Brueckner wrote on 09/10/15 08:13:
> Any feedback regarding this change?  Did I miss to notify someone
> to pick that patch up?

The process these days is via PR on GitHub. Normally patches posted to
the ML get a PR created for them automatically, but I don't see that here...

Perhaps retry via GitHub?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] systemd shutdown query

[Colin Guthrie]

Susant Sahani wrote on 07/10/15 04:05:
> 
> 
> On 10/06/2015 06:36 PM, Lennart Poettering wrote:
>> On Mon, 05.10.15 15:49, Dushyant Uge (dushyan...@gmail.com) wrote:
>>
>>> Hello there,
>>>
>>> I have two queries
>>>
>>> Some processes terminated immediately after writing reboot before
>>> reaching
>>> systemd unit ExecStop
>>
>> I am not sure I parse this, but when services are shut down systemd
>> won't kill their processes until their ExecStop= is executed, so that
>> the code in the ExecStop= can do that on its own. Everything else would
>> be a bug.
> If it's like ExecStop=su  example-user; /sbin/foo .
> then is it the same behavior ?

That's not a valid ExecStop definition (for one, there is no path to su;
secondly it contains a ; which isn't doing what you think it does...)

I'd strongly advice against using su, but if you have to you'd have to
wrap this command in some kind of script:

e.g. ExecStop=/bin/sh -c '/sbin/su example-user; /sbin/foo .'

But I'd really recommend finding a cleaner way to do this!

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] run no more than one of foo@.service at a time

[Colin Guthrie]

Johannes Ernst wrote on 05/10/15 23:53:
> 
>> On Oct 5, 2015, at 14:29, David Timothy Strauss
>> <da...@davidstrauss.net <mailto:da...@davidstrauss.net>> wrote:
>>
>> If you only want one instance running, why not just create one service
>> and reconfigure/restart it?
>>
> Because the service dependencies are totally different.

If the service dependencies are totally different, why are you using a
templated unit? Surely templated units have to have the same dependences.

Basically in your unit, you are presumably using %i or %I in it in some
capacity.

What David suggested was using a
/etc/systemd/system/foo.service.d/config.conf dropin file to add a
"Environment=MYVAR=newval" line and use $MYVAR in your unit rather than
%i or %I.

This is the same approach but you configure your unit appropriately
rather than using instances.

If you post your unit or provide more details of the kind of thing you
are actually wanting to achieve (rather than the solution you want) then
people may be able to offer other suggestions.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What I think is really wrong with systemd

[Colin Guthrie]

Reindl Harald wrote on 17/09/15 02:19:
> 
> 
> Am 17.09.2015 um 03:08 schrieb Jon Stanley:
>> On Wed, Sep 16, 2015 at 8:45 PM, Reindl Harald
>> <h.rei...@thelounge.net> wrote:
>>
>>> nonsense
>>>
>>> 4.1.x will get a lot more updates while 4.2.x get them too
>>> systemd never ever had any minor release
>>
>> That is the nonsense. 4.1.x is not maintained by the kernel
>> maintainer, but rather someone interested in maintaining old releases
>> of the kernel. Linus has zero to do with what goes into 4.1.x (other
>> than Greg's rule that all changes in linux-stable must be in the
>> mainline kernel)
> 
> Linus is not the Kernel alone
> 
> frankly, i don't matter which person is repsonsible for what exactly -


Exactly, and the systemd -stable branches that many distributions use
serve precisely the same purpose. Just because they are not distributed
as a tarball makes no odds. Systemd itself is no longer distributed as a
tarball either and as you said, it [doesn't] matter which person is
responsible.

So, as your argument make no sense...
http://i1.kym-cdn.com/photos/images/facebook/000/175/839/nickcage.jpeg

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Kill on console works, ExecStop not

[Colin Guthrie]

Florian Lindner wrote on 12/08/15 15:47:
 Hello,
 
 I have a systemd 224 user service unit that starts the emacs daemon:
 
 [Unit]
 Description=Emacs: the extensible, self-documenting text editor
 
 [Service]
 Type=forking
 ExecStart=/usr/bin/emacs --daemon
 ExecStop=/usr/bin/emacsclient --eval (progn (setq kill-emacs-hook nil) 
 (kill-emacs))
 Restart=always
 
 [Install]
 WantedBy=default.target
 
 
 I starts just fine, but stopping is problematic:
 
 % systemctl --user start emacs
   
  
 % systemctl --user status emacs
 ● emacs.service - Emacs: the extensible, self-documenting text editor
Loaded: loaded (/home/florian/.config/systemd/user/emacs.service; 
 disabled; vendor preset: enabled)
Active: active (running) since Mi 2015-08-12 15:57:32 CEST; 13s ago
   Process: 1331 ExecStart=/usr/bin/emacs --daemon (code=exited, 
 status=0/SUCCESS)
  Main PID: 1332 (emacs)
CGroup: /user.slice/user-1000.slice/user@1000.service/emacs.service
├─1332 /usr/bin/emacs --daemon
└─1343 /usr/sbin/idn --quiet --idna-to-ascii --usestd3asciirules
 
 [...]
 
 % systemctl --user stop emacs
 % systemctl --user status emacs
 ● emacs.service - Emacs: the extensible, self-documenting text editor
Loaded: loaded (/home/florian/.config/systemd/user/emacs.service; 
 disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mi 2015-08-12 16:03:21 CEST; 6s 
 ago
   Process: 1906 ExecStop=/usr/bin/emacsclient --eval (progn (setq kill-
 emacs-hook nil) (kill-emacs)) (code=exited, status=0/SUCCESS)
   Process: 1331 ExecStart=/usr/bin/emacs --daemon (code=exited, 
 status=0/SUCCESS)
  Main PID: 1332 (code=exited, status=15)
 
 [...]
 Aug 12 16:03:21 asaru systemd[499]: Stopping Emacs: the extensible, self-
 documenting text editor...
 Aug 12 16:03:21 asaru systemd[499]: emacs.service: Main process exited, 
 code=exited, status=15/n/a
 Aug 12 16:03:21 asaru systemd[499]: Stopped Emacs: the extensible, self-
 documenting text editor.
 Aug 12 16:03:21 asaru systemd[499]: emacs.service: Unit entered failed 
 state.
 Aug 12 16:03:21 asaru systemd[499]: emacs.service: Failed with result 'exit-
 code'.
 
 
 However, stopping with the same command works:
 
 % /usr/bin/emacs --daemon 
   
 
 [...]
 % /usr/bin/emacsclient --eval (progn (setq kill-emacs-hook nil) (kill-
 emacs))
 
 returns 0 exit code.

Note that the exit code from the emacclient is 0 in both cases.

The systemd status snippet you quote above is complaining that the exit
code for PID 1332 is 15, (i.e. the main process (emacs --daemon)) and it
happily reports that your emacsclient --eval command exited with status 0.

Is it expected that emacs --daemon exits with status 15 when called via
such an eval? If so, you can configure the unit accordingly to tell it
about that exit code as you mentioned already.

There is also the possibility of a race condition here.

It could be that emacsclient --eval returns before waiting for the
results of the signal (i.e. it exits after *sending* the signal, but
before the signal is fully handled). In this case, when it's run as part
of an ExecStop, systemd will then move on to a killing spree (it expects
ExecStop to leave things clean, so if anything is left, it mops up),
sending SIGTERM to the emacs --daemon process. Depending on how it
handles the signals and where in it's destruction process (from the
emacsclient signal) it *might* exit with status 15.

HTHs

Col




-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] starting processes for other users

[Colin Guthrie]

Michał Zegan wrote on 31/07/15 12:37:
 The thing is, if the user does it, then after he leaves, the process
 is running under the user's session.
 If I log in to my own account, su to the other user and start the
 process and then logout, this process, even though running as the
 other user, is in my own session.
 Actually it is sometimes confusing to see utmp entries saying
 different things than loginctl ;)
 

Using tools like su is rarely doing what you expect. It doesn't start a
new pam session and doesn't start  a systemd --user etc. etc.


Ultimately, you'll always be able to do bad things here and have process
for the wrong users in sessions if you use this kind of approach (same
for setuid binaries). The trick is to avoid doing these things if this
is not what you want! :)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] [ANNOUNCE] systemd-223 around the corner

[Colin Guthrie]

David Herrmann wrote on 23/07/15 16:28:
 Hi
 
 Following our ~2 week release plans, we intend to release v223 early
 next week. If anyone has open issues that need to be resolved before a
 release, please speak up.
 
 Right now, the changes consist of mostly bugfixes and a few
 configuration additions. I'll commit the full NEWS tomorrow.

machined thinks all machines terminate on systemctl daemon-reload
https://github.com/systemd/systemd/issues/376

This one but it seems to be on the milestone already - I take it you
don't want/need pinged about stuff that's already targeted for the
milestone?


This one would also be nice to fix too, but I only reported it yesterday
and for me at least, it's not a recent regression so no real urgency!
(although if someone on Fedora could confirm they get the problem too,
that would be nice - it may still be limited to some downstream cockup
on my part!). Not had a chance to poke into code yet, but if no-one has
time for this release, I'll try and do that for 224.

systemctl reload-or-try-restart does not fail silently as per documentation
https://github.com/systemd/systemd/issues/688



Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] How to properly write an umbrella unit

[Colin Guthrie]

Marc Haber wrote on 21/07/15 12:43:
 Hi,
 
 I am trying to systemd'ize a daemon which is useful to be run in two
 instances. It is usually the case that both instances need to be
 started and stopped simultaneously, and the local admin would want a
 _single_ command to start and stop both instances. Therefore, an
 umbrella is needed.
 
 As a beginner, I have written:
 
 nifty.target:
 [Unit]
 Description=nifty Server (all protocols)
 After=network.target
 
 [Install]
 WantedBy=multi-user.target
 
 
 nifty-v4.service:
 [Unit]
 Description=nifty Server for IPv4 (niftyd4.conf)
 After=network.target
 PartOf=nifty.target
 
 [Service]
 ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf
 
 [Install]
 WantedBy=nifty.target
 
 
 
 nifty-v6.service:
 [Unit]
 Description=nifty Server for IPv6
 After=network.target
 PartOf=nifty.target
 
 [Service]
 ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf
 
 [Install]
 WantedBy=nifty.target
 
 
 This works as designed. Unfortunately, my Distribution's build tools
 don't handle package-provided targets too well, and I feel that using
 a target here is kind of wrong anyway.

In this case, I'd perhaps recommend NOT including [Install] sections fir
your two .service files and instead make your make install action
write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus
the user could never disable the individual components of your daemon
themselves and thus not need to rely on distro scripts to create them at
install time.

Your package install script would still have to enable (or preset) the
nifty.target however.

This might or might not be desirable overall (in the example above, I
can imagine someone still wanting to disable only the IPv6 component for
example!).

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Confusing journal information - journal size

[Colin Guthrie]

David Sommerseth wrote on 17/07/15 14:28:
 On 17/07/15 13:31, Mantas Mikulėnas wrote:
 On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com
 mailto:dav...@redhat.com wrote:


 Hi,

 I'm looking through some journals now, and even though I've seen it a
 few times I haven't thought about it until now.

systemd-journal[1151]: Runtime journal is using 8.0M (max allowed
  4.0G, trying to leave 4.0G free of 63.7G available →
  current limit 4.0G).

 Could this line be cleaned up so you don't have to look up a man page to
 try to figure out what this really means?  Here's my uneducated guess
 and confusion of this line:

 * Runtime journal is using 8.0M
   - Okay, so currently the journal uses 8MB of disk-space.  No problem.

 * max allowed 4.0G
   - Okay, so the journal should not grow beyond 4GB, makes sense.  No
 problem.

 * trying to leave 4.0G free of 63.7G available
   - Uhm, what!? So it will grow until there is 4GB left on the
 filesystem?  Not so okay.


 It chooses the /smallest/ limit, not largest. (Common sense...) For
 example, if you had only 5 GB space available, the journal would not
 grow beyond 1 GB.
  

 * current limit 4.0G
   - Ehh ... okay ... so make up your mind, please!  So will the
 journal grow until 4GB or 59.7GB.


 This *is* it making up its mind: min(limit 1, limit 2) → resulting limit

 But then I looked into /var/log/journal ...

   # du --si -s /var/log/journal/
   4.3G  /var/log/journal/

 I do see that both system,journal and user-UID.journal are both 8.4MB,
 and from that I can guess what the log entry tried to tell me with
 Runtime journal ... but how is /that/ information useful for me, from
 a sys-admin point of view?


 Runtime here means /run, as opposed to persistent in /var. They have
 separately configurable limits, since /run is in RAM and /var is usually
 on disk. (Though, I'm not entirely sure what purpose the runtime journal
 even serves, when /var is available.)
 
 Fair enough.  But you are missing my point.
 
 How this information is presented do require some detail knowledge of
 the journal.  Don't think like a developer who have poked at the journal
 code.  Think like a sys-admin who looks through the logs looking for
 issues.  Then you want to have the answer straight in your face, not
 needing to go elsewhere to read about these things.  In fact most admins
 will probably have forgotten what they were going to look for when they
 move their eyes of the log data.
 
 If it is considered important information, fine.  But present it in a
 far more understandable way for those who just uses the journal.  Right
 now, I'm not surprised if most sys-admins read that line as useless
 gibberish - Yeah, yeah, journal will waste some space on my drive.

Yeah, I can't disagree with David. Not sure how best to tidy it up, but
some rework would definitely be nice.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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