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

[林自均]

Anyone?

John Lin

林自均  於 2018年2月27日 週二 下午6:20寫道：

> 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

[systemd-devel] [ANNOUNCE] systemd v238

[Zbigniew Jędrzejewski-Szmek]

Hi,

systemd-238 has been tagged.

https://github.com/systemd/systemd/archive/v238/systemd-238.tar.gz

CHANGES WITH 238:

* The MemoryAccounting= unit property now defaults to on. After
  discussions with the upstream control group maintainers we learnt
  that the negative impact of cgroup memory accounting on current
  kernels is finally relatively minimal, so that it should be safe to
  enable this by default without affecting system performance. Besides
  memory accounting only task accounting is turned on by default, all
  other forms of resource accounting (CPU, IO, IP) remain off for now,
  because it's not clear yet that their impact is small enough to move
  from opt-in to opt-out. We recommend downstreams to leave memory
  accounting on by default if kernel 4.14 or higher is are primarily
  used. On very resource constrained systems or when support for old
  kernels is a necessity, -Dmemory-accounting-default=false can be used
  to revert this change.

* rpm scriptlets to update the udev hwdb and rules (%udev_hwdb_update,
  %udev_rules_update) and the journal catalog (%journal_catalog_update)
  from the upgrade scriptlets of individual packages now do nothing.
  Transfiletriggers have been added which will perform those updates
  once at the end of the transaction.

  Similar transfiletriggers have been added to execute any sysctl.d
  and binfmt.d rules. Thus, it should be unnecessary to provide any
  scriptlets to execute this configuration from package installation
  scripts.

* systemd-sysusers gained a mode where the configuration to execute is
  specified on the command line, but this configuration is not executed
  directly, but instead it is merged with the configuration on disk,
  and the result is executed. This is useful for package installation
  scripts which want to create the user before installing any files on
  disk (in case some of those files are owned by that user), while
  still allowing local admin overrides.

  This functionality is exposed to rpm scriplets through a new
  %sysusers_create_package macro. Old %sysusers_create and
  %sysusers_create_inline macros are deprecated.

  A transfiletrigger for sysusers.d configuration is now installed,
  which means that it should be uncessary to call systemd-sysusers from
  package installation scripts, unless the package installs any files
  owned by those newly-created users, in which case
  %sysusers_create_package should be used.

* Analogous change has been done for systemd-tmpfiles: it gained a mode
  where the command-line configuration is merged with the configuration
  on disk. This is exposed as the new %tmpfiles_create_package macro,
  and %tmpfiles_create is deprecated. A transfiletrigger is installed
  for tmpfiles.d, hence it should be unnecessary to call 
systemd-tmpfiles
  from package installation scripts.

* sysusers.d configuration for a user may now also specify the group
  number, in addition to the user number ("u username 123:456"), or
  without the user number ("u username -:456").

* Configution items for systemd-sysusers can now be specified as
  positional arguments when the new --inline switch is used.

* The login shell of users created through sysusers.d may now be
  specified (previously, it was always /bin/sh for root and
  /sbin/nologin for other users).

* systemd-analyze gained a new --global switch to look at global user
  configuration. It also gained a unit-paths verb to list the unit load
  paths that are compiled into systemd (which can be used with
  --systemd, --user, or --global).

* udevadm trigger gained a new --settle/-w option to wait for any
  triggered events to finish (but just those, and not any other events
  which are triggered meanwhile).

* The action that systemd-logind takes when the lid is closed and the
  machine is connected to external power can now be configured using
  HandleLidSwitchExternalPower= in logind.conf. Previously, this action
  was determined by HandleLidSwitch=, and, for backwards compatibility,
  is still is, if HandleLidSwitchExternalPower= is not explicitly set.

* journalctl will periodically call sd_journal_process() to make it
  resilient against inotify queue overruns when journal files are
  rotated very quickly.

* Two new functions in libsystemd — sd_bus_get_n_queued_read and
  sd_bus_get_n_queued_write — may be used to check the number of
  pending bus messages.

* systemd gained a new
  

Re: [systemd-devel] RFC: enable suspend to idle

[Oliver Neukum]

On Fri, 2018-03-02 at 10:18 +0100, Lennart Poettering wrote:

> But why wouldn't that be a kernel option? I mean, so far the goal was
> to encode "reasonable defaults" in the kernel itself, so that
> userspace is only used when those "reasonable defaults" do not apply
> onto one local case.
> 
> Really, already for compatibility reasons the kernel should just carry
> the "reasonable defaults", so that it's not necessary to match it up
> with a udev version that carries the right policy for it.

Well, no. The kernel must carry conservative defaults that do no harm
in any case. Setting defaults sensible for the class of systems systemd
runs on is the job of udev.

For now we are running with defaults taken from firmware, which can be
expected to be tailored to the system it comes with.
Falling back to conservative defaults would mean a regression in
functionality.

Regards
Oliver


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