Re: [systemd-devel] Moving a service from one systemd slice to another..

[Lennart Poettering]

On Mi, 06.05.20 22:05, Tomasz Torcz (to...@pipebreaker.pl) wrote:

> On Wed, May 06, 2020 at 05:18:34PM +0200, Lennart Poettering wrote:
> > On Mo, 04.05.20 08:31, Tomasz Torcz (to...@pipebreaker.pl) wrote:
> >
> > > On Mon, May 04, 2020 at 11:52:37AM +0530, nitish nagesh wrote:
> > > > Hello,
> > > >
> > > >We have this odd want to move a daemon between different systemd 
> > > > slices.
> > > > Not sure if that's even a valid thing to do, but here is the 
> > > > requirement.
> > >
> > >   You can use low-level cgroup access to move it. Something like:
> > > systemctl show --property MainPID --value your.service >
> > > /sys/fs/cgroup/NEW.slice/cgroup.procs
> >
> > You void your warranty if you do that. Moreover, on cgroupvs2 this
> > doesn't work really, since inner cgroups cannot have processes and
> > slices are by definition inner cgroups.
>
>   Doesn't work? I beg to differ, the following is on Fedora 31:
>
> Control group /:
> -.slice
> ├─kodi.slice
> │ └─2872766 /usr/lib64/kodi/kodi-wayland  ← here it has process

Sure, if you have an empty slice (i.e. with no unit associated) then
you can attach processes instead, because it is a leaf node too.

The cgroupsv2 rule is: only leaf cgroups may contain processes. You
cannot have populated child cgroups and processes on the same level.

>  Is there an API in systemd to move specific program to a dedicated
>  slice?

Use Slice= in the service file.

> I know recent gnome-shell starts every application in dedicate scope,
> but it's under *user* instance. Which means:
> – no ability to increase priority of program in such scope
> - still fights over resources with other user scopes, and other users in
>   general.

Yeah, it's a model of strict resource delegation: of the resources PID
1 has it passes a subset to a specific user. The user then can
distribute it further among its services and so on. But under no
circumstances could a user's service gain more resources than what the
user as a whole gets assigned.

>   In my usecase, I've created a top-level .slice for Kodi player. I want
> it to have priority over everything on my machine - over other users'
> processes, over virtual machines, over everything in system.slice.
> I achieve it by having this top-level slice with CPUShares, CPUWeight,
> BlockIOWeight, IOWeight much higher and IODeviceLatencyTargetSec
> much lower than rest of the slices.  Seems to work.

I presume you you mean a top-level slice in the system manager? If so
you need to run kodi as a system service too.

If you want to run kodi as user service, then assign your user the
resources you want to assign to kodi, and then distribute them from
there to kodi, and reduce it for the rest.

Lennart

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

Re: [systemd-devel] No DHCP server is started with DHCPServer=yes

[Lennart Poettering]

On Mi, 06.05.20 23:43, Francis Moreau (francis.m...@gmail.com) wrote:

> Hi,
>
> I'm running systemd v245 (in the host and in the containers) and I
> have 2 containers whose veth link is connected to a bridge.
>
> One container named "c1" uses "DHCPServer=yes" and is supposed to
> provide an ipv4 address to the second container "c2" but for some
> reasons it seems that no DHCP server is started in "c1". At least
> "journalctl -u systemd-networkd | grep DHCP" doesn't show anything
> interesting although the debug logs have been enabled.
>
> I monitored the DHCP traffic in "c1" andI could see the DISCOVER
> requests sent by "c2" but no answer from "c1". So it really seems that
> no DHCP server is running in "c1".
>
> Could anybody tell me how I could make sure that no DHCP server has
> been started and help me understanding why ?

Are you sure your .network files match on the iface properly? What
does "networkctl status" say about the interface?

Lennart

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

[systemd-devel] No DHCP server is started with DHCPServer=yes

[Francis Moreau]

Hi,

I'm running systemd v245 (in the host and in the containers) and I
have 2 containers whose veth link is connected to a bridge.

One container named "c1" uses "DHCPServer=yes" and is supposed to
provide an ipv4 address to the second container "c2" but for some
reasons it seems that no DHCP server is started in "c1". At least
"journalctl -u systemd-networkd | grep DHCP" doesn't show anything
interesting although the debug logs have been enabled.

I monitored the DHCP traffic in "c1" andI could see the DISCOVER
requests sent by "c2" but no answer from "c1". So it really seems that
no DHCP server is running in "c1".

Could anybody tell me how I could make sure that no DHCP server has
been started and help me understanding why ?

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

Re: [systemd-devel] Moving a service from one systemd slice to another..

[Tomasz Torcz]

On Wed, May 06, 2020 at 05:18:34PM +0200, Lennart Poettering wrote:
> On Mo, 04.05.20 08:31, Tomasz Torcz (to...@pipebreaker.pl) wrote:
> 
> > On Mon, May 04, 2020 at 11:52:37AM +0530, nitish nagesh wrote:
> > > Hello,
> > >
> > >We have this odd want to move a daemon between different systemd 
> > > slices.
> > > Not sure if that's even a valid thing to do, but here is the requirement.
> >
> >   You can use low-level cgroup access to move it. Something like:
> > systemctl show --property MainPID --value your.service >
> > /sys/fs/cgroup/NEW.slice/cgroup.procs
> 
> You void your warranty if you do that. Moreover, on cgroupvs2 this
> doesn't work really, since inner cgroups cannot have processes and
> slices are by definition inner cgroups.

  Doesn't work? I beg to differ, the following is on Fedora 31:

Control group /:
-.slice
├─kodi.slice
│ └─2872766 /usr/lib64/kodi/kodi-wayland  ← here it has process
├─user.slice
│ ├─user-1001.slice
│ ├─user-0.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ └─init.scope
│   │   ├─2914978 /usr/lib/systemd/systemd --user
│   │   └─2914990 (sd-pam)
│   ├─session-356.scope
│   │ └─2915060 /usr/libexec/openssh/sftp-server
│   └─session-354.scope
│ └─2915015 /usr/libexec/openssh/sftp-server
├─init.scope
│ └─1 /usr/lib/systemd/systemd --system --deserialize 214
├─system.slice
│ ├─rngd.service
│ ├─abrt-oops.service
[…]
│ └─smokeping.service
│   ├─5423 /usr/bin/perl /usr/sbin/smokeping --nodaemon
│   ├─7804 /usr/sbin/smokeping [FPing]
│   └─7805 /usr/sbin/smokeping [FPing6]
└─machine.slice
  ├─machine-qemu\x2d67\x2dkaitain.scope
  │ ├─2905751 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=kaitai…
  │ ├─vcpu0
  │ └─emulator
  ├─machine-qemu\x2d9\x2dnaib.scope
[…]

 (heavily trimmed, but shows the idea)

> There is supposed to be only one manager of the top-level cgroup
> tree. On systemd systems. If you muck with the cgroup tree anyway you
> are interfering with systemd#s management and things will fall apart
> sooner or later.
> if you want to muck around in the cgroup tree, acquire a delegated
> cgroup subtree, where you can do whatever you want.

 Is there an API in systemd to move specific program to a dedicated slice?
I know recent gnome-shell starts every application in dedicate scope,
but it's under *user* instance. Which means:
– no ability to increase priority of program in such scope
- still fights over resources with other user scopes, and other users in
  general.

  In my usecase, I've created a top-level .slice for Kodi player. I want
it to have priority over everything on my machine - over other users'
processes, over virtual machines, over everything in system.slice.
I achieve it by having this top-level slice with CPUShares, CPUWeight,
BlockIOWeight, IOWeight much higher and IODeviceLatencyTargetSec
much lower than rest of the slices.  Seems to work.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|

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

Re: [systemd-devel] network-online.target time

[Peter Morrow]

On Wed, 2020-05-06 at 17:51 +0200, Lennart Poettering wrote:
> On Mi, 06.05.20 15:50, Peter Morrow (
> peter.mor...@microsoft.com
> ) wrote:
> 
> > On Wed, 2020-05-06 at 17:39 +0200, Lennart Poettering wrote:
> > > On Mi, 22.04.20 14:44, Peter Morrow (
> > > peter.mor...@microsoft.com
> > > 
> > > ) wrote:
> > > 
> > > > Hi Folks,
> > > > 
> > > > I'm trying to optimise our boot process and have started to
> > > > look at
> > > > the time it takes for the network to come up (a single
> > > > interface to
> > > > be
> > > > routable) when using systemd-networkd:
> > > > 
> > > > Can anyone offer any suggestions for where I should look to try
> > > > to
> > > > speed things up here?
> > > 
> > > Turn on debug logging for networkd. it should tell you what it is
> > > doing, and the timestamps should allow you to determine what
> > > precisely
> > > is being waited for.
> > 
> > Thanks. Yes - I ended up doing this and it turned out much of the
> > additional time is down to ipv6 interface
> > configuration.  Specifically
> > ipv6 link local duplicate address detection.
> 
> You can turn that off if you like: IPv6DuplicateAddressDetection=

This option worked well when I tried it (total time came down to
~700ms) but unfortunately disabling it entirely isn't an option.

FWIW setting CONFIG_IPV6_OPTIMISTIC_DAD=y in the kernel is providing a
good middle ground.

Peter.


> Lennart
> 
> --
> Lennart Poettering, Berlin


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

Re: [systemd-devel] network-online.target time

[Peter Morrow]

On Wed, 2020-05-06 at 17:39 +0200, Lennart Poettering wrote:
> On Mi, 22.04.20 14:44, Peter Morrow (
> peter.mor...@microsoft.com
> ) wrote:
> 
> > Hi Folks,
> > 
> > I'm trying to optimise our boot process and have started to look at
> > the time it takes for the network to come up (a single interface to
> > be
> > routable) when using systemd-networkd:
> > 
> > Can anyone offer any suggestions for where I should look to try to
> > speed things up here?
> 
> Turn on debug logging for networkd. it should tell you what it is
> doing, and the timestamps should allow you to determine what
> precisely
> is being waited for.

Thanks. Yes - I ended up doing this and it turned out much of the
additional time is down to ipv6 interface configuration.  Specifically
ipv6 link local duplicate address detection.

Peter.

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 

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

Re: [systemd-devel] Requested transaction contradicts existing jobs: start is destructive

[Kumar Kartikeya Dwivedi]

On Wed, 6 May 2020 at 15:58, Mark Bannister  wrote:
>
> I repeated the exact same test with a different user account, one
> set-up specifically for this test and nothing else, so there was only
> one SSH session.  But 'systemctl list-jobs' always reported 'No jobs
> running' even after the SSH session was terminated.  My script kept
> running with the parent PID of 1.  Thanks for your help so far, but I
> have still been unable to reproduce the problem.  What am I doing
> wrong?
>

Alright, so I dug into this, and managed to reproduce it at last.

This issue is NOT reproducible with the version you reported
originally. The stock CentOS image on my cloud provider comes with the
same version (219-67.el7_7.4) that you said you see this issue with,
but that can't be, as it doesn't include this change:
https://github.com/systemd-rhel/rhel-7/commit/0600681f04e3818282a2d518ec3e6afee85f7978,
unless I'm missing something. It took me a while to figure this out...

This was added in 219-69 (see the tag). I guess you built your copy
with some custom patches, which pulled it in. This is the reason
essentially why the transaction becomes destructive. Prior to this
change, the session scope added a Wants= dependency, instead of
Requires=, on user-UID.slice, so the conflicting start job could
simply be *dropped* instead of failing the transaction on a login
attempt, but the change upgrades Slice= deps to Requires=, so they
start failing when stop is waiting and start is included in a newly
generated transaction. You can verify this with systemctl show
session-N.scope, the 219-67 says Wants=user-UID.slice, and 219-69 and
upwards say Requires=user-UID.slice.

One key thing I missed was that systemd on CentOS wouldn't clean up
the session for the user since KillUserProcesses=no by default, and
also the fact that the user slice's stop job is not added until all
session scopes finish cleaning up. So the scope is simply abandoned,
and should exist until all processes die themselves.

So, observing this issue is not easy, it would only trigger if you try
to login right when systemd tries to stop the user slice and the job
exists in queue (which is a very short window), and it took a lot of
tries before I could reproduce it (for a start I manually queued the
stop job for the slice with a hung session scope and tried logging in
to verify the transaction problem).

So this is racy in nature, the sequence of events can be that your
processes die, session scopes are gone, and now the manager will try
to shut down the user slice, and if you happen to be amidst a login at
this moment, pam_systemd's call for CreateSession would conflict with
the already waiting stop job. It doesn't matter if KillUserProcesses=
is set or not, that just decides if the scopes are cleaned up on
logout (they would become inactive when all session processes are gone
anyway). It does decide when the user-UID.slice would be stopped,
however.

The reason you didn't see any jobs was that the scope was abandoned,
and your long-lived process pinned it. So the session scope should
never stop, as a consequence neither the slice.

Here are a series of steps to widen the race (by queuing a stop job
for user slice)  and reproduce it:
1. Create a script badproc.sh; chmod +x badproc.sh
#!/bin/bash
trap "" SIGHUP
trap "" SIGINT
trap "" SIGTERM
exec "$@"

2. From user's shell, do: ./badproc.sh sleep infinity &; disown; ^D (logout)
The scope is now abandoned, or being stopped (if KillUserProcesses=yes)
3. From root's shell, do:
systemctl --no-block stop session-N.scope; systemctl --no-block stop
user-UID.slice;
systemctl list-jobs should list both jobs, the scope job as running,
and the slice job as waiting.

The sequence that actually happens is processes dying, (last) session
scope stopping, user slice stopping, in order. The point at which it
fails is the user slice stopping, which is a very very short time
window, so it makes sense if you only see these sporadically.

4. Try a login, which gives me:
May 06 17:03:12 systemd[1]: Requested transaction contradicts existing
jobs: Transaction is destructive.
May 06 17:03:12 sshd[3134]: pam_systemd(sshd:session): Failed to
create session: Resource deadlock avoided
May 06 17:03:12 systemd-logind[3078]: Failed to start session scope
session-37.scope: Transaction is destructive.

All in all, you can't do much about these errors, they're mostly
harmless (at worst you need to retry the login), and upgrading to v228
(the patchset mentioned in the previous exchange) or higher should fix
all of this for you.

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

Re: [systemd-devel] os-release: extension to expose host's version variables to containers

[Simon McVittie]

On Wed, 06 May 2020 at 16:39:39 +0200, Lennart Poettering wrote:
> On Do, 16.04.20 16:56, Simon McVittie (s...@collabora.com) wrote:
> > /run/host seems like a reasonable convention to encourage for
> > container/host systems that want this, since it doesn't require
> > inventing a new top-level directory.
> 
> I am not opposed adding something similar to nspawn, using the same
> paths. Only issue I see: docker doesn't acknowledge the existance of
> /run inside the container iirc, i.e. doesn't pre-mount it, hence
> passing data in via some subdir in /run is weird...

I suspect Docker itself probably isn't going to implement this interface,
because it doesn't generally acknowledge the existence of non-Docker
container frameworks, and sharing information from the host with the
container is pretty much the opposite of its philosophy in any case.

If *users of Docker* want to implement this interface, they can do so
with something like

docker run \
--mount type=tmpfs,tmpfs-mode=0755 \
--mount type=bind,src=/etc/os-release,dst=/run/host/etc/os-release,ro \
...

in much the same way they can implement the "/run is a tmpfs"
interface, or the various desirable properties listed in
, by giving Docker suitable
options.

They'd have to pass similar options to Docker to get /host (which was the
original suggestion in this thread), so the conventional directory might
as well be one that doesn't need to invent new top-level directories?

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

Re: [systemd-devel] network-online.target time

[Lennart Poettering]

On Mi, 06.05.20 15:50, Peter Morrow (peter.mor...@microsoft.com) wrote:

> On Wed, 2020-05-06 at 17:39 +0200, Lennart Poettering wrote:
> > On Mi, 22.04.20 14:44, Peter Morrow (
> > peter.mor...@microsoft.com
> > ) wrote:
> >
> > > Hi Folks,
> > >
> > > I'm trying to optimise our boot process and have started to look at
> > > the time it takes for the network to come up (a single interface to
> > > be
> > > routable) when using systemd-networkd:
> > >
> > > Can anyone offer any suggestions for where I should look to try to
> > > speed things up here?
> >
> > Turn on debug logging for networkd. it should tell you what it is
> > doing, and the timestamps should allow you to determine what
> > precisely
> > is being waited for.
>
> Thanks. Yes - I ended up doing this and it turned out much of the
> additional time is down to ipv6 interface configuration.  Specifically
> ipv6 link local duplicate address detection.

You can turn that off if you like: IPv6DuplicateAddressDetection=

Lennart

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

Re: [systemd-devel] How to figure out what's causing systemd to start printing messages partway through boot?

[McKay, Sean]

Hi Lennart,

I've had debug logging on for a while (it's mentioned in my first email, but I 
concede that was rather long). Unfortunately, I will admit to not being 
particularly familiar with dbus or the signals I should be looking for.

Is there a direction you could point me in (either documentation, or even in 
the code itself) that would help me familiarize myself with them so I can 
follow what's happening to try to figure out what could be changing that value?

The part that I really don't understand is that the only place that I can find 
where the value seems to be modified is in the manager_set_show_status 
function. That function has a debug log in it, but when I enable debug logging, 
it's nowhere to be found in the journal despite the value being toggled from 
auto to temporary.

Cheers!
-Sean

-Original Message-
From: Lennart Poettering  
Sent: Wednesday, May 6, 2020 8:09 AM
To: McKay, Sean 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to figure out what's causing systemd to start 
printing messages partway through boot?

On Mi, 29.04.20 23:26, McKay, Sean (sean.mc...@hpe.com) wrote:

> Do you have any guidance on what I should look at to determine what is 
> causing the show_status variable in systemd to get flipped to true 
> without any apparent unit failures? Is there an easy way to find that 
> information?

Maybe something asks systemd to? Consider enabling debug logging with 
"systemd.log_level=debug" on the kernel cmdline. It will then print information 
about incoming dbus msgs which might cause this, as well as signals it receives 
that might cause it.

Lennart

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

Re: [systemd-devel] network-online.target time

[Lennart Poettering]

On Mi, 22.04.20 14:44, Peter Morrow (peter.mor...@microsoft.com) wrote:

> Hi Folks,
>
> I'm trying to optimise our boot process and have started to look at
> the time it takes for the network to come up (a single interface to be
> routable) when using systemd-networkd:
>
> Can anyone offer any suggestions for where I should look to try to
> speed things up here?

Turn on debug logging for networkd. it should tell you what it is
doing, and the timestamps should allow you to determine what precisely
is being waited for.

Lennart

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

Re: [systemd-devel] Moving a service from one systemd slice to another..

[Lennart Poettering]

On Mo, 04.05.20 08:31, Tomasz Torcz (to...@pipebreaker.pl) wrote:

> On Mon, May 04, 2020 at 11:52:37AM +0530, nitish nagesh wrote:
> > Hello,
> >
> >We have this odd want to move a daemon between different systemd slices.
> > Not sure if that's even a valid thing to do, but here is the requirement.
>
>   You can use low-level cgroup access to move it. Something like:
> systemctl show --property MainPID --value your.service >
> /sys/fs/cgroup/NEW.slice/cgroup.procs

You void your warranty if you do that. Moreover, on cgroupvs2 this
doesn't work really, since inner cgroups cannot have processes and
slices are by definition inner cgroups.

There is supposed to be only one manager of the top-level cgroup
tree. On systemd systems. If you muck with the cgroup tree anyway you
are interfering with systemd#s management and things will fall apart
sooner or later.

if you want to muck around in the cgroup tree, acquire a delegated
cgroup subtree, where you can do whatever you want.

Lennart

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

Re: [systemd-devel] Moving a service from one systemd slice to another..

[Lennart Poettering]

On Mo, 04.05.20 11:52, nitish nagesh (nagesh.nit...@gmail.com) wrote:

> Hello,
>
>We have this odd want to move a daemon between different systemd slices.
> Not sure if that's even a valid thing to do, but here is the
> requirement.

The Linux kernel gets a bit confused with accounting if you migrate
running processes between cgroups. One usually shouldn't do that
except when forking off/execing new stuff.

>The daemon while booting up belongs to a systemd slice (say X) which has
> parameters like startupCPUShares tuned to bring the system up faster.
> However for normal operations after bootup, it would be apt to make it
> belong to another slice (say Y) with different cgroup parameters
> configurations (ex: CPUShares). The set of daemons that belong to X and Y
> are totally different, except for this one daemon. Also the cgroup
> parameter that are set via slice Y are totally different than those set via
> slice X.

This is not supported. In systemd you can migrate services between
slices only by stopping them and starting them again.

>   A few basic questions:
> - Can a daemon be a part of 2 slices?

no.

> - If yes, going by the example above, if slice X loads first followed by
> slice Y, does it mean when slice X is in force this daemon will have
> startUpCPUShares set & when slice Y is loaded the CPUShares will be
> set?

I don't grok this, sorry.

>Please suggest if there are alternate ways in systemd to handle this
> requirement.

We don't support that. Slice assignments are sticky during service
runtime.

Lennart

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

Re: [systemd-devel] why is systemd-remount-fs.service needed in stage-2?

[Lennart Poettering]

On So, 03.05.20 23:03, Arian Van Putten (ar...@wire.com) wrote:

> Hey list,
>
> I'm in the process of experimenting with a systemd-based initrd.
> However I have two questions concerning the boot process that came up
> whilst reading the documentation.
>
> If I understand "man 7 bootup" correctly so far  the initrd mounts /sysroot
> based on either the root= kernel parameter or through gpt-auto-generator.
> At this point /sysroot is mounted. However /sysroot/etc/fstab might have
> additional entries that need to be mounted in the initrd (marked with
> "x-initrd").
> Next "initrd-parse-etc.service" gets triggered which runs fstab-generator
> which then mounts all the entries marked with "x-initrd".
> If "/usr" is in a separate partition; I would expect it to _need_ to be
> marked "x-initrd" as you want /usr to be present as soon as you boot up the
> system. And this causes the "sysroot-usr.mount" unit to be generated and
> gets pulled in by "initrd-fs.target".

IIRC we imply x-initrd for /usr.

> We're now ready to switch-root to the root-filesystem and move to stage-2.
>
> In stage-2, in early boot.  "systemd-remount-fs.service" runs;  which
> remounts / and /usr with the actual options in /etc/fstab.
>
> Two questions about this:
>
> 1.  if sysroot-usr.mount already gets pulled in in the initrd by parsing
> /sysroot/etc/fstab why do we need to remount /usr   in stage-2 with
> "systemd-remount-fs.service"? Didn't we already parse the correct values
> from fstab, and hence /usr is already guaranteed to be correctly
> mounted?

Two reasons:

1) To cover for non-initrd systems or systems using yesteryear's
   (i.e. non-systemd) initrds.

2) Also, it's for applying mount options to /run, /sys, /proc and
   suchlike, i.e. API VFS which are mounted by systemd itself natively
   early on without any fstab entry, but if the user wants exotic
   mount options can list in fstab too.

> 2. relatedly;  why cant after "initrd-parse-etc.service" is run
> sysroot.mount  be retriggered with the new options parsed from
> /sysroot/etc/fstab as well?  Then to me it sounds like
> "systemd-remount-fs.service" is not needed at all for / and /usr. (though
> maybe still for /sys and /proc)

Yeah, but /sys and /proc and /run do matter.

> My gut feeling the answer to this question is "not all initrd's use
> systemd; so they might not parse /sysroot/etc/fstab so early we need to
> account for that". Is that the case?

Yes, partially, see above.

Lennart

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

Re: [systemd-devel] How to figure out what's causing systemd to start printing messages partway through boot?

[Lennart Poettering]

On Mi, 29.04.20 23:26, McKay, Sean (sean.mc...@hpe.com) wrote:

> Do you have any guidance on what I should look at to determine what
> is causing the show_status variable in systemd to get flipped to
> true without any apparent unit failures? Is there an easy way to
> find that information?

Maybe something asks systemd to? Consider enabling debug logging with
"systemd.log_level=debug" on the kernel cmdline. It will then print
information about incoming dbus msgs which might cause this, as well
as signals it receives that might cause it.

Lennart

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

Re: [systemd-devel] A way to debug machine shutdown

[Lennart Poettering]

On So, 26.04.20 19:08, Dark Penguin (darkpeng...@yandex.com) wrote:

> Very often I have encountered one problem: during shutdown, systemd has
> to wait for something. Of course, it is probably different things every
> time, and it is probably not systemd's fault, at least some of the cases.
>
> This leads to the question: how do we find out the root of the problem?
> Systemd has a lot of good tools for debugging, but using them is not as
> easy as it seems, and the Internet is not much help either.
>
> Naturally, reading the output and the journal would be the first step.
> On the screen, it was "A stop job is running for session 1 of user
> myuser". In the journal, there is:
>
> Apr 26 18:46:56 DEUS systemd[1]: session-1.scope: Stopping timed out.
> Killing.
> Apr 26 18:46:56 DEUS systemd[1]: session-1.scope: Failed with result
> 'timeout'.
> Apr 26 18:46:56 DEUS systemd[1]: Stopped Session 1 of user myuser.
> Apr 26 18:46:56 DEUS systemd[1]: Stopping Login Service...
> Apr 26 18:46:56 DEUS systemd[1]: Stopping User Manager for UID 1000...
> Apr 26 18:46:56 DEUS systemd-logind[809]: Removed session 1.
>
> Now how do I check exactly what was the problem in that session?

Which systemd version is this?

Current versions (since ~231 iirc) of systemd log about the processes
they kill due to timeouts. You should find that in the logs.

There's also:

https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Lennart

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

Re: [systemd-devel] os-release: extension to expose host's version variables to containers

[Lennart Poettering]

On Do, 16.04.20 16:56, Simon McVittie (s...@collabora.com) wrote:

> On Thu, 16 Apr 2020 at 14:03:43 +, Luca Boccassi wrote:
> > But I found at least one other use case where this is needed, and the
> > solution there is to add a new directory /host/ which replicates part
> > of the host's filesystem tree, including os-release:
> >
> > https://docs.netdata.cloud/packaging/docker/#run-netdata-with-the-docker-command
> > https://github.com/netdata/netdata/issues/7488
>
> Flatpak uses /run/host for similar things. Some parts of the host system
> are visible to Flatpak apps unconditionally, and some only if the Flatpak
> app has special permission flags.
>
> In particular, if a Flatpak app has the --filesystem=host permission flag
> (which is mainly intended to expose the host's /home, /srv, /media etc. in
> the container's /home, /srv, /media etc., for apps that can't be sandboxed
> properly), the host's /usr and /etc get exposed in /run/host/usr and
> /run/host/etc.
>
> In the Flatpak 1.7 development branch, I added a host-os permission,
> which puts the host /usr in /run/host/usr, the host /bin, /sbin and /lib*
> (if not /usr-merged) in /run/host/bin etc., and a small subset of /etc
> (ld.so.cache, alternatives) in /run/host/etc; and a host-etc permission,
> which puts the whole host /etc in /run/host/etc. Those can be used to
> share the host OS, without the side-effect of sharing users' personal
> files.
>
> /run/host seems like a reasonable convention to encourage for
> container/host systems that want this, since it doesn't require
> inventing a new top-level directory. The experimental pressure-vessel
> container-runner, used in Steam to run games in containers, also uses
> /run/host.
>
> That setup would automatically let apps with appropriate permissions read
> /run/host/etc/os-release and/or /run/host/usr/lib/os-release to get host
> OS properties.

I am not opposed adding something similar to nspawn, using the same
paths. Only issue I see: docker doesn't acknowledge the existance of
/run inside the container iirc, i.e. doesn't pre-mount it, hence
passing data in via some subdir in /run is weird...

Lennart

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

Re: [systemd-devel] os-release: extension to expose host's version variables to containers

[Lennart Poettering]

On Do, 16.04.20 14:03, Luca Boccassi (luca.bocca...@microsoft.com) wrote:

> Hi,
>
> We find ourselves in a situation where application running
> containerized (specifically as portable services, although this issue
> is general) need to either find information about the host, or alter
> their behaviour depending on the host's flavour.
> At the same time, applications also need to find information about the
> guest's OS, so simply bind mounting /etc/os-release from the host is
> not enough. We need both.

Hmm, usually containers are about isolation, i.e. avoiding that host
data leaks into the container as far as that's possible.

We currently pass very little info from host into container, i.e. just
the container manager's own name via the $container env var set for
PID 1 (see: https://systemd.io/CONTAINER_INTERFACE/).

I am not opposed to passing os-release into the container somehow. I
mean, effectively the info from os-release can be deduced from "uname
-a" usually, as kernel versions tend to correlate closely with distro
versions.

> I did some research and I cannot find a generalized, common solution.
> But I found at least one other use case where this is needed, and the
> solution there is to add a new directory /host/ which replicates part
> of the host's filesystem tree, including os-release:
>
> https://docs.netdata.cloud/packaging/docker/#run-netdata-with-the-docker-command
> https://github.com/netdata/netdata/issues/7488

Somewhat related but also not: nspawn has a magic dir for passing
mounts from host to container in /run/systemd/nspawn/incoming, I guess
passing info such as os-release or so into a containar is conceptually
not too different.

I think making os-release available in the container as-is would be OK
(either mounted immutable or copied in).

An alternative would be to just pass the most basic info from
os-release to the container, unconditionally, similar to the
$container stuff. i.e. just the identification bits from
/etc/os-release, i.e. introduce env vars $container_host_os,
$container_host_os_version, $container_host_os_build,
$container_host_os_variant, initialized from the various XYZ_ID=
fields from /etc/os-release. That would be simple enough to make it
something we could just declare part of the container iface and do
unconditionally. It leaks just the implementation ids into the
container but no host identifiers, and hence should be OK to do
unconditionally. Would that suffice for your usecase?

I am tempted to say this discussion is specific enough to be tracked
in a github RFE issue btw, so that we don't lose track of it.

Lennart

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

Re: [systemd-devel] sd_bus_add_match callback

[Lennart Poettering]

On Fr, 10.04.20 12:06, David J (ema...@icloud.com) wrote:

> Giacinto,
> Thanks for further explaining my email.
>
> Lennart,

> Thank you for your feedback. What I am doing is writing an sd-bus
> interface and a client code, which is only interested in specific
> signal information. So the interface has to offer minimal API’s. The
> interface has one callback to handle all the signal callbacks,
> processes the messages and populates the information for the client
> code. If you have a better resolution please share.

"one callback to handle all the signal callbacks"? Not getting it?

You can register the same function as many times as you want for
different match expressions with different (and with the same, too)
user data ptr, it's up to you. What function you pass and what
userdata ptr you pass is entirely your own choice. All sd-bus ensures
is that for every matching incoming signal message your function will
be called as many times as it is registered.

i.e. if you'd use sd_bus_add_match() five times in a row with the
identical callback function ptrs and userdata ptrs then for each
matching incoming signal msg your function would be called five times,
each time with the same userdata ptr, i.e. the one you specified.

Lennart

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

[systemd-devel] Antw: Re: EXT :Antw: [EXT] Udev Regex

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 06.05.2020 um 15:43
in
Nachricht <20200506134333.GC89018@gardel-login>:
> On Mi, 06.05.20 13:03, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com)
wrote:
> 
>> Ulrich,
>>
>> I just noticed that too.  This seems rather restrictive given that one
could 
> have a system with many drives, and with GPT it is not unreasonable to have
a 
> large number of partitions as well.
>>
>> There should be a way in udev to write rules that can distinguish between 
> /dev/sda and /dev/sdzfe87.  Matching with sd[a‑z]* or even sd* does not 
> provide enough granularity.
>>
>> What would it take to get this sort of request in to systemd‑udev to
>> support perl style regular expressions that can group terms and
>> match multiple instances of a group with '+'?
> 
> I am sorry, but no. We are talking about device nodes, i.e. file
> objects in the file system tree. It's generally understood that files
> are matched with globs, not regexes.

The manual says:

   PROGRAM
   Execute a program to determine whether there is a match; the key
is
   true if the program returns successfully. The device properties
are
   made available to the executed program in the environment. The
   program's standard output is available in the RESULT key.

   This can only be used for very short-running foreground tasks. For
   details, see RUN.

So a short C program might help to solve the problem.

> 
> There are things where regexes might be fine, but not matching of file
> names.
> 
> Or to say this differently: as soon as you convinced bash to replace
> its glob matching with regex matching we can consider this for udev
> too.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

Re: [systemd-devel] EXT :Re: Antw: [EXT] Udev Regex

[Boyce, Kevin P [US] (AS)]

So therefore udev should be able to make use of extended globbing...?

-Original Message-
From: Andrei Borzenkov  
Sent: Wednesday, May 06, 2020 9:49 AM
To: Lennart Poettering 
Cc: Boyce, Kevin P [US] (AS) ; 
systemd-devel@lists.freedesktop.org
Subject: EXT :Re: [systemd-devel] Antw: [EXT] Udev Regex

On Wed, May 6, 2020 at 4:43 PM Lennart Poettering  
wrote:
>
> On Mi, 06.05.20 13:03, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com) wrote:
>
> > Ulrich,
> >
> > I just noticed that too.  This seems rather restrictive given that one 
> > could have a system with many drives, and with GPT it is not unreasonable 
> > to have a large number of partitions as well.
> >
> > There should be a way in udev to write rules that can distinguish between 
> > /dev/sda and /dev/sdzfe87.  Matching with sd[a-z]* or even sd* does not 
> > provide enough granularity.
> >
> > What would it take to get this sort of request in to systemd-udev to 
> > support perl style regular expressions that can group terms and 
> > match multiple instances of a group with '+'?
>
> I am sorry, but no. We are talking about device nodes, i.e. file 
> objects in the file system tree. It's generally understood that files 
> are matched with globs, not regexes.
>
> There are things where regexes might be fine, but not matching of file 
> names.
>
> Or to say this differently: as soon as you convinced bash to replace 
> its glob matching with regex matching we can consider this for udev 
> too.
>


bash already does it if extglob is set.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT :Antw: [EXT] Udev Regex

[Andrei Borzenkov]

On Wed, May 6, 2020 at 4:43 PM Lennart Poettering
 wrote:
>
> On Mi, 06.05.20 13:03, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com) wrote:
>
> > Ulrich,
> >
> > I just noticed that too.  This seems rather restrictive given that one 
> > could have a system with many drives, and with GPT it is not unreasonable 
> > to have a large number of partitions as well.
> >
> > There should be a way in udev to write rules that can distinguish between 
> > /dev/sda and /dev/sdzfe87.  Matching with sd[a-z]* or even sd* does not 
> > provide enough granularity.
> >
> > What would it take to get this sort of request in to systemd-udev to
> > support perl style regular expressions that can group terms and
> > match multiple instances of a group with '+'?
>
> I am sorry, but no. We are talking about device nodes, i.e. file
> objects in the file system tree. It's generally understood that files
> are matched with globs, not regexes.
>
> There are things where regexes might be fine, but not matching of file
> names.
>
> Or to say this differently: as soon as you convinced bash to replace
> its glob matching with regex matching we can consider this for udev
> too.
>


bash already does it if extglob is set.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] IdleAction=lock not working in ubuntu

[Archana Polampalli]

4.IdleAction=lock does it work in tty console .

-Original Message-
From: Archana Polampalli 
Sent: Wednesday, May 6, 2020 2:52 PM
To: 'Archana Polampalli' ; Lennart Poettering 

Cc: systemd-devel@lists.freedesktop.org
Subject: RE: [systemd-devel] IdleAction=lock not working in ubuntu

Hi Lennart ,
I have few more questions,

1.I have run $loginctl lock-session  command in gnome DE,it is 
locking the session. and why it is not locking through logind.conf parameters.

2.As per my investigation on session locking,  logind uses DBus to propagate 
the "Lock" event .we will need an application that listens for those events for 
ex.xss-lock,GDM,SDDM So I have installed xss-lock though I found same behavior  

2.May I know which Desktop Environment support locking logic 1.Gnome 2.Mate 
3.Lxde 4.Jwm


Thank in advance 

Regards,
Archana
-Original Message-
From: systemd-devel  On Behalf Of 
Archana Polampalli
Sent: Wednesday, May 6, 2020 2:25 PM
To: Lennart Poettering 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] IdleAction=lock not working in ubuntu

Thank you very much for the prompt reply

 I am using 'gnome' Desktop Environment

Regards,
Archana

-Original Message-
From: Lennart Poettering 
Sent: Wednesday, May 6, 2020 2:14 PM
To: Archana Polampalli 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] IdleAction=lock not working in ubuntu

On Mi, 06.05.20 06:40, Archana Polampalli (archana.c...@toshiba-tsip.com) wrote:

> Hi All,
>
> My requirement is my system should get locked automatically when the system 
> is idle for 5min.
> So for this I have configured /etc/system/logind.conf file as 
> IdleAction = lock IdleActionSec=2min
>
> And I restarted systemd service with  'setemctl restart 
> system-logind.service' and I kept my system idle for more than 
> 20min,but system not getting locked .and IdleAction = poweroff 
> IdleActionSec=2min Is working ,but lock not working,what I am missing here.
> Please any one can  help me at your earliest convenience .

Which desktop environment are you using? Not all DEs support the locking logic 
and simply ignore it.

Lennart

--
Lennart Poettering, Berlin
The information contained in this e-mail message and in any 
attachments/annexure/appendices is confidential to the recipient and may 
contain privileged information. 
If you are not the intended recipient, please notify the sender and delete the 
message along with any attachments/annexure/appendices. You should not 
disclose, copy or otherwise use the information contained in the message or any 
annexure. Any views expressed in this e-mail are those of the individual sender 
except where the sender specifically states them to be the views of Toshiba 
Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be free of any 
virus or other defect that might affect any computer system into which it is 
received and opened, it is the responsibility of the recipient to ensure that 
it is virus free and no responsibility is accepted by Toshiba Embedded Software 
India Pvt. Ltd, for any loss or damage arising in any way from its use.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

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

Re: [systemd-devel] EXT :Antw: [EXT] Udev Regex

[Lennart Poettering]

On Mi, 06.05.20 13:03, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com) wrote:

> Ulrich,
>
> I just noticed that too.  This seems rather restrictive given that one could 
> have a system with many drives, and with GPT it is not unreasonable to have a 
> large number of partitions as well.
>
> There should be a way in udev to write rules that can distinguish between 
> /dev/sda and /dev/sdzfe87.  Matching with sd[a-z]* or even sd* does not 
> provide enough granularity.
>
> What would it take to get this sort of request in to systemd-udev to
> support perl style regular expressions that can group terms and
> match multiple instances of a group with '+'?

I am sorry, but no. We are talking about device nodes, i.e. file
objects in the file system tree. It's generally understood that files
are matched with globs, not regexes.

There are things where regexes might be fine, but not matching of file
names.

Or to say this differently: as soon as you convinced bash to replace
its glob matching with regex matching we can consider this for udev
too.

Lennart

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

Re: [systemd-devel] EXT :Antw: [EXT] Udev Regex

[Boyce, Kevin P [US] (AS)]

Ulrich,

I just noticed that too.  This seems rather restrictive given that one could 
have a system with many drives, and with GPT it is not unreasonable to have a 
large number of partitions as well.

There should be a way in udev to write rules that can distinguish between 
/dev/sda and /dev/sdzfe87.  Matching with sd[a-z]* or even sd* does not provide 
enough granularity.

What would it take to get this sort of request in to systemd-udev to support 
perl style regular expressions that can group terms and match multiple 
instances of a group with '+'?

Kevin

-Original Message-
From: Ulrich Windl  
Sent: Wednesday, May 06, 2020 8:41 AM
To: systemd-devel@lists.freedesktop.org; Boyce, Kevin P [US] (AS) 

Subject: EXT :Antw: [EXT] [systemd-devel] Udev Regex

>>> "Boyce, Kevin P [US] (AS)"  schrieb am 
>>> 06.05.2020 um
14:15
in Nachricht
<16534_1588767787_5EB2AC2A_16534_16_1_d2c2e1aff05740ea9d1ea3e1325511b2@XCGVAG30.
orthgrum.com>:
> Good Morning List,
> 
> Does anyone know how complicated of a regular expression can be 
> utilized in

> a udev rule?
> 
> For instance I have a system with a lot of drives (sda through z 
> aren't
> enough) and I want to write a rule that will match the physical block
devices 
> for one rule and then a separate rule for partitions.
> 
> Something like this, however the rules don't seem to fire except when 
> I remove the '+' from the rules:

The man page udev(7) I have lists '[', ']', '|', '*' and '?', but not '+'...

> ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a‑z]+",
> SYMLINK+="some_device_%k"
> ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a‑z]+[0‑9]+",
> SYMLINK+="some_device_%k"
> 
> I am running systemd version 219‑67.
> 
> Kind Regards,
> Kevin



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

Re: [systemd-devel] systemd service fails to start rhel7.8

[Lennart Poettering]

On Di, 05.05.20 08:48, Aviram, Nimrod (navi...@bottomline.com) wrote:

> HI,
>
> I've been using the following service to control our catalane server for the 
> past few years now.
> After upgrading OS to RHEL 7.8 , the service fails to start.
> I'm usually creating a basic user (cfrm) to run Catalina but I've also tried 
> with root and received the same exception.
> I know that  something was changed in systemd but I can't figure out how to 
> fix this.
> Any help will be appreciated.
>
> [Unit]
> Description=cfrmic
> [Service]
> User=cfrm

So, you run the service as "cfrm" user already, i.e. unprivileged.

> Environment=JAVA_HOME=$JAVA_HOME

As others mentioned, this makes no sense, unit files will not evaluate
env vars, and even if it would assigned a variable's value to the
variable is kinda pointless, no?

> May 05 04:45:13 US02VLAPP8519 su[2249]: pam_unix(su-l:auth): auth could not 
> identify password for [cfrm]
> May 05 04:45:13 US02VLAPP8519 su[2249]: pam_sss(su-l:auth): authentication 
> failure; logname= uid=1001 euid=0 tty= ruser=cfrm rhost= user=cfrm
> May 05 04:45:13 US02VLAPP8519 su[2249]: pam_sss(su-l:auth): received for user 
> cfrm: 10 (User not known to the underlying authentication module)
> May 05 04:45:13 US02VLAPP8519 su[2249]: FAILED SU (to cfrm) cfrm on none
> May 05 04:45:14 US02VLAPP8519 manager.sh[2248]: Password: su:
> Authentication failure

I appears your service script uses "su" to switch to the "cfrm" user. As we 
noted above it is
already running as as that user, which hence makes this
pointless. This "su" fails, because no pw was supplied. Most likely
your distro changed behaviour there, i.e. previously allowed "su" from
a user to itself and now doesn't anymore. Eithre way, it's kinda
pointless doing that anyway...

In general: it's not a good idea to use "su" in shell scripts. "su"
creates login sessions, but for system stuff that's not desirable
typically. Use util-linux' setpriv(1) tool instead. But again, in this
case it's entirely pointless, …

Lennart

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

Re: [systemd-devel] Udev Regex

[Lennart Poettering]

On Mi, 06.05.20 12:15, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com) wrote:

> Good Morning List,
>
> Does anyone know how complicated of a regular expression can be
> utilized in a udev rule?

udev supports shell-style globbing for matching, but no regular
expressions. The man page says that pretty clearly, no?

Lennart

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

[systemd-devel] Antw: [EXT] Udev Regex

[Ulrich Windl]

>>> "Boyce, Kevin P [US] (AS)"  schrieb am 06.05.2020 um
14:15
in Nachricht
<16534_1588767787_5EB2AC2A_16534_16_1_d2c2e1aff05740ea9d1ea3e1325511b2@XCGVAG30.
orthgrum.com>:
> Good Morning List,
> 
> Does anyone know how complicated of a regular expression can be utilized in

> a udev rule?
> 
> For instance I have a system with a lot of drives (sda through z aren't 
> enough) and I want to write a rule that will match the physical block
devices 
> for one rule and then a separate rule for partitions.
> 
> Something like this, however the rules don't seem to fire except when I 
> remove the '+' from the rules:

The man page udev(7) I have lists '[', ']', '|', '*' and '?', but not '+'...

> ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a‑z]+", 
> SYMLINK+="some_device_%k"
> ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a‑z]+[0‑9]+", 
> SYMLINK+="some_device_%k"
> 
> I am running systemd version 219‑67.
> 
> Kind Regards,
> Kevin



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

Re: [systemd-devel] Udev Regex

[Andrei Borzenkov]

On Wed, May 6, 2020 at 3:23 PM Boyce, Kevin P [US] (AS)
 wrote:
>
> Good Morning List,
>
>
>
> Does anyone know how complicated of a regular expression can be utilized in a 
> udev rule?
>

I would ask udev manual page :)

>
>
> For instance I have a system with a lot of drives (sda through z aren’t 
> enough) and I want to write a rule that will match the physical block devices 
> for one rule and then a separate rule for partitions.
>
>
>
> Something like this, however the rules don’t seem to fire except when I 
> remove the ‘+’ from the rules:
>
> ACTION==”add”, SUBSYSTEM==”block”, KERNEL==”sd[a-z]+”, 
> SYMLINK+=”some_device_%k”
>
> ACTION==”add”, SUBSYSTEM==”block”, KERNEL==”sd[a-z]+[0-9]+”, 
> SYMLINK+=”some_device_%k”
>
>
>
> I am running systemd version 219-67.
>
>
>
> Kind Regards,
>
> Kevin
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Udev Regex

[Boyce, Kevin P [US] (AS)]

Good Morning List,

Does anyone know how complicated of a regular expression can be utilized in a 
udev rule?

For instance I have a system with a lot of drives (sda through z aren't enough) 
and I want to write a rule that will match the physical block devices for one 
rule and then a separate rule for partitions.

Something like this, however the rules don't seem to fire except when I remove 
the '+' from the rules:
ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]+", SYMLINK+="some_device_%k"
ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]+[0-9]+", 
SYMLINK+="some_device_%k"

I am running systemd version 219-67.

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

Re: [systemd-devel] systemd.network vs. ifupdown vs. netplan?

[Ansgar]

John Ioannidis writes:
> Is there a document somewhere that details what the
> interactions/conflicts/etc are between systemd.{link,netdev,network} and
> the ifupdown mechanisms? I have read the manual pages, of course, but I
> feel I'm missing something fundamental. I finally got around to moving to
> Debian 10, and in the process modernizing some of my configurations.

I don't think there are any interactions between systemd-networkd and
Debian's ifupdown mechanism.  They are just alternatives you can use to
configure network interfaces; there are other alternatives like
NetworkManager.

You can also use them in parallel as long as only one system manages a
given interface.  I find that mostly useful to have VPN connections in
NetworkManager which has nicer desktop integration.

> Then there is netplan, which Canonical is pushing with Ubuntu; it does not
> have feature parity with ifupdown, so it is not under consideration right
> now, but if the comparison includes that, so much the better.

As far as I understand Canonical's netplan.io is an abstraction layer
that allows choosing between systemd-networkd and NetworkManager to
manage interfaces (maybe also others?).  Personally I would just use
either system directly.

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

[systemd-devel] Requested transaction contradicts existing jobs: start is destructive

[Mark Bannister]

> On Tue, 5 May 2020 at 16:27, Mark Bannister  wrote:
> > Perhaps I'm missing something or oversimplifying, but I tried to
> > reproduce the problem as follows: I created a script that ignores INT,
> > TERM and HUP and then loops indefinitely writing the time every second
> > to a log file.  I SSHed into the box, ran the script, and then from
> > another terminal window killed the parent (bash) and also retried the
> > experiment by killing the bash parent (sshd).  In both cases the
> > parent bash and sshd processes died (as expected), my script kept
> > running but the parent PID of the script was changed to 1 (systemd).
> > I did not receive any error messages in /var/log/messages.
>
> It has to be the last remaining session of the user, and you should
> inspect with systemctl list-jobs if systemd is trying to stop the
> scope and slice units, just to be sure, before attempting to login.
> Otherwise, if you're logged in from two places on the machine for a
> user, you won't hit the issue, obviously.

I repeated the exact same test with a different user account, one
set-up specifically for this test and nothing else, so there was only
one SSH session.  But 'systemctl list-jobs' always reported 'No jobs
running' even after the SSH session was terminated.  My script kept
running with the parent PID of 1.  Thanks for your help so far, but I
have still been unable to reproduce the problem.  What am I doing
wrong?

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

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

[Ulrich Windl]

>>> Paul Menzel  schrieb am 06.05.2020 um
11:26 in Nachricht
<12189_1588757179_5EB282BB_12189_122_1_f3c28f74-4675-ff7b-edd2-66f52e12831f@molg
n.mpg.de>:
> Dear Ulrich,
> 
> 
> Am 06.05.20 um 11:21 schrieb Ulrich Windl:
> 
>> I have a question for systemd-228-150.82.1.x86_64 (of SLES12 SP4):
>> While developing a script for logrotate, I tested this command with the
>> following result:
>> 
>> # systemctl kill -s HUP --kill-who=15862 iotwatch@LOC1.service 
>> Failed to kill unit iotwatch@LOC1.service: Invalid who argument 15862
> 
> […]
> 
>> Did I misinterpret the manual page, or what is the problem?
>> 
>> --kill-who=
>> When used with kill, choose which processes to send a signal
to.
>> Must be one of main, control or all to select whether to kill 
> only
>> the main process, the control process or all processes of the
>> unit.
> 
> I understand it, that only *main*, *control* or *all* are valid arguments.

Ah "main" is literal. Sorry, I misinterpreted the manual page thinking
-kill-who expects a PID of the types listed...

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



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

Re: [systemd-devel] systemd-hostnamed/hostnamectl and transient hostname change

[Thomas HUMMEL]

On 5/4/20 3:57 PM, Thomas HUMMEL wrote:

but

hostnamectl --static set-hostname 'static' where current static hostname 
is already 'static' then transient hostname is never set.


What do you think about it ?


Hello,

am I wrong on this one ?

Thanks for your help

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

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

[Ulrich Windl]

>>> Reindl Harald  schrieb am 06.05.2020 um 11:24 in
Nachricht
<11141_1588757087_5EB2825F_11141_72_1_3a082624-966b-a922-f8b9-ef0bb69c32f0@thelo
nge.net>:

> 
> Am 06.05.20 um 11:21 schrieb Ulrich Windl:
>> # systemctl kill -s HUP --kill-who=15862 iotwatch@LOC1.service 
>> 
>> Did I misinterpret the manual page, or what is the problem?
>> 
>>--kill-who=
>>When used with kill, choose which processes to send a signal to.
>>Must be one of main, control or all to select whether to kill 
> only
>>the main process, the control process or all processes of the 
> unit
> 
> 15862 !== main !== control !== all

Harald,

In the part you are not quoting is: "Main PID: 15862" 

So what do you want to tell us? I could not even find out which programming 
language can parse the line above.

In case you don't want to answer, please do so, but don't answer with useless 
messages.

Regards,
Ulrich




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

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

[Silvio Knizek]

Am Mittwoch, den 06.05.2020, 11:21 +0200 schrieb Ulrich Windl:
> Hi!
>
> I have a question for systemd-228-150.82.1.x86_64 (of SLES12 SP4):
> While developing a script for logrotate, I tested this command with the
> following result:
>
> # systemctl kill -s HUP --kill-who=15862 iotwatch@LOC1.service
> Failed to kill unit iotwatch@LOC1.service: Invalid who argument 15862
>
> That's odd, because:
> # systemctl status iotwatch@LOC1
> ● iotwatch@LOC1.service - iotwatch I/O performance monitor instance "LOC1"
>Loaded: loaded (/etc/iotwatch.conf; enabled; vendor preset: disabled)
>Active: active (running) since Tue 2020-03-10 07:58:35 CET; 1 months 26
> days ago
>  Docs: man:iotwatch(1)
>man:iotwatch@.service(8)
>  Main PID: 15862 (iotwatch-LOC1)
> Tasks: 4 (limit: 512)
>CGroup: /system.slice/system-iotwatch.slice/iotwatch@LOC1.service
>└─15862 iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log
> ...
>
> Mar 10 07:58:35 rksapv04 systemd[1]: Starting iotwatch I/O performance
> moni.
> Mar 10 07:58:35 rksapv04 systemd[1]: Started iotwatch I/O performance
> monit...".
> Hint: Some lines were ellipsized, use -l to show in full.
>
>
> Did I misinterpret the manual page, or what is the problem?
>
>--kill-who=
>When used with kill, choose which processes to send a signal to.
>Must be one of main, control or all to select whether to kill only
>the main process, the control process or all processes of the
> unit.
>
> Regards,
> Ulrich

Hi Ulrich,

as you quoted right --kill-who takes either "main", "control" or "all",
not a PID.

BR
Silvio

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

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

[Paul Menzel]

Dear Ulrich,


Am 06.05.20 um 11:21 schrieb Ulrich Windl:


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

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


[…]


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

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


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


Kind regards,

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

Re: [systemd-devel] IdleAction=lock not working in ubuntu

[Archana Polampalli]

Hi Lennart ,
I have few more questions,

1.I have run $loginctl lock-session  command in gnome DE,it is 
locking the session. and why it is not locking through logind.conf parameters.

2.As per my investigation on session locking,  logind uses DBus to propagate 
the "Lock" event .we will need an application that listens for those events for 
ex.xss-lock,GDM,SDDM
So I have installed xss-lock though I found same behavior  

2.May I know which Desktop Environment support locking logic
1.Gnome
2.Mate
3.Lxde
4.Jwm


Thank in advance 

Regards,
Archana
-Original Message-
From: systemd-devel  On Behalf Of 
Archana Polampalli
Sent: Wednesday, May 6, 2020 2:25 PM
To: Lennart Poettering 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] IdleAction=lock not working in ubuntu

Thank you very much for the prompt reply

 I am using 'gnome' Desktop Environment

Regards,
Archana

-Original Message-
From: Lennart Poettering 
Sent: Wednesday, May 6, 2020 2:14 PM
To: Archana Polampalli 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] IdleAction=lock not working in ubuntu

On Mi, 06.05.20 06:40, Archana Polampalli (archana.c...@toshiba-tsip.com) wrote:

> Hi All,
>
> My requirement is my system should get locked automatically when the system 
> is idle for 5min.
> So for this I have configured /etc/system/logind.conf file as 
> IdleAction = lock IdleActionSec=2min
>
> And I restarted systemd service with  'setemctl restart 
> system-logind.service' and I kept my system idle for more than 
> 20min,but system not getting locked .and IdleAction = poweroff 
> IdleActionSec=2min Is working ,but lock not working,what I am missing here.
> Please any one can  help me at your earliest convenience .

Which desktop environment are you using? Not all DEs support the locking logic 
and simply ignore it.

Lennart

--
Lennart Poettering, Berlin
The information contained in this e-mail message and in any 
attachments/annexure/appendices is confidential to the recipient and may 
contain privileged information. 
If you are not the intended recipient, please notify the sender and delete the 
message along with any attachments/annexure/appendices. You should not 
disclose, copy or otherwise use the information contained in the message or any 
annexure. Any views expressed in this e-mail are those of the individual sender 
except where the sender specifically states them to be the views of Toshiba 
Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be free of any 
virus or other defect that might affect any computer system into which it is 
received and opened, it is the responsibility of the recipient to ensure that 
it is virus free and no responsibility is accepted by Toshiba Embedded Software 
India Pvt. Ltd, for any loss or damage arising in any way from its use.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

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

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

[Ulrich Windl]

Hi!

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

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

That's odd, because:
# systemctl status iotwatch@LOC1
● iotwatch@LOC1.service - iotwatch I/O performance monitor instance "LOC1"
   Loaded: loaded (/etc/iotwatch.conf; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-03-10 07:58:35 CET; 1 months 26
days ago
 Docs: man:iotwatch(1)
   man:iotwatch@.service(8)
 Main PID: 15862 (iotwatch-LOC1)
Tasks: 4 (limit: 512)
   CGroup: /system.slice/system-iotwatch.slice/iotwatch@LOC1.service 
   └─15862 iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log
...

Mar 10 07:58:35 rksapv04 systemd[1]: Starting iotwatch I/O performance
moni.
Mar 10 07:58:35 rksapv04 systemd[1]: Started iotwatch I/O performance
monit...".
Hint: Some lines were ellipsized, use -l to show in full.


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

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

Regards,
Ulrich


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

Re: [systemd-devel] IdleAction=lock not working in ubuntu

[Archana Polampalli]

Thank you very much for the prompt reply

 I am using 'gnome' Desktop Environment

Regards,
Archana

-Original Message-
From: Lennart Poettering  
Sent: Wednesday, May 6, 2020 2:14 PM
To: Archana Polampalli 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] IdleAction=lock not working in ubuntu

On Mi, 06.05.20 06:40, Archana Polampalli (archana.c...@toshiba-tsip.com) wrote:

> Hi All,
>
> My requirement is my system should get locked automatically when the system 
> is idle for 5min.
> So for this I have configured /etc/system/logind.conf file as 
> IdleAction = lock IdleActionSec=2min
>
> And I restarted systemd service with  'setemctl restart 
> system-logind.service' and I kept my system idle for more than 
> 20min,but system not getting locked .and IdleAction = poweroff 
> IdleActionSec=2min Is working ,but lock not working,what I am missing here.
> Please any one can  help me at your earliest convenience .

Which desktop environment are you using? Not all DEs support the locking logic 
and simply ignore it.

Lennart

--
Lennart Poettering, Berlin
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

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

Re: [systemd-devel] IdleAction=lock not working in ubuntu

[Lennart Poettering]

On Mi, 06.05.20 06:40, Archana Polampalli (archana.c...@toshiba-tsip.com) wrote:

> Hi All,
>
> My requirement is my system should get locked automatically when the system 
> is idle for 5min.
> So for this I have configured /etc/system/logind.conf file as
> IdleAction = lock
> IdleActionSec=2min
>
> And I restarted systemd service with  'setemctl restart 
> system-logind.service' and I kept my system idle for more than 20min,but 
> system not getting locked .and
> IdleAction = poweroff
> IdleActionSec=2min
> Is working ,but lock not working,what I am missing here.
> Please any one can  help me at your earliest convenience .

Which desktop environment are you using? Not all DEs support the
locking logic and simply ignore it.

Lennart

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

Re: [systemd-devel] IdleAction=lock not working in ubuntu

[Archana Polampalli]

Linux-4.19.0-5-amd64
Debian-buster
Systemd - systemd-241

Regards
Archana

From: systemd-devel  On Behalf Of 
Archana Polampalli
Sent: Wednesday, May 6, 2020 12:11 PM
To: systemd-devel@lists.freedesktop.org
Subject: [systemd-devel] IdleAction=lock not working in ubuntu

Hi All,

My requirement is my system should get locked automatically when the system is 
idle for 5min.
So for this I have configured /etc/system/logind.conf file as
IdleAction = lock
IdleActionSec=2min

And I restarted systemd service with  'setemctl restart system-logind.service' 
and I kept my system idle for more than 20min,but system not getting locked .and
IdleAction = poweroff
IdleActionSec=2min
Is working ,but lock not working,what I am missing here.
Please any one can  help me at your earliest convenience .



Regards
Archana.

.
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] IdleAction=lock not working in ubuntu

[Archana Polampalli]

Hi All,

My requirement is my system should get locked automatically when the system is 
idle for 5min.
So for this I have configured /etc/system/logind.conf file as
IdleAction = lock
IdleActionSec=2min

And I restarted systemd service with  'setemctl restart system-logind.service' 
and I kept my system idle for more than 20min,but system not getting locked .and
IdleAction = poweroff
IdleActionSec=2min
Is working ,but lock not working,what I am missing here.
Please any one can  help me at your earliest convenience .



Regards
Archana.

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel