Re: [systemd-devel] The question about process limits in systemd

[Firxiao zhang]

Hi Mantas Mikulėnas,  Got it, thanks a lot.

On Wed, Feb 28, 2018 at 2:11 PM Mantas Mikulėnas  wrote:

> On Wed, Feb 28, 2018 at 3:30 AM, Firxiao zhang 
> wrote:
>
>> Hi All.
>> I am confusing the relationship between "systemd" and
>> "/etc/security/limits.conf".
>> so far, I am migrating a service(init.d) script(centos6) to systemd
>> unit(centos7).
>> on centos6, I defined the user limits in "/etc/security/limits.conf". and
>> it worked well.
>> after I done the same thing on centos7. I found the limits was not taking
>> effect. so I googled this problem. it said I need define the limits in
>> systemd unit file. like: LimitNOFILE=xxx.
>> Here are my questions:
>> 1. are the systemd limits and the system security limits  individual?
>>
>
> They are completely separate. /etc/security/limits.conf is *only* read by
> PAM (pam_limits.so), which basically means user login sessions (getty, ssh,
> xdm...)
>
> (Although it's possible for systemd to call PAM when starting a service,
> it needs careful configuration and you shouldn't do it by default.)
>
>
>> 2. if not. is there a way to make systemd read the system security limits
>> as default?
>>
>
> No. Limits for a service should be in its .service file.
>
> --
> Mantas Mikulėnas
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] The question about process limits in systemd

[Mantas Mikulėnas]

On Wed, Feb 28, 2018 at 3:30 AM, Firxiao zhang 
wrote:

> Hi All.
> I am confusing the relationship between "systemd" and
> "/etc/security/limits.conf".
> so far, I am migrating a service(init.d) script(centos6) to systemd
> unit(centos7).
> on centos6, I defined the user limits in "/etc/security/limits.conf". and
> it worked well.
> after I done the same thing on centos7. I found the limits was not taking
> effect. so I googled this problem. it said I need define the limits in
> systemd unit file. like: LimitNOFILE=xxx.
> Here are my questions:
> 1. are the systemd limits and the system security limits  individual?
>

They are completely separate. /etc/security/limits.conf is *only* read by
PAM (pam_limits.so), which basically means user login sessions (getty, ssh,
xdm...)

(Although it's possible for systemd to call PAM when starting a service, it
needs careful configuration and you shouldn't do it by default.)


> 2. if not. is there a way to make systemd read the system security limits
> as default?
>

No. Limits for a service should be in its .service file.

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

Re: [systemd-devel] networkd dhcp client generic options

[Sebastian Unger]

Hi List,

I believe I sent the email below before, but since I didn't get ANY reply
(not even a "no idea" or "what a silly question"), I'm uncertain that it in
fact made it to the list. If it has, then please accept my apologies for
the bump.

In either case, I'd really appreciate it if anybody can share any insight
they may have.

On 30 January 2018 at 09:07, Sebastian Unger  wrote:

> Hi,
>
> I have tried to find an answer to this using the usual sources, but have
> come up empty so far. Hopefully someone here can help me. If this is not
> the best place, please let me know where that would be.
>
> I've been managing a number of Ubuntu machines (~60) for several years now
> and am currently preparing the upgrade from 16.04 to 18.04 (using 17.10
> a.t.m.).
>
> One of the many changes is the migration from ifupdown to
> netplan/networkd, at least for the server machines. The desktop install
> still seems to use network-manager by default. This is causing me a bit of
> a head-ache.
>
> In 16.04 we had a number of scripts in /etc/dhclient hooks as well as in
> /etc/network/if-up.d. Obviously these do not work any more with networkd. I
> understand why networkd does not use the if-up scripts and does not like
> scripts in general. However, for the /etc/dhclient scripts, I can see no
> way to achieve the same functionality that is currently available.
>
> For example, samba installs a script into /etc/dhclient to get the WINS
> server from DHCP and update its own dynamic config so that it can use that.
> How would one go about achieving this with networkd?
>
> I have read suggestions on the internet to put an inotify on
> /run/systemd/netif/* and process the information when it changes. That
> strikes me as a bad idea on many levels (i.e. the files themselves contain
> warnings not to do that), but for WINS that isn't even a solution since
> networkd does not appear to store the received value for option 44 in there.
>
> So:
>
> Q1: Is there any way to get the networkd DHCP client to ask for and record
> more options than just the bare IPv4/6 necessities?
> Q2: What is the "official" way to get these options out of networkd for
> use by the parts of the system that need them?
> Q3: If the answers to the two above are something like: No and None, then
> is there a way to integrate networkd with an external DHCP client?
>

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

[systemd-devel] The question about process limits in systemd

[Firxiao zhang]

Hi All.
I am confusing the relationship between "systemd" and
"/etc/security/limits.conf".
so far, I am migrating a service(init.d) script(centos6) to systemd
unit(centos7).
on centos6, I defined the user limits in "/etc/security/limits.conf". and
it worked well.
after I done the same thing on centos7. I found the limits was not taking
effect. so I googled this problem. it said I need define the limits in
systemd unit file. like: LimitNOFILE=xxx.
Here are my questions:
1. are the systemd limits and the system security limits  individual?
2. if not. is there a way to make systemd read the system security limits
as default?

it would be appreciated for your help. thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Triggering the HW Watchdog

[D.S. Ljungmark]

Partially,

   It shows that systemd is handling the watchdog as I expect it to
here, but it also means that the "dysfunctional" times where the
system isn't resetting properly is _not_ due to watchdog triggering,
but is a "normal system" according to systemd.

Which is a worse case for me, since it's harder to debug.

So, conclusion:
 systemd seems to handle watchdog properly
 systemd seems to not die properly when we expect it to, leaving us to
find more debugging.

I hope that makes more sense than less.


On Tue, Feb 27, 2018 at 5:34 PM, Mantas Mikulėnas  wrote:
> On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark  wrote:
>>
>>
>>
>> On 27/02/18 15:21, Lennart Poettering wrote:
>> > On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
>> >
>> >>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>> >>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>> >>> please try)
>> >>
>> >> It seems that SIGSTOP is being filtered, because nothing appears to
>> >> happen, and the system certainly isn't rebooting.
>> >
>> > You should be able to trigger an abort in PID 1 by sending it SIGABRT
>> > or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop
>> > in which it stops pinging the hw watchdog.
>> >
>> > Lennart
>>
>>
>> ABRT works,  or well..
>>
>> systemd[1]: Caught , core dump failed (child 3844, code=killed,
>> status=6/ABRT).
>>
>> And then a broadcast, freezing execution
>>
>>
>> And after that, what I was afraid of:
>>
>> [25417.186351] watchdog: watchdog0: watchdog did not stop!
>>
>
> Isn't that exactly the result you asked for?
>
> --
> Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in

[Andrei Borzenkov]

27.02.2018 17:20, Hongzhi, Song пишет:
> Hi,
> 
> thank for your help, but I still have some question.
> 
> 
> My current linux system init uses systemd and udev, with
> 'automount.rules' and 'mount.sh' in /etc/udev/,
> 
> to manage device. But owning to MountFlags=slave, hotpluggable media
> (e.g., /dev/sda1 )
> 
> can be mounted again in host, whereas can't be formatted by mkfs.ext4 in
> host with error
> 
> message '/dev/sda1 is apparently in use by the system; will not make a
> filesystem here!'.
> 
> 
> In your reply, you told me to invoke "systemd-mount" from udev rules. Do
> you mean that
> 
> I should replace /bin/mount with /usr/bin/systemd-mount in mount.sh, or add
> 
> "RUN+='/usr/bin/systemd-mount $env{DEVNAME}'" to automount.rules?
> 
> 1）
> 
> I  replaced /bin/mount with /usr/bin/systemd-mount in mount.sh.
> 
>     /usr/bin/systemd-mount $DEVNAME "/run/media/$name"
> 
> it prompted that
> 
>     systemd[1]: dev-sda.device: Job dev-sda.device/start timed out.
>     systemd[1]: Timed out waiting for device dev-sda.device.
>     systemd[1]: Dependency failed for /run/media/sda.
>     systemd[1]: run-media-sda.mount: Job run-media-sda.mount/start
> failed with result 'dependency'.
>     systemd[1]: Dependency failed for File System Check on /dev/sda.
>     systemd[1]: systemd-fsck@dev-sda.service: Job
> systemd-fsck@dev-sda.service/start failed with result 'dependency'.
>     systemd[1]: Startup finished in 16.692s (kernel) + 1min 32.605s
> (userspace) = 1min 49.298s.
>     systemd[1]: dev-sda.device: Job dev-sda.device/start failed with
> result 'timeout'.
> 
>     ...
> 
> in /var/log/syslog.
> 

Try

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

Re: [systemd-devel] Triggering the HW Watchdog

[Mantas Mikulėnas]

On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark  wrote:

>
>
> On 27/02/18 15:21, Lennart Poettering wrote:
> > On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
> >
> >>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
> >>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
> >>> please try)
> >>
> >> It seems that SIGSTOP is being filtered, because nothing appears to
> >> happen, and the system certainly isn't rebooting.
> >
> > You should be able to trigger an abort in PID 1 by sending it SIGABRT
> > or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop
> > in which it stops pinging the hw watchdog.
> >
> > Lennart
>
>
> ABRT works,  or well..
>
> systemd[1]: Caught , core dump failed (child 3844, code=killed,
> status=6/ABRT).
>
> And then a broadcast, freezing execution
>
>
> And after that, what I was afraid of:
>
> [25417.186351] watchdog: watchdog0: watchdog did not stop!
>
>
Isn't that exactly the result you asked for?

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

Re: [systemd-devel] Triggering the HW Watchdog

[D.S. Ljungmark]

On 27/02/18 15:21, Lennart Poettering wrote:
> On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
> 
>>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>>> please try)
>>
>> It seems that SIGSTOP is being filtered, because nothing appears to
>> happen, and the system certainly isn't rebooting.
> 
> You should be able to trigger an abort in PID 1 by sending it SIGABRT
> or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop
> in which it stops pinging the hw watchdog.
> 
> Lennart


ABRT works,  or well..

systemd[1]: Caught , core dump failed (child 3844, code=killed,
status=6/ABRT).

And then a broadcast, freezing execution


And after that, what I was afraid of:

[25417.186351] watchdog: watchdog0: watchdog did not stop!


Well, that gives me a tool to debug this with, Thank you!


//D.S

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in

[Hongzhi, Song]

Hi,

thank for your help, but I still have some question.


My current linux system init uses systemd and udev, with 
'automount.rules' and 'mount.sh' in /etc/udev/,


to manage device. But owning to MountFlags=slave, hotpluggable media 
(e.g., /dev/sda1 )


can be mounted again in host, whereas can't be formatted by mkfs.ext4 in 
host with error


message '/dev/sda1 is apparently in use by the system; will not make a 
filesystem here!'.



In your reply, you told me to invoke "systemd-mount" from udev rules. Do 
you mean that


I should replace /bin/mount with /usr/bin/systemd-mount in mount.sh, or add

"RUN+='/usr/bin/systemd-mount $env{DEVNAME}'" to automount.rules?

1）

I  replaced /bin/mount with /usr/bin/systemd-mount in mount.sh.

    /usr/bin/systemd-mount $DEVNAME "/run/media/$name"

it prompted that

    systemd[1]: dev-sda.device: Job dev-sda.device/start timed out.
    systemd[1]: Timed out waiting for device dev-sda.device.
    systemd[1]: Dependency failed for /run/media/sda.
    systemd[1]: run-media-sda.mount: Job run-media-sda.mount/start 
failed with result 'dependency'.

    systemd[1]: Dependency failed for File System Check on /dev/sda.
    systemd[1]: systemd-fsck@dev-sda.service: Job 
systemd-fsck@dev-sda.service/start failed with result 'dependency'.
    systemd[1]: Startup finished in 16.692s (kernel) + 1min 32.605s 
(userspace) = 1min 49.298s.
    systemd[1]: dev-sda.device: Job dev-sda.device/start failed with 
result 'timeout'.


    ...

in /var/log/syslog.

2）

I edited automount.rules with "SUBSYSTEM=="block", ACTION=="add"    
RUN+="/usr/bin/systemd-mount $env{DEVNAME}"，


it prompt that "systemd-udevd Process '/usr/bin/systemd-mount 
$env{DEVNAME}' failed with exit code 1".



Infact, my problem is that I can't format /dev/sda1 with mkfs.ext4 in 
host with MountFlags=slave.


So. is it usefull to use systemd-mount? If it is, how should do to fix 
the new problems mentioned above.



Thanks again for your help.


On 2018年02月23日 19:06, Lennart Poettering wrote:

On Do, 22.02.18 20:52, Hongzhi, Song (hongzhi.s...@windriver.com) wrote:


Hi,

systemd, upstream commit id c2c13f2df42e0691aecabe3979ea81cd7faa35c7

You set MountFlags=slave just for keeping mounts done by udev rules private
to udevd.

So all block device mounted by systemd-udevd is unvisible for host.

I don't know why. And is there any bad effect, if I change slave to shared ?

Well, we generally try to run all our services with sandboxes that are
as tight as we can make them. udev can run arbitrary stuff from its
rules hence the sandbox can't be made too tight unfortunately.

MountFlags=slave is essentially a sandboxing setting: it detaches
mount() operations done within the service from the rest of the
system.

While udev rules can do pretty much everything, we do know that doing
mount operations themselves is not the best of ideas, and there are
better approaches. That's because udev rules should be quick, and
mounting isn't necessarily (in particular on dirty fs).

Specifcally, there are three schemes that are much preferable:

1. Use TAG+="systemd", ENV{SYSTEMD_WANTS}+="foobar.mount" in udev
rules to asynchronously pull in mount units from udev rules.

2. Invoke "systemd-mount" from udev rules, which will spawn transient
automount and mount units for devices. This is generally the best
way in particular in embedded applications to deal with
hotpluggable media. It optionally runs fsck before mounting for
you, and it it uses automounts for keeping the actual window when a
device is mounted as brief as possible, in order to maximize the
chance that the file system remains in a fully clean state, since
it's essentially unmounted whenever idle. If you have hotplug media
this means you get the best chance of leaving the fs in a clean
state, and getting it back into a clean state if it evers gets into
an unclean state.

3. Use a daemon such as udisks to manage hotplugs of devices.

That all said, you can also deviate from upstream and simply drop the
MountFlags=slave, but of course, this means you lose compatibility
with upstream on this.

Lennart



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

Re: [systemd-devel] EXT: Re: Triggering the HW Watchdog

[Ray, Ian (GE Healthcare)]

> On 27 Feb 2018, at 16.12, D.S. Ljungmark  wrote:
> 
> ( re-send as I forgot the list )
> 
> On 27/02/18 13:20, Lennart Poettering wrote:> On Di, 27.02.18 12:44,
> D.S. Ljungmark (ljungm...@modio.se) wrote:
>> 
>>> Hi list!
>>> 
>>> We're using systemd to control the hardware watchdog, and would want to
>>> induce fail state to _verify_ that the shutdown/reboot process works as
>>> expected.
>>> 
>>> How do we make systemd "fail" to ping the watchdog?
>> 
>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>> please try)
> 
> It seems that SIGSTOP is being filtered, because nothing appears to
> happen, and the system certainly isn't rebooting.
> 

This works for me: `gdb --pid 1'.


> 
>>> How do we control which states ( root fs not available, etc) cause
>>> systemd to not ping the hardware watchdog?
>> 
>> The watchdog is for detecting software hanging. Root fs not being
>> available does not really qualify as "software hanging". If you want
>> to reboot the machine if it fails to bring everything up, then use
>> JobTimeoutAction= on some suitable action, for example local-fs.target
>> or multi-user.target.
>> 
>> Lennart
> Thanks,
>  I'm trying to get to a state where the machine fails over and triggers
> watchdog on known things, rather than triggering the rescue shell or
> similar.
> 
> 
> I'll try with a jobtimeout on multi-user.
> 
> //D.S.
> 
> 
> -- 
> 8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
> ___
> 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] Triggering the HW Watchdog

[Lennart Poettering]

On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:

> > I figure you can send SIGSTOP to PID 1, no? (there are some signals
> > the kernel blocks for PID 1, but I think SIGSTOP is not among them,
> > please try)
> 
> It seems that SIGSTOP is being filtered, because nothing appears to
> happen, and the system certainly isn't rebooting.

You should be able to trigger an abort in PID 1 by sending it SIGABRT
or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop
in which it stops pinging the hw watchdog.

Lennart

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

Re: [systemd-devel] Triggering the HW Watchdog

[D.S. Ljungmark]

( re-send as I forgot the list )

On 27/02/18 13:20, Lennart Poettering wrote:> On Di, 27.02.18 12:44,
D.S. Ljungmark (ljungm...@modio.se) wrote:
>
>> Hi list!
>>
>>  We're using systemd to control the hardware watchdog, and would want to
>> induce fail state to _verify_ that the shutdown/reboot process works as
>> expected.
>>
>> How do we make systemd "fail" to ping the watchdog?
>
> I figure you can send SIGSTOP to PID 1, no? (there are some signals
> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
> please try)

It seems that SIGSTOP is being filtered, because nothing appears to
happen, and the system certainly isn't rebooting.


>> How do we control which states ( root fs not available, etc) cause
>> systemd to not ping the hardware watchdog?
>
> The watchdog is for detecting software hanging. Root fs not being
> available does not really qualify as "software hanging". If you want
> to reboot the machine if it fails to bring everything up, then use
> JobTimeoutAction= on some suitable action, for example local-fs.target
> or multi-user.target.
>
> Lennart
Thanks,
  I'm trying to get to a state where the machine fails over and triggers
watchdog on known things, rather than triggering the rescue shell or
similar.


I'll try with a jobtimeout on multi-user.

//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Best practice for prepopulating the CacheDirectory of dynamic users

[Antoine Pietri]

Hi!

To experiment with systemd dynamic users, I started working on a
wrapper around a program that builds user packages (Archlinux makepkg)
and that refuses to be launched as root (for very good reasons). The
idea is that the wrapper just calls:

systemd-run --pipe \
  -p DynamicUser=yes \
  -p CacheDirectory=mywrapper \
  -p WorkingDirectory=/var/cache/mywrapper/build/repo \
  makepkg

However, to be able to run makepkg, its cache directory has to be
pre-populated with a clone of the package to build. So, from my
wrapper, I just did:

  os.makedirs(os.path.dirname(build_dir), exist_ok=True)
  shutil.copytree(repo_path, build_dir)

to copy the content of the repo to the build directory. But it fails with:

  run-u63.service: Failed to set up special execution directory in
/var/cache: File exists

This makes sense, because of the symbolic link shenanigans to
/var/cache/private that systemd uses to keep the filesystem readonly.
So, now I'm wondering what would be the best practice to prepopulate
this directory:

- My current workaround is to shell-out to `systemd-run -p
DynamicUser=yes ...` first to do a mkdir -p, then for a cp -R. This
solution requires a lot of boilerplate from the Python wrapper and
takes more time for no good reason, so I think it's not ideal.

- I believe another solution would be to modify /var/cache/private
directly, but I'm not sure it's a good practice to do so because I
don't know if this path is reliable or just an implementation detail.
Plus, it requires a weird special case compared to when I don't run
makepkg with systemd-run, as I have to insert something in the middle
of the copy destination path.

- Maybe there's something else I'm missing that would allow me to do
this more cleanly?

Thanks,

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

Re: [systemd-devel] Triggering the HW Watchdog

[Lennart Poettering]

On Di, 27.02.18 12:44, D.S. Ljungmark (ljungm...@modio.se) wrote:

> Hi list!
> 
>  We're using systemd to control the hardware watchdog, and would want to
> induce fail state to _verify_ that the shutdown/reboot process works as
> expected.
> 
> How do we make systemd "fail" to ping the watchdog?

I figure you can send SIGSTOP to PID 1, no? (there are some signals
the kernel blocks for PID 1, but I think SIGSTOP is not among them,
please try)

> How do we control which states ( root fs not available, etc) cause
> systemd to not ping the hardware watchdog?

The watchdog is for detecting software hanging. Root fs not being
available does not really qualify as "software hanging". If you want
to reboot the machine if it fails to bring everything up, then use
JobTimeoutAction= on some suitable action, for example local-fs.target
or multi-user.target.

Lennart

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

[systemd-devel] Triggering the HW Watchdog

[D.S. Ljungmark]

Hi list!

 We're using systemd to control the hardware watchdog, and would want to
induce fail state to _verify_ that the shutdown/reboot process works as
expected.

How do we make systemd "fail" to ping the watchdog?

How do we control which states ( root fs not available, etc) cause
systemd to not ping the hardware watchdog?

//D.S.
-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Create a target unit to start & stop a group of services

[林自均]

Hi Jérémy,

Thank you, but I read the section "Mapping of unit properties to their
inverses" in the man page
https://www.freedesktop.org/software/systemd/man/systemd.unit.html and then
found out the PropagatesReloadTo= and ReloadPropagatedFrom= are inverses to
each other and both can be configured in a unit file. I was wondering why
PartOf= and ConsistsOf= are not the case. Thank you.

John Lin


Jérémy Rosen  於 2018年2月27日 週二 下午4:35寫道：

>
>
> On 27/02/2018 02:49, 林自均 wrote:
>
> Hi both Michal,
>
> Thank you for the quick responses! I think I will keep on using the tedious
> PartOf= directive.
>
> However, may I ask why ConsistsOf= is readonly? If I can use it in my
> "my-apps.target", that would be great.
>
> Because "ConsistsOf" doesn't exist in the way you think it does...
>
> Every relation between units (Wants, Before, PartOf) needs to have an
> internal, reverse relation for accounting purpose
>
> That reverse relation is usually an internal detail, but it is handy to
> expose
> it in "systemctl show" & co.
>
> So that's what you see, an internal property exposed for ease-of-use. not
> an
> external, user configurable property
>
>
>
> John Lin
>
> Michal Koutný   於 2018年2月26日 週一 下午7:28寫道：
>
>
>
>
> On 02/26/2018 11:08 AM, Michal Sekletar wrote:
>
> Unfortunately, we don't have a dependency (AFAIK) that only propagates
> stop actions.
>
> FTR (not helpful for the original problem), there exists ConsistsOf= as
> an inverse of PartOf= dependency. However, it's read only currently (or
> strictly speaking, writable through the PartOf= endpoint).
>
> Michal
>
> ___
> systemd-devel mailing 
> listsystemd-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> ___
> systemd-devel mailing 
> listsystemd-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
> --
> [image: SMILE] 
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Jérémy ROSEN*
> Architecte technique
> Responsable de l'expertise Smile-ECS
>
> [image: email] jeremy.ro...@smile.fr
> [image: phone] +33141402967 <+33%201%2041%2040%2029%2067>
> [image: url] http://www.smile.eu
>
> [image: Twitter]  [image: Facebook]
>  [image: LinkedIn]
>  [image: Github]
> 
>
> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
> 
>
> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
> ___
> 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] Cleanest way to halt a VM after a service has stopped

[Lennart Poettering]

On Mo, 26.02.18 15:54, Filipe Brandenburger (filbran...@google.com) wrote:

> Hi,
> 
> I found it's possible to halt a VM after a service has stopped by
> using something like this:
> 
> ExecStopPost=/sbin/halt -p
> 
> Is this the cleanest approach? Or would anyone have a better
> recommendation (perhaps using systemd-halt.service or similar)?

There's FailureAction= and SuccessAction=. Set both to "poweroff". See
systemd.unit(5) for details.

Lennart

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

Re: [systemd-devel] Create a target unit to start & stop a group of services

[Jérémy Rosen]

On 27/02/2018 02:49, 林自均 wrote:

Hi both Michal,

Thank you for the quick responses! I think I will keep on using the tedious
PartOf= directive.

However, may I ask why ConsistsOf= is readonly? If I can use it in my
"my-apps.target", that would be great.

Because "ConsistsOf" doesn't exist in the way you think it does...

Every relation between units (Wants, Before, PartOf) needs to have an
internal, reverse relation for accounting purpose

That reverse relation is usually an internal detail, but it is handy to 
expose

it in "systemctl show" & co.

So that's what you see, an internal property exposed for ease-of-use. not an
external, user configurable property


John Lin

Michal Koutný  於 2018年2月26日 週一 下午7:28寫道：



On 02/26/2018 11:08 AM, Michal Sekletar wrote:

Unfortunately, we don't have a dependency (AFAIK) that only propagates
stop actions.

FTR (not helpful for the original problem), there exists ConsistsOf= as
an inverse of PartOf= dependency. However, it's read only currently (or
strictly speaking, writable through the PartOf= endpoint).

Michal

___
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


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel