Re: [systemd-devel] Systemd DBus API doc on wiki

[Jacob Floyd]

On Tue, Nov 28, 2017 at 3:57 PM, Jacob Floyd <
cognifloyd+ml.systemd.de...@gmail.com> wrote:

> 2) =
>
> First property of Manager: https://www.freedesktop.org/
> wiki/Software/systemd/dbus/#properties
>
> *Version* encodes the version string of the running systemd instance.
>> Note that the version string is purely informational, it should not be
>> parsed, one may not assume the version to be formatted in any particular
>> way. We take the liberty to change the versioning scheme at any time and it
>> is not part of the API.
>
>
> And in the gdbus introspect examples:
>
> properties:
>>   readonly s Version = 'systemd 205';
>
>
> So, the Version has, as promised, changed format. I just tested in 219
> (Centos 7) and 233 (Gentoo), and the dbus Version is only the version
> number: "219" or "233" respectively, unlike "systemd 205" in the example.
> Is version still considered internal API? Do you still discourage using
> the Version string via dbus?
>

It looks like the format of the Version property changed in v209 with
https://github.com/systemd/systemd/commit/718db96199eb307751264e4163555662c9a389fa#diff-b3e16bf39e5d7ab233077b9b1dafb095
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] udev rules: add by-location symlinks to nvme devices

[systemd github import bot]

Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v2] udev rules: add by-location symlinks to nvme devices

[Charles.Rose]

On systems with multiple 2.5-inch form factor PCIe SSD devices, locating the
physical drive can be made easier with symlinks that contain the drive bay
and slot information like this:

   /dev/disk/by-path/PCIe_SSD_in_Slot_9_Bay_1-nvme0n1 -> ../../nvme0n1
   /dev/disk/by-path/PCIe_SSD_in_Slot_9_Bay_1-nvme0n2 -> ../../nvme0n2
   /dev/disk/by-path/PCIe_SSD_in_Slot_9_Bay_1-nvme1n1 -> ../../nvme1n1

The bay/slot information is read from the sysfs label attribute available for
each NVMe device.

v2: Incorporate Lennart's feedback
   Do not shell out to "tr".
   Create link in "by-path", not "by-location".
   Remove "DRIVERS==nvme" check.
   Do not make the rule vendor specific.

Signed-off-by: Charles Rose 
---
 rules/60-persistent-storage.rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rules/60-persistent-storage.rules 
b/rules/60-persistent-storage.rules
index 0de8cf3a1..2d3f7dc72 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -19,6 +19,8 @@ ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
 KERNEL=="nvme*[0-9]n*[0-9]", ATTR{wwid}=="?*", 
SYMLINK+="disk/by-id/nvme-$attr{wwid}"
 KERNEL=="nvme*[0-9]n*[0-9]p*[0-9]", ENV{DEVTYPE}=="partition", 
ATTRS{wwid}=="?*", SYMLINK+="disk/by-id/nvme-$attr{wwid}-part%n"
 
+KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{label}=="?*", 
SYMLINK+="disk/by-path/$attr{label}-%k", OPTIONS="string_escape=replace"
+
 KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{serial}=="?*", 
ENV{ID_SERIAL_SHORT}="$attr{serial}"
 KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{wwid}=="?*", 
ENV{ID_WWN}="$attr{wwid}"
 KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*", 
ENV{ID_MODEL}="$attr{model}"
-- 
2.14.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Systemd DBus API doc on wiki

[Jacob Floyd]

Could someone update this doc:

https://www.freedesktop.org/wiki/Software/systemd/dbus/

The history says it was last updated Feb 2014, so I think it's out of date,
but I don't know enough about what's changed to update it. (If you want to
explain it, I can try to write it up, and then I'll have to figure out how
to get write access to update it)

Here are the issues I see.

1) =

Fourth paragraph of the introduction:

In contrast to most of the other services of the systemd suite PID 1 does
> not use PolicyKit for controlling access to privileged operations, but
> relies exclusively on the low-level D-Bus policy language. (This is done in
> order to avoid a cyclic dependency between PolicyKit and systemd/PID 1.)
> This means that sensitive operations exposed by PID 1 on the bus are
> generally not available to unprivileged processes directly.


Are there any docs about how to configure systemd access via polkit? I
think this changed with these commits (Aug 2014, Sep 2015)
https://github.com/systemd/systemd/commit/283868e1dcd8ea7475850d9c6e7d4722c473dd50
https://github.com/systemd/systemd/commit/88ced61bf9673407f4b15bf51b1b408fd78c149d

There are probably other commits that my search didn't turn up.

2) =

First property of Manager:
https://www.freedesktop.org/wiki/Software/systemd/dbus/#properties

*Version* encodes the version string of the running systemd instance. Note
> that the version string is purely informational, it should not be parsed,
> one may not assume the version to be formatted in any particular way. We
> take the liberty to change the versioning scheme at any time and it is not
> part of the API.


And in the gdbus introspect examples:

properties:
>   readonly s Version = 'systemd 205';


So, the Version has, as promised, changed format. I just tested in 219
(Centos 7) and 233 (Gentoo), and the dbus Version is only the version
number: "219" or "233" respectively, unlike "systemd 205" in the example.
Is version still considered internal API? Do you still discourage using the
Version string via dbus?

3) =

I've seen Manager.ListUnitsFiltered and Manager.ListUnitsByName in various
places (Introspection or comments or commits online), but they're not on
the page.

It would be nice to have them there, perhaps mentioning in which the
version they were added to systemd.

4) =

Is there anything else on that page that should be updated due to changes
in the last (almost) 4 years?

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

[systemd-devel] "service failed because a configured resource limit was exceeded" for service whose ExecStart command works without systemd

[Doug Snyder]

I am trying to create a systemd service to manage the celery task queue

My service file is :
[Unit]
Description=Celery bf Service
After=network.target

[Service]
Type=forking
User=doug
Group=doug
WorkingDirectory=/home/doug/www/my_project
ExecStart=/home/doug/.virtualenvs/bf-env/bin/celery-A tasks worker
 --app=tasks.celery_app:app   --logfile=/var/log/celery/bf/%n%I.log
 --loglevel=INFO   -Ofair --time-limit=300

When I run:
$ systemctl start celery_bf.service
I get:
Job for celery_bf.service failed because a configured resource limit was
exceeded. See "systemctl status celery_bf.service" and "journalctl -xe" for
details.

$ systemctl status celery_bf.service
● celery_bf.service - Celery bf Service
   Loaded: loaded (/etc/systemd/system/celery_bf.service; enabled; vendor
preset: disabled)
   Active: failed (Result: resources)

Nov 20 13:57:20 stower systemd[1]: celery_bf.service failed.
Nov 20 13:57:20 stower systemd[1]: Starting Celery bf Service...
Nov 20 13:58:33 stower systemd[1]: celery_bf.service failed to run 'start'
task: Operation not supported
Nov 20 13:58:33 stower systemd[1]: Failed to start Celery bf Service.
Nov 20 13:58:33 stower systemd[1]: celery_bf.service failed.
Nov 20 13:58:33 stower systemd[1]: Starting Celery bf Service...
Nov 20 14:06:03 stower systemd[1]: celery_bf.service failed to run 'start'
task: Operation not supported
Nov 20 14:06:03 stower systemd[1]: Failed to start Celery bf Service.
Nov 20 14:06:03 stower systemd[1]: celery_bf.service failed.
Nov 20 14:06:03 stower systemd[1]: Starting Celery bf Service...

$ journalctl -xe
Nov 20 14:05:12 stower polkitd[29785]: Unregistered Authentication Agent
for unix-process:11449:78569047 (system bus name :1.1184, object path
/org/freedesktop
Nov 20 14:06:00 stower polkitd[29785]: Registered Authentication Agent for
unix-process:11476:78574149 (system bus name :1.1187 [/usr/bin/pkttyagent
--notify-f
Nov 20 14:06:03 stower polkitd[29785]: Operator of
unix-process:11476:78574149 successfully authenticated as unix-user:doug to
gain ONE-SHOT authorization for
Nov 20 14:06:03 stower systemd[1]: celery_bf.service failed to run 'start'
task: Operation not supported
Nov 20 14:06:03 stower systemd[1]: Failed to start Celery bf Service.
-- Subject: Unit celery_bf.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit celery_bf.service has failed.
-- 
-- The result is failed.
Nov 20 14:06:03 stower systemd[1]: celery_bf.service failed.
Nov 20 14:06:03 stower systemd[1]: Starting Celery bf Service...
-- Subject: Unit celery_bf.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit celery_bf.service has begun starting up.

It appears that something is wrong with the ExecStart command,
But when I cut and paste the same command into the command line it works as
expected and celery starts without any issues

Any help Would be appreciated
Thanks,
Doug
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Question]: About systemctl and its related commands

[千葉幹正]

Thank you.

I know have a deeper understanding of the this topic :)

Regards.
Chiba

2017年11月28日(火) 23:32 Lennart Poettering :

> f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote:
>
> > We have a few questions about systemctl and -H option.
> >
> > It looks like systemctl is communicating with /run/systemd/private in
> order
> > to interact with systemd.
> >
> > However, after you log in the connected computer via ssh, it looks like
> > it's trying to control systemd by going through systemd-stdio-bridge when
> > you use systemctl's -H option.
> >
> > Instead of going through /run/systemd/private, it looks like
> > systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which
> is
> > usually created by dbus daemon) in order to control systemd.
> >
> > This where we run into the following 2 questions:
> >
> > 1. Is it necessary to start up dbus daemon on the computer we're
> connecting
> > to in order to control systemd by using the systemctl -H option?
>
> Currently, yes. And I doubt this will change anytime soon.
>
> D-Bus is designed around a bus concept: all services are available on
> the same IPC bus. That's usually a good thing, as that means systemctl
> can talk to all services it needs to through a single IPC
> connection. systemctl talks to a number of daemons actually, not just
> PID 1: for example, it also talks to logind and policykit.
>
> If the private IPC socket is used a very limited way of IPC is
> available only: since the other side is PID 1 and PID 1 only, there's
> no hookup with polkit, and communication with logind is not
> available. Moreover a couple of peer tracking concepts in PID 1 are
> disabled for such "direct" connections, as a peer concept is not
> really existing for such connections that do not involve a bus.
>
> systemctl currently contains some logic to use the private socket
> (i.e. a direct connection) automatically in a number of cases,
> preferring it over the bus. It does that so that systemctl can talk to
> systemd during early boot too (when dbus-daemon is not up yet, hence
> the proper bus is not available), as well as when the system is really
> hosed (so that you can still debug things and shut things down). The
> direct connections however are a very specific hack in systemctl
> ultimately, done under very specific conditions, in order to deal with
> a very specific set of problems. When PK or logind involvement is
> needed, when the caller is not privileged and so on, the direct
> connections are not used. Now, the ssh transport (i.e. -H) doesn't
> know about all this, and cannot possibly guess what systemctl actually
> wants to do, hence it is exclusively a gateway to the full bus, it
> contains no special hookup with the private socket. Moreover, ssh is
> a late boot service anyway, i.e. dbus is already up at that moment,
> hence the early-boot reason for the private socket doesn't even apply
> to remote connections at all..
>
> > 2. Are we correct in our understanding that /run/systemd/private exists
> to
> > control systemctl though the local systemd?
>
> the private socket is an implementation detail between systemctl and
> systemd, to support the aforementioned usecases. It's not a public
> API (which is the reason btw, why it is called 'private'…), it's not
> fully featured, and it should not be used except under very well
> defined conditions, and remote access does not fall under that.
>
> > Why does systemctl use the specialized interface called
> > /run/systemd/private to control systemd?
> > Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> > like systemctl does?
>
> Besides the fact that systemctl talks to logind and so on, the stdio
> bridge is also used by the various other tools in systemd, including
> machinectl, loginctl, busctl, systemd-run, … Since they generally talk
> to other daemons than just PID 1 a full ybus connection is required.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
-- 
KLab株式会社 インフラマネジメント部
千葉 幹正 chib...@klab.com

 [東京本社]
  〒106-6122 東京都港区六本木6-10-1 六本木ヒルズ森タワー22F
  TEL：03-5771-1818  / FAX：03-3403-8520
 [地方・海外拠点]
仙台/大阪/福岡/シンガポール/上海
 [弊社HP]
  http://www.klab.com/jp/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] A server says: "System is going down." But never does.

[Yuri Kanivetsky]

Hi,

This mailing list is the only place where I expect to have some
helpful feedback. But feel free to suggest other places. I'd like to
investigate situation I have now, find out what went wrong and prevent
it from happening again if possible. Your help is appreciated.

Like I said, a server reports that it's going down, when I ssh to it
as root. As a non-root user, it says that and closes the connection.

In the journal I see a lot of this:


Nov 28 16:22:01 st2 systemd-journal[353]: Journal stopped
Nov 28 16:22:01 st2 systemd-journal[494]: Runtime journal is using
624.0M (max allowed 642.1M, trying to leave 963.1M free of 5.6G
available → current limit 642.1M).
Nov 28 16:22:01 st2 systemd-journal[494]: Runtime journal is using
624.0M (max allowed 642.1M, trying to leave 963.1M free of 5.6G
available → current limit 642.1M).
Nov 28 16:22:01 st2 systemd-journal[494]: Journal started
Nov 28 16:22:01 st2 systemd[1]: systemd-journald.service watchdog
timeout (limit 1min)!
Nov 28 16:22:01 st2 systemd-journald[353]: Received SIGTERM from PID 1
(systemd).
Nov 28 16:22:01 st2 systemd[1]: Unit systemd-journald.service entered
failed state.
Nov 28 16:22:01 st2 systemd[1]: systemd-journald.service has no
holdoff time, scheduling restart.
Nov 28 16:22:01 st2 systemd[1]: Stopping Journal Service...
Nov 28 16:22:01 st2 systemd[1]: Starting Journal Service...
Nov 28 16:22:01 st2 systemd[1]: Started Journal Service.
Nov 28 16:22:01 st2 systemd[1]: Starting Trigger Flushing of Journal
to Persistent Storage...
Nov 28 16:22:01 st2 systemd[1]: systemd-journal-flush.service: main
process exited, code=exited, status=1/FAILURE
Nov 28 16:22:01 st2 systemd[1]: Failed to start Trigger Flushing of
Journal to Persistent Storage.
Nov 28 16:22:01 st2 systemd[1]: Unit systemd-journal-flush.service
entered failed state.


Nov 28 16:22:52 st2 systemd[1]: systemd-timesyncd.service start
operation timed out. Terminating.
Nov 28 16:22:52 st2 systemd[1]: Failed to start Network Time Synchronization.
Nov 28 16:22:52 st2 systemd[1]: Unit systemd-timesyncd.service entered
failed state.
Nov 28 16:22:53 st2 systemd[1]: systemd-timesyncd.service has no
holdoff time, scheduling restart.
Nov 28 16:22:53 st2 systemd[1]: Stopping Network Time Synchronization...
Nov 28 16:22:53 st2 systemd[1]: Starting Network Time Synchronization...


Nov 28 16:23:02 st2 systemd-journal[494]: Journal stopped
Nov 28 16:23:02 st2 systemd-journal[632]: Runtime journal is using
624.0M (max allowed 642.1M, trying to leave 963.1M free of 5.6G
available → current limit 642.1M).
Nov 28 16:23:02 st2 systemd-journal[632]: Runtime journal is using
624.0M (max allowed 642.1M, trying to leave 963.1M free of 5.6G
available → current limit 642.1M).
Nov 28 16:23:02 st2 systemd-journal[632]: Journal started
Nov 28 16:23:02 st2 systemd[1]: systemd-journald.service watchdog
timeout (limit 1min)!
Nov 28 16:23:02 st2 systemd-journald[494]: Received SIGTERM from PID 1
(systemd).
Nov 28 16:23:02 st2 systemd[1]: Unit systemd-journald.service entered
failed state.
Nov 28 16:23:02 st2 systemd[1]: systemd-journald.service has no
holdoff time, scheduling restart.
Nov 28 16:23:02 st2 systemd[1]: Stopping Journal Service...
Nov 28 16:23:02 st2 systemd[1]: Starting Journal Service...
Nov 28 16:23:02 st2 systemd[1]: Started Journal Service.
Nov 28 16:23:02 st2 systemd[1]: Starting Trigger Flushing of Journal
to Persistent Storage...
Nov 28 16:23:02 st2 systemd[1]: systemd-journal-flush.service: main
process exited, code=exited, status=1/FAILURE
Nov 28 16:23:02 st2 systemd[1]: Failed to start Trigger Flushing of
Journal to Persistent Storage.
Nov 28 16:23:02 st2 systemd[1]: Unit systemd-journal-flush.service
entered failed state.


It repeats itself every minute.

systemctl doesn't work:


# systemctl
Failed to get D-Bus connection: Connection refused


I have 16 lxc containers running on the server:


# lxc-ls -f | grep RUNNING | wc -l
16


and 16 dbus-daemon's (so supposedly one dbus-daemon is missing):


# ps -ef | grep dbus
message+   845 1  0 Feb15 ?00:09:56 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
systemd+  1615   579  0 Jun13 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
root  1673 28602  0 16:26 pts/31   00:00:00 grep dbus
systemd+  3761  3461  0 Feb15 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
systemd+  4635  3436  0 Feb15 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
systemd+  4767  3527  0 Feb15 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
systemd+  5344  3597  0 Feb15 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
systemd+  5714  3664  0 Feb15 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: 

Re: [systemd-devel] [Question]: About systemctl and its related commands

[Lennart Poettering]

f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote:

> We have a few questions about systemctl and -H option.
> 
> It looks like systemctl is communicating with /run/systemd/private in order
> to interact with systemd.
> 
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
> 
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
> 
> This where we run into the following 2 questions:
> 
> 1. Is it necessary to start up dbus daemon on the computer we're connecting
> to in order to control systemd by using the systemctl -H option?

Currently, yes. And I doubt this will change anytime soon.

D-Bus is designed around a bus concept: all services are available on
the same IPC bus. That's usually a good thing, as that means systemctl
can talk to all services it needs to through a single IPC
connection. systemctl talks to a number of daemons actually, not just
PID 1: for example, it also talks to logind and policykit.

If the private IPC socket is used a very limited way of IPC is
available only: since the other side is PID 1 and PID 1 only, there's
no hookup with polkit, and communication with logind is not
available. Moreover a couple of peer tracking concepts in PID 1 are
disabled for such "direct" connections, as a peer concept is not
really existing for such connections that do not involve a bus.

systemctl currently contains some logic to use the private socket
(i.e. a direct connection) automatically in a number of cases,
preferring it over the bus. It does that so that systemctl can talk to
systemd during early boot too (when dbus-daemon is not up yet, hence
the proper bus is not available), as well as when the system is really
hosed (so that you can still debug things and shut things down). The
direct connections however are a very specific hack in systemctl
ultimately, done under very specific conditions, in order to deal with
a very specific set of problems. When PK or logind involvement is
needed, when the caller is not privileged and so on, the direct
connections are not used. Now, the ssh transport (i.e. -H) doesn't
know about all this, and cannot possibly guess what systemctl actually
wants to do, hence it is exclusively a gateway to the full bus, it
contains no special hookup with the private socket. Moreover, ssh is
a late boot service anyway, i.e. dbus is already up at that moment,
hence the early-boot reason for the private socket doesn't even apply
to remote connections at all..

> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?

the private socket is an implementation detail between systemctl and
systemd, to support the aforementioned usecases. It's not a public
API (which is the reason btw, why it is called 'private'…), it's not
fully featured, and it should not be used except under very well
defined conditions, and remote access does not fall under that.

> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?

Besides the fact that systemctl talks to logind and so on, the stdio
bridge is also used by the various other tools in systemd, including
machinectl, loginctl, busctl, systemd-run, … Since they generally talk
to other daemons than just PID 1 a full ybus connection is required.

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] failed to schedule restart job: Transaction is destructive.

[prashantkumar dhotre]

Exec StopPost script writes to log file and writes to zookeeper.
I have checked that , that script takes Max 2 sec to finish.
To recreate issue, I have tried doing mre work in the script so that script
take more than 1 min but I could not recreate issue

On Nov 28, 2017 4:34 PM, "Mantas Mikulėnas"  wrote:

> On Tue, Nov 28, 2017 at 11:14 AM, prashantkumar dhotre <
> prashantkumardho...@gmail.com> wrote:
>
>> Hi
>> Sometimes i see that service restart fails with
>> systemd[1]: *my.service failed to schedule restart job: Transaction is
>> destructive.*
>>
>> above error is very rare.
>> I have defined ExecStopPost script in my service file.
>> this problem does not always happen and  there is no defined steps to
>> recreate this.
>> Any idea what may cause above error ? is it ExecStopPost  script.
>>
>
> What does your ExecStopPost script do?
>
> --
> Mantas Mikulėnas 
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] failed to schedule restart job: Transaction is destructive.

[Mantas Mikulėnas]

On Tue, Nov 28, 2017 at 11:14 AM, prashantkumar dhotre <
prashantkumardho...@gmail.com> wrote:

> Hi
> Sometimes i see that service restart fails with
> systemd[1]: *my.service failed to schedule restart job: Transaction is
> destructive.*
>
> above error is very rare.
> I have defined ExecStopPost script in my service file.
> this problem does not always happen and  there is no defined steps to
> recreate this.
> Any idea what may cause above error ? is it ExecStopPost  script.
>

What does your ExecStopPost script do?

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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[systemd github import bot]

Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

From: Pekka Paalanen 

There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.

This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.

The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.

The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.

Fixes: https://phabricator.freedesktop.org/T63

Cc: martyn.we...@collabora.co.uk
Cc: fabien.lahoud...@collabora.co.uk
Cc: matt.hoos...@gmail.com
Cc: sjoerd.sim...@collabora.co.uk
Signed-off-by: Pekka Paalanen 

---

Hi all,

I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
 doc/systemd/README | 45 +++
 doc/systemd/weston.service | 66 ++
 2 files changed, 111 insertions(+)
 create mode 100644 doc/systemd/README
 create mode 100644 doc/systemd/weston.service

diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index ..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+   Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login 
--enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+This can be done on the Weston command line:
+
+$ weston --modules=systemd-notify.so
+
+or in weston.ini:
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+   weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index ..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[Unit]
+Description=Weston, a Wayland compositor, as a system service
+Documentation=man:weston(1) man:weston.ini(5)
+Documentation=http://wayland.freedesktop.org/
+
+# Make sure we are started after logins are permitted.
+After=systemd-user-sessions.service
+
+# If Plymouth is used, we want to start when it is on its way out.
+After=plymouth-quit-wait.service
+
+# D-Bus is necessary for contacting logind. Logind is required.
+Wants=dbus.socket
+After=dbus.socket
+
+# This scope is created by pam_systemd when logging in as the user.
+# This directive is a workaround to a systemd bug, where the setup of the
+# user session by PAM has some race condition, possibly leading to a failure.
+# See README for more details.
+After=session-c1.scope
+
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+Before=graphical.target
+
+# 

Re: [systemd-devel] What is the recommended way to setup the compose key ?

[Francis Moreau]

On Tue, Nov 28, 2017 at 9:57 AM, Mantas Mikulėnas  wrote:

>
> And where would it get the actual compose definitions from? They have to be
> defined in the keymap itself.
>

on my distro (opensuse Tumbleweed) compose tables and the definition
of the compose key can be found here:

$ ls /usr/share/kbd/keymaps/legacy/include/
compose.8859_7  compose.latin   compose.latin1.cedilla
compose.latin4 compose.winkeys
compose.8859_8  compose.latin1  compose.latin2
compose.shiftctrl  disable.capslock
compose.ctrlperiod  compose.latin1.add  compose.latin3
compose.utf8   vim-compose.latin1

So one can configure the compose key by running "loadkeys
compose.shiftctrl" for example and the same can be done to pick up a
compose table.

It doesn't seem a bad idea to extend /etc/vconsole.conf so it's done
automatically at boot.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] failed to schedule restart job: Transaction is destructive.

[prashantkumar dhotre]

Hi
Sometimes i see that service restart fails with
systemd[1]: *my.service failed to schedule restart job: Transaction is
destructive.*

above error is very rare.
I have defined ExecStopPost script in my service file.
this problem does not always happen and  there is no defined steps to
recreate this.
Any idea what may cause above error ? is it ExecStopPost  script.
how to resolve that ?
thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What is the recommended way to setup the compose key ?

[Mantas Mikulėnas]

On Tue, Nov 28, 2017 at 10:54 AM, Francis Moreau 
wrote:

> On Tue, Nov 28, 2017 at 9:46 AM, Mantas Mikulėnas 
> wrote:
> > On Tue, Nov 28, 2017 at 10:35 AM, Francis Moreau  >
> > wrote:
> >>
> >> Hello,
> >>
> >> I'm trying to figure out how I can configure a compose key for the
> >> consoles.
> >>
> >> I looked at man localectl and vconsole.conf but haven't found an answer.
> >
> >
> > You'd need to edit the actual keyboard layout in /usr/share/kbd/keymaps.
> See
> > i386/include/compose.inc and i386/qwerty/{cz,lv}.map.gz for examples.
>
> Do you mean I need to edit my preferred map in /usr/share to include
> compose.inc ?
>

You will need more than that – grep the other examples for 'compose'.


> If so I don't think I'm supposed to change any files in /usr/share/kbd...
>

Probably not, but that's the only location keymaps are loaded from (whether
you use systemd or regular loadkeys).


> Wouldn't it be simpler to add the compose key in vconsole.conf so it's
> loaded automatically ?
>

And where would it get the actual compose definitions from? They have to be
defined in the keymap itself.

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

Re: [systemd-devel] What is the recommended way to setup the compose key ?

[Francis Moreau]

On Tue, Nov 28, 2017 at 9:46 AM, Mantas Mikulėnas  wrote:
> On Tue, Nov 28, 2017 at 10:35 AM, Francis Moreau 
> wrote:
>>
>> Hello,
>>
>> I'm trying to figure out how I can configure a compose key for the
>> consoles.
>>
>> I looked at man localectl and vconsole.conf but haven't found an answer.
>
>
> You'd need to edit the actual keyboard layout in /usr/share/kbd/keymaps. See
> i386/include/compose.inc and i386/qwerty/{cz,lv}.map.gz for examples.

Do you mean I need to edit my preferred map in /usr/share to include
compose.inc ?

If so I don't think I'm supposed to change any files in /usr/share/kbd...

Wouldn't it be simpler to add the compose key in vconsole.conf so it's
loaded automatically ?

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

Re: [systemd-devel] What is the recommended way to setup the compose key ?

[Mantas Mikulėnas]

On Tue, Nov 28, 2017 at 10:35 AM, Francis Moreau 
wrote:

> Hello,
>
> I'm trying to figure out how I can configure a compose key for the
> consoles.
>
> I looked at man localectl and vconsole.conf but haven't found an answer.
>

You'd need to edit the actual keyboard layout in /usr/share/kbd/keymaps.
See i386/include/compose.inc and i386/qwerty/{cz,lv}.map.gz for examples.

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

[systemd-devel] What is the recommended way to setup the compose key ?

[Francis Moreau]

Hello,

I'm trying to figure out how I can configure a compose key for the consoles.

I looked at man localectl and vconsole.conf but haven't found an answer.

Could anybody give me some hints ?

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

Re: [systemd-devel] [Question]: About systemctl and its related commands

[aleivag]

Hi, i asked similar question a few weeks ago, and you probably will get a
oficial answer soon :P, but in a nutshell would be:

/run/systemd/private is a private socket and its meant for systemd tools to
communicate with systemd even if dbus daemon is down. this is specially
true during boot and shutdown, but you should never try to use the private
sockets for anything, always use dbus sockets, because (in Lennard's words,
not mine) "systemd sucks as a bus replacement". if posible, even forget
that /run/systemd/private exists :P.

after playing around a lot with servers i agree with previous statements,
and always prefere dbus over private.

hope that helps.


Alvaro

On Mon, Nov 27, 2017 at 11:16 PM, 千葉幹正  wrote:

> We have a few questions about systemctl and -H option.
>
> It looks like systemctl is communicating with /run/systemd/private in
> order to interact with systemd.
>
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
>
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
>
> This where we run into the following 2 questions:
>
> 1. Is it necessary to start up dbus daemon on the computer we're
> connecting to in order to control systemd by using the systemctl -H option?
>
> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?
>
> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?
>
> Any information you can provide about the above would be much appreciated!
> Thanks in advance for your time and all your help.
>
> All the best,
>
> Chiba
> KLab Inc.
>
> ___
> 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