Re: [systemd-devel] Services with multiple pre-requisites

2020-12-21 Thread Andrei Borzenkov 
21.12.2020 20:23, freedesk...@priatel.co.uk пишет:
> Perhaps I'm missing something, but that's still not doing what I expect.
> 
> Here's what I have...
> 
> #- /etc/systemd/system/first.target -#
> [Unit]
> Description=Started first
> Wants=third.service
> 
> #- /etc/systemd/system/second.target -#
> [Unit]
> Description=Started second
> Wants=third.service
> 
> #- /etc/systemd/system/third.service -#
> [Unit]
> Description=Third service
> Requisite=first.target second.target
> 
> [Service]
> Type=simple
> ExecStartPre=/usr/bin/logger -t "FooBar" -p daemon.notice "%P is starting"
> ExecStart=/tmp/third.sh
> Restart=always
> ExecStop=/usr/bin/logger -t "FooBar" -p daemon.notice "%P has stopped"
> 
> 
> #- /tmp/third.sh -#
> #!/bin/bash
> count=1
> while (( count > 0 ))
> do
>   /usr/bin/logger -i -t "FooBar" -p daemon.notice "Counter: $count"
>   (( count++ ))
>   sleep 5
> done
> 
> And here's what I observe happening. When I start *either* first.target or
> second.target, the third.service is started. That's not what I expect or
> want though. The third.service should be requisite on **both** first.target
> and second.target.
> 
> localhost# systemctl start first.target
> 
> 2020-12-21T17:03:51.039814+00:00 localhost systemd[1]: Starting Third
> service...
> 2020-12-21T17:03:51.041827+00:00 localhost FooBar: Third service is starting
> 2020-12-21T17:03:51.042451+00:00 localhost systemd[1]: Started third
> service.
> 2020-12-21T17:03:51.045033+00:00 localhost systemd[1]: Reached target
> Started first.
> 2020-12-21T17:03:51.045114+00:00 localhost systemd[1]: Started second is not
> active.
> 2020-12-21T17:03:51.045843+00:00 localhost FooBar[29048]: Counter: 1
> 2020-12-21T17:03:56.048463+00:00 localhost FooBar[644]: Counter: 2
> 2020-12-21T17:04:01.050951+00:00 localhost FooBar[4881]: Counter: 3
> 
> localhost# systemctl stop first.target
> ...
> localhost# systemctl start second.target
> 
> 2020-12-21T17:04:47.544840+00:00 localhost systemd[1]: Starting Third
> service...
> 2020-12-21T17:04:47.546885+00:00 localhost FooBar: Third Service is starting
> 2020-12-21T17:04:47.555459+00:00 localhost systemd[1]: Started third
> service.
> 2020-12-21T17:04:47.56+00:00 localhost FooBar[3938]: Counter: 1
> 2020-12-21T17:04:47.555666+00:00 localhost systemd[1]: Started first is not
> active.
> 2020-12-21T17:04:47.555730+00:00 localhost systemd[1]: Reached target
> Started second.
> 2020-12-21T17:04:52.553867+00:00 localhost FooBar[8255]: Counter: 2
> 2020-12-21T17:04:57.554741+00:00 localhost FooBar[12157]: Counter: 3
> 
> localhost# systemctl stop second.target
> 
> Note particularly the `systemd` logs:
> 
> 2020-12-21T17:03:51.045114+00:00 localhost systemd[1]: Started second is not
> active.
> 2020-12-21T17:04:47.555666+00:00 localhost systemd[1]: Started first is not
> active.
> 
> It has noticed and logged that one of the Requisite targets for the Third
> service isn't active, but it starts it anyway :-(
> 
> That seems to go directly against the documented behaviour (at
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requisite
> =):
>   | Requisite=
>   | 
>   | Similar to Requires=. However, if the units listed here are not
>   | started already, they will not be started and the starting of
>   | this unit will fail immediately.
> 
> Is this a bug, or am I still missing something?
> 

You miss ordering dependencies. Neither Requires not Requisite work
without proper After/Before.

systemd manuals make impression that dependencies are between units.
This is wrong - dependencies are between jobs. If unit B has "Requisite:
A" what happens is - systemd implicitly creates job for unit A that
verifies current state of unit A and if it is not active fails pending
start job for unit B. Without proper ordering both jobs (verify state of
unit A and start unit B) run concurrently and the order is
non-deterministic (or may be it is but then it is always "wrong" for
your purpose :) ), so in your case job for Second runs too late, when
Third is already started and there is no pending job to fail.



> Martin
> 
> -Original Message-
> From: Lennart Poettering  
> Sent: 21 December 2020 15:32
> To: freedesk...@priatel.co.uk
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] Services with multiple pre-requisites
> 
> On Mo, 21.12.20 14:43, freedesk...@priatel.co.uk (freedesk...@priatel.co.uk)
> wrote:
> 
>> Hi
>>
>> I have two "primary" services running on a Linux server with `systemd` 
>> that may be started at approximately the same time, or could just as 
>> easily be started days apart. When started, they take a few seconds to
> reach "ready"
>> state, and can signal that readiness however I choose.
>>
>> I have a third (and fourth, fifth, etc...) service which:
>>   * must not start before both Service 1 & Service 2 are ready
>>   * must start as soon as possible once both Service 1 & Service 2 are
> ready
>>   * must be s

Re: [systemd-devel] Services with multiple pre-requisites

2020-12-21 Thread freedesktop 
Perhaps I'm missing something, but that's still not doing what I expect.

Here's what I have...

#- /etc/systemd/system/first.target -#
[Unit]
Description=Started first
Wants=third.service

#- /etc/systemd/system/second.target -#
[Unit]
Description=Started second
Wants=third.service

#- /etc/systemd/system/third.service -#
[Unit]
Description=Third service
Requisite=first.target second.target

[Service]
Type=simple
ExecStartPre=/usr/bin/logger -t "FooBar" -p daemon.notice "%P is starting"
ExecStart=/tmp/third.sh
Restart=always
ExecStop=/usr/bin/logger -t "FooBar" -p daemon.notice "%P has stopped"


#- /tmp/third.sh -#
#!/bin/bash
count=1
while (( count > 0 ))
do
  /usr/bin/logger -i -t "FooBar" -p daemon.notice "Counter: $count"
  (( count++ ))
  sleep 5
done

And here's what I observe happening. When I start *either* first.target or
second.target, the third.service is started. That's not what I expect or
want though. The third.service should be requisite on **both** first.target
and second.target.

localhost# systemctl start first.target

2020-12-21T17:03:51.039814+00:00 localhost systemd[1]: Starting Third
service...
2020-12-21T17:03:51.041827+00:00 localhost FooBar: Third service is starting
2020-12-21T17:03:51.042451+00:00 localhost systemd[1]: Started third
service.
2020-12-21T17:03:51.045033+00:00 localhost systemd[1]: Reached target
Started first.
2020-12-21T17:03:51.045114+00:00 localhost systemd[1]: Started second is not
active.
2020-12-21T17:03:51.045843+00:00 localhost FooBar[29048]: Counter: 1
2020-12-21T17:03:56.048463+00:00 localhost FooBar[644]: Counter: 2
2020-12-21T17:04:01.050951+00:00 localhost FooBar[4881]: Counter: 3

localhost# systemctl stop first.target
...
localhost# systemctl start second.target

2020-12-21T17:04:47.544840+00:00 localhost systemd[1]: Starting Third
service...
2020-12-21T17:04:47.546885+00:00 localhost FooBar: Third Service is starting
2020-12-21T17:04:47.555459+00:00 localhost systemd[1]: Started third
service.
2020-12-21T17:04:47.56+00:00 localhost FooBar[3938]: Counter: 1
2020-12-21T17:04:47.555666+00:00 localhost systemd[1]: Started first is not
active.
2020-12-21T17:04:47.555730+00:00 localhost systemd[1]: Reached target
Started second.
2020-12-21T17:04:52.553867+00:00 localhost FooBar[8255]: Counter: 2
2020-12-21T17:04:57.554741+00:00 localhost FooBar[12157]: Counter: 3

localhost# systemctl stop second.target

Note particularly the `systemd` logs:

2020-12-21T17:03:51.045114+00:00 localhost systemd[1]: Started second is not
active.
2020-12-21T17:04:47.555666+00:00 localhost systemd[1]: Started first is not
active.

It has noticed and logged that one of the Requisite targets for the Third
service isn't active, but it starts it anyway :-(

That seems to go directly against the documented behaviour (at
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requisite
=):
  | Requisite=
  | 
  | Similar to Requires=. However, if the units listed here are not
  | started already, they will not be started and the starting of
  | this unit will fail immediately.

Is this a bug, or am I still missing something?

Martin

-Original Message-
From: Lennart Poettering  
Sent: 21 December 2020 15:32
To: freedesk...@priatel.co.uk
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Services with multiple pre-requisites

On Mo, 21.12.20 14:43, freedesk...@priatel.co.uk (freedesk...@priatel.co.uk)
wrote:

> Hi
>
> I have two "primary" services running on a Linux server with `systemd` 
> that may be started at approximately the same time, or could just as 
> easily be started days apart. When started, they take a few seconds to
reach "ready"
> state, and can signal that readiness however I choose.
>
> I have a third (and fourth, fifth, etc...) service which:
>   * must not start before both Service 1 & Service 2 are ready
>   * must start as soon as possible once both Service 1 & Service 2 are
ready
>   * must be stopped as soon as possible if either Service 1 or Service 
> 2 terminates

Did I get this right: service 3 is not supposed to pull in services 1
+ 2, but just be activated as side-effect of those services being
activated? i.e. the activation of service 1 and 2 need to happen first and
they are the trigger for service 3, but besides that noone ever asks for
service 3?

If so, it appears to me a Wants= dep from services 1 and 2 on 3 would make
sense, plus a Requisite= dep in the other direction.

Lennart

--
Lennart Poettering, Berlin

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

Re: [systemd-devel] Services with multiple pre-requisites

2020-12-21 Thread Lennart Poettering 
On Mo, 21.12.20 14:43, freedesk...@priatel.co.uk (freedesk...@priatel.co.uk) 
wrote:

> Hi
>
> I have two "primary" services running on a Linux server with `systemd` that
> may be started at approximately the same time, or could just as easily be
> started days apart. When started, they take a few seconds to reach "ready"
> state, and can signal that readiness however I choose.
>
> I have a third (and fourth, fifth, etc...) service which:
>   * must not start before both Service 1 & Service 2 are ready
>   * must start as soon as possible once both Service 1 & Service 2 are ready
>   * must be stopped as soon as possible if either Service 1 or Service 2
> terminates

Did I get this right: service 3 is not supposed to pull in services 1
+ 2, but just be activated as side-effect of those services being
activated? i.e. the activation of service 1 and 2 need to happen first
and they are the trigger for service 3, but besides that noone ever
asks for service 3?

If so, it appears to me a Wants= dep from services 1 and 2 on 3 would
make sense, plus a Requisite= dep in the other direction.

Lennart

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

Re: [systemd-devel] systemd 244 version Execstop issue

2020-12-21 Thread Lennart Poettering 
On Do, 17.12.20 12:27, gowtham b (gowtham.gowtha...@gmail.com) wrote:

> Hi,
>
> hope you are doing good
> Facing issue in systemd 244 version Execstop is not executing while process
> crashing. Did additional testing if we restart the process via systemd
> "systemctl restart tr069pa" command Execstop is running properly seeing the
> restart log in the redirected file. The same service file was used in
> systemd 216 version not facing any issue in process crashing time Execstop
> was executed properly. could please let me know if we have any known
> issues.

Have you read the docs about ExecStop=?

Note that ExecStop= is only run once the service managed to complete
initializatio at least once, i.e. ExecStart= complete fully so that
the service is up.

Maybe turn on debug logging (with "systemd-analyze log-level debug")
to get a closer look at what is happening.

Lennart

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

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

2020-12-21 Thread Lennart Poettering 
On Do, 17.12.20 13:20, Aditya Tayade (adityadtay...@gmail.com) wrote:

> Hi,
>
> I am getting below crash in our CI environment with systemd v244-stable
> which looks similar to issue #14943
> . So could you please
> confirm if it is the same issue and whether the PR:
> https://github.com/systemd/systemd/pull/15557 (already merged in v246) will
> fix this? If yes then we need back port of these PR to v244-stable as well
> and if not then could you please help to understand what can be cause of
> this?:

15557 is the supposed fix for 14943. That I can confirm. if it fixes
your specific issue I don't know, since I do not have access to your
platform.

The question you are asking cannot reasonably answered, in particular
without any informaiton about used distro/arch/… and all those things.

Either way, I'd recommend you to try it out and see if it fixes your
CI problems? That's the only way you can now for sure...

Lennart

--
Lennart Poettering, Berlin
___
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

2020-12-21 Thread Reindl Harald 




Am 14.12.20 um 17:22 schrieb John:

Thank you for the reply, Colin.  I found that to be the case[1].  I
think everything is working as expected now.  I still have quirks with
the kodi-x11.service since it has to call xinit as well as the kodi
binary but I do not know of a cleaner way to do it unless there is a
multiple unit solution to be had (one for xserver and another for
kodi).


targets and dependencies maybe are your friend

[root@srv-rhsoft:~]$ cat /etc/systemd/system/vmware-guest.target
[Unit]
Description=VMware Guest Group
After=vmware.service vmware-modules.service vmware.target 
vmware-vmnet.service network-up.service
Requires=vmware.service vmware-modules.service vmware.target 
vmware-vmnet.service

Wants=network-up.service
Wants=guest-arrakis.service
Wants=guest-testserver.service
Wants=guest-esxi.service

[Install]
WantedBy=multi-user.target


1. 
https://github.com/graysky2/kodi-standalone-service/commit/909f274d6eaf011add6326b28b42fecb9123c7df

On Mon, Dec 14, 2020 at 11:12 AM Colin Guthrie  wrote:


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.

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

Re: [systemd-devel] Q: (simple) socket activation

2020-12-21 Thread Lennart Poettering 
On Fr, 18.12.20 08:44, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> I have a simple question: For a socket-unit I have:
> LISTENUNIT
> ACTIVATES
> [::]:16514libvirtd-tls.socket 
> libvirtd.service
>
> I had enabled/started libvirtd.service first, then configured TLS later, 
> enabling/starting the libvirtd-tls.socket.
> Should I disable libvirtd.service again, or would that block 
> libvirtd-tls.socket from working?
> At the moment I can't restart libvirtd-tls.socket when libvirtd.service is 
> running: I first have to stop libvirtd.service.

This really depends on how the libvirt object put together its unit
files, and cannot be answered out of thin air.

Not sure what "configured TLS later" is even supposed to mean.

Lennart

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

Re: [systemd-devel] networkd questions

2020-12-21 Thread Lennart Poettering 
On Fr, 04.12.20 03:50, Dan Egli (d...@newideatest.site) wrote:

> I've got an issue or two with networkd that I can't seem to resolve. I hope
> someone here can help me.
>
> 1) I have a particular machine configured to forward and Masquerade ipv4
> packets. But when networkd loads, I see this in the journal:
> enp0s3: Could not enable IP masquerading, ignoring: Operation not supported
>
> Yet I looked in the kernel's .config and as far as I can tell, masquerading
> IS enabled. It's certainly enabled for netfilter. If there's somewhere else
> I should look, where?
>
> Second, how can I configure the dhcp server portion to sent out reserved
> IPs, i.e. when MAC address ::::: requests an
> address, give it W.X.Y.Z and hostname H.

Maybe your distro disabled support for iptables during systemd build?
This requires libiptc development headers to be installed during
build.

Also note that your kernel needs to enable iptables (not nftables) for
this to work.

Lennart

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

Re: [systemd-devel] Raw/translated keycode clashes in hwdb.d/60-keyboard.hwdb

2020-12-21 Thread Lennart Poettering 
On Do, 03.12.20 04:22, Ardavast Dayleryan (ardav...@noiseoverip.com) wrote:

> Hello,
>
> I'm trying to emit keypresses from an embedded device connected over a
> serial port, I attach it as an "AT Raw Set 2 keyboard" with inputattach
> like this: sudo inputattach --baud 9600 --ps2serkbd /dev/ttyACM0
>
> It usually works, but I noticed that on some laptops, some of the
> scancodes do not work, for example on an IdeaPad Y580 the scancode for
> KEY_DOWN does not work.
> The scancode for KEY_DOWN on a raw set 2 keyboard is 0xe0 0x72, which
> is encoded as 0xf2.
> The scancode for KEY_DOWN on a translated set 2 keyboard is 0xd0, and
> 0xf2 is KEY_RESERVED.
> I traced the problem to the following lines in hwdb.d/60-keyboard.hwdb:
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*IdeaPad*:*
> [...]
> KEYBOARD_KEY_f1=camera
> KEYBOARD_KEY_f2=f21
> KEYBOARD_KEY_f3=f21
>
> It seems that these lines are applied for both the raw and the
> translated keyboards, and this works fine for the translated keyboard,
> but it clashes with the scancode for KEY_DOWN on the raw keyboard and
> I can't emit KEY_DOWN from it.
>
> I was able to fix this by adding the following near the top of
> rules.d/60-evdev.rules:
> ATTRS{name}=="AT Raw Set 2 keyboard", GOTO="evdev_end"
>
> But I'm a total noob when it comes to systemd/udev , so I wanted to ask:
> 1. Is this approach OK, or is it prone to break other stuff?
> 2. Would you consider including a fix for this issue in a future version?

Sure, please file a PR with a patch on github, or at least an issue.

I wonder if we can find a better match though than the name string,
i.e. what is key is that one keyboard is connected to the AT keyboard
controller, and yours is connected to a serial port, right? So the
udev rules should be fixed to match against the former only.

Anyway, please file a PR/issue on github about this, and continue the
discussion there.

Lennart

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

[systemd-devel] Services with multiple pre-requisites

2020-12-21 Thread freedesktop 
Hi

I have two "primary" services running on a Linux server with `systemd` that
may be started at approximately the same time, or could just as easily be
started days apart. When started, they take a few seconds to reach "ready"
state, and can signal that readiness however I choose.

I have a third (and fourth, fifth, etc...) service which:
  * must not start before both Service 1 & Service 2 are ready
  * must start as soon as possible once both Service 1 & Service 2 are ready
  * must be stopped as soon as possible if either Service 1 or Service 2
terminates

I've been trying to do this using systemd.targets, but while I can trivially
get Service 3 to start when Service 1 'starts' a target, I've not found how
to get it to depend on both Service 1's target & Service 2's target.

Here's an example of what I've tried:

```
[Unit]
Description=Service 3
PartOf=Service1.target Service2.target
After=Service1.target Service2.target

[Service]
ExecStart=<>

[Install]
WantedBy=Service1.target Service2.target
```

Then Service 1 & Service 2 would trigger `systemctl start
Service[12].target` when they reach readiness, and `systemctl stop
Service[12].target` when they terminate.

However, Service 3 starts as soon as either Service1.target or
Service2.target occurs. What I need is for Service 3 to start when both
Service1.target and Service2.target have occurred. (It terminates correctly,
though.)

Am I missing something obvious?

Thanks

Martin

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

Re: [systemd-devel] systemd 244 version Execstop issue

2020-12-21 Thread gowtham b 
Hi All,

could you please any help on this issue.

Thanks,
Gowtham

On Thu, Dec 17, 2020 at 12:27 PM gowtham b 
wrote:

> Hi,
>
> hope you are doing good
> Facing issue in systemd 244 version Execstop is not executing while
> process crashing. Did additional testing if we restart the process via
> systemd "systemctl restart tr069pa" command Execstop is running properly
> seeing the restart log in the redirected file. The same service file was
> used in systemd 216 version not facing any issue in process crashing time
> Execstop was executed properly. could please let me know if we have any
> known issues.
>
> logs:
>
> ===
> [Unit]
> Description=Tr069Pa service
>
> After=QandA.service
> ConditionPathExists=!/tmp/disableTr069
>
> [Service]
> Type=forking
> EnvironmentFile=/etc/device.properties
> ExecStart=/usr/bin/Tr069Pa
> ExecStop=/bin/sh -c 'echo "`date`: Stopping/Restarting Tr069Pa" >>
> ${PROCESS_RESTART_LOG}'
> Restart=always
>
> StandardOutput=syslog+console
>
> 
> 2020 Dec 16 10:18:27  systemd[1]: Tr069Pa.service: Main process exited,
> code=killed, status=11/SEGV
> 2020 Dec 16 10:18:27  systemd[1]: Tr069Pa.service: Failed with result
> 'signal'.
> 2020 Dec 16 10:18:37 systemd[1]: Tr069Pa.service: Scheduled restart job,
> restart counter is at 1.
> 2020 Dec 16 10:18:37 systemd[1]: Stopped Tr069Pa service.
> 2020 Dec 16 10:18:37 systemd[1]: Starting Tr069Pa service...
> 2020 Dec 16 10:18:37 systemd[1]: Started Tr069Pa service.
>
> =
>
> Please let me know if any additional logs required.
>
> Thanks,
> Gowtham
>
>

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

Re: [systemd-devel] Sandboxing options

2020-12-21 Thread Christopher Wong 
Hi Lennart,

Thanks for your reply! After some struggles I managed to figure out that I was 
missing the SECCOMP in systemd 244 that I was running. Once I have enabled 
SECCOMP and managed to build systemd with it then all the below options except 
for UMask was available for me.

I will leave UMask for now, no need to use it at this moment.

Best regards,
Christopher Wong



From: Lennart Poettering 
Sent: Saturday, December 19, 2020 11:28
To: Christopher Wong
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Sandboxing options

On Mo, 28.09.20 17:00, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi,
>
>
> There are a bunch of sandboxing options that I am trying to enable
> but I got no effects when I am setting them. Below are the options
> that I am trying to set, but I can't seem to turn them on.
>
> LockPersonality=true
> MemoryDenyWriteExecute=true
> RestrictRealtime=true
> RestrictSUIDSGID=true
> RestrictNamespaces=
> SystemCallArchitectures=native
> #SystemCallArchitectures=option
> UMask=
> #UMask=0033
>
> I have enabled the following kernel configurations:
>
> CONFIG_NAMESPACES=y
> CONFIG_NET_NS=y
> CONFIG_USER_NS=y
> CONFIG_SECCOMP=y
>
> Is there anything that I am missing?

Maybe start with saying which distro you are using, which kernel,
which systemd version.

Give an example of the unit file you are using.

Are you using this in --user or --system mode? (Note that a bunch of
sandboxing settings are only available for --system).

Have you checked the logs? In particular after enabling debug logging
(systemd-analyze log-level debug).

Lennart

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

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

2020-12-21 Thread Paul Menzel 

Dear Aditya,


Am 21.12.20 um 04:30 schrieb Aditya Tayade:


Could you please help with this.


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



Kind regards,

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