[systemd-devel] make pystemd part of systemd repo.

[aleivag]

Hello systemd developers:

We talked last week about entertaining the idea of make pystemd part of
systemd github org and eventually merge (in functionalities, not literally
merge both) with the current python-systemd, This is our proposal to do
this. happy to hear feedback :)

What do we propose to do?
-

We want to bring pystemd[1] into the systemd organization, and merge
(functionality wise) with python-systemd[2], so that there is a single
Python library, supported by the systemd community, that interacts with the
systemd API.

Why?
-

systemd has a Python library already under the organization:
python-systemd. This library does some interesting stuff with the journal
(my personal favorite is creating a Python logger that talks directly with
the journal, kudos to whoever did that!).

But in my honest opinion, this library is missing some core functionality
to interact with systemd: the service manager, start/stop/interaction with
Units, create ephemeral units, etc. At Meta (the company formerly known as
Facebook) we created a python library that does that… among other things.

What is pystemd?
-

pystemd, at its core, is a Python library that allows users to talk to
systemd over dbus, without thinking that you are talking to systemd over
dbus. It does this by binding sd_bus and other sd_* libraries from C to
Python.

This enables users to interact with systemd in many ways. Most notably, but
not restricted to, start/stop/kill and checking the status of units.

It was created because Instagram (at the time) needed to expose systemd
features, like managing units, creating ephemeral units, using the notify
and watchdog interface, etc. to Python and reduce the need to “shell-out”
in order to parse results.

Example of usage:

from pystemd.systemd1 import Unit

with Unit(b'postfix.service') as unit:
   if unit.Unit.ActiveState == b"active":
   unit.Unit.Stop(b'replace')


Or

from pystemd.systemd1 import Manager

with Manager() as manager:
   print("Version", manager.Manager.Version)
   print("Architecture", manager.Manager.Architecture)

   # List Units
   for unit, state in manager.Manager.ListUnitFiles():
   print(f"{unit} is {state}")


It does a few more things (I won't bore you with details), but my
particular favorite is an analogous feature to systemd-run called
pystemd.run. It’s similar to systemd-run in that it is a smart wrapper
around StartTransientUnit. But it's meant to be “programatically called”
instead of a CLI.

>>> import pystemd.run, time
>>> unit = pystemd.run(
[b'/usr/bin/psql', b'postgres'],
machine=b'db1',
user=b'postgres',
wait=False,
env={b'PGTZ': b'UTC'}
)
>>> time.sleep(300)
>>> unit.Unit.Stop(b'postgres') # you lived too long, time to stop


If you want to know more, Anita Zhang and I did a talk in SCaLE [3] where
we abused pystemd.

How do we propose to do this?
-

Preliminary plan (of course we are open to any suggestions) look like this:

1. We move pystemd repo [1] into the systemd org, something like
https://github.com/systemd/pystemd
2. People with commit access to this repo (Davide, Anita and me) would
remain having commit access to this repo, and whoever has access to the
python-systemd repo [2] would be added here.
3. We merge all features of python-systemd (that are not in pystemd yet)
into pystemd, this will probably mean re-writing most of those features.
Development would be done by mostly me, with code review and from hopefully
as close to the original authors as possible… Basically I don't want to be
disrespectful of python-systemd.
4. If we want to keep the name python-systemd (and the import namespace of
systemd) we can rename the repo as python-systemd, if we want to keep
pystemd as the name of the package and the import namespace, we can make
python-systemd as “a link” to pystemd
5. Whatever we decide on the last point, we cut the version 1.0.0 of
pystemd, or the next version of python-systemd. And we let the new era of
Python bindings start!

Best regards
Alvaro Leiva Geisse

[1] https://github.com/facebookincubator/pystemd
[2] https://github.com/systemd/python-systemd
[3] https://youtu.be/FMnvvfBYypY?t=24789

Re: [systemd-devel] unit been dead before been running

[aleivag]

Hi all:

Sorry to bring this up again... here is what i plan to do, i'm just asking
if this make sense.

(the context is that i start a transient unit, and pass tty fd, and i need
to know when the unit is dead, so i can close my fds)
`systemd1.Manager.StartTransientUnit` returns a job in the form of
`/org/freedesktop/systemd1/job/`, so i'm just going to ignore all
messages that comes with that Job. Because those comes when the unit is
starting up.. the final `dead` of `failed` message comes with Job (0, '/')..

do that make sense?

Thanks!


Alvaro Leiva


On Mon, Feb 18, 2019 at 1:46 PM aleivag  wrote:

>
> Hi All:
>
> i notice a change of behaviour that broke a couple of my scripts between
> v239 and v240, and wanted to know that maybe i was always assuming the
> wrong thing, so here it goes:
>
> so i subscribe to
>
> "type='signal',"
> "sender='org.freedesktop.systemd1',"
> "path='/org/freedesktop/systemd1/unit/myu_2eservice',"
> "interface='org.freedesktop.DBus.Properties',"
> "member='PropertiesChanged'"
>
> on the bus, and then i start a transient unit like `systemd-run --pty
> --unit myu.service /bin/bash` .
>
> to do the subscribe to that event i use the following script, (its
> definitely not important the script i use but just show you for
> completeness),
>
> ```
> #!/usr/bin/python3
>
> from pprint import pprint
> import pystemd
> from pystemd.dbuslib import DBus
>
> with DBus() as bus, pystemd.DBus.Manager(bus=bus, _autoload=True) as man:
> mstr = (
> "type='signal',"
> "sender='org.freedesktop.systemd1',"
> "path='/org/freedesktop/systemd1/unit/myu_2eservice',"
> "interface='org.freedesktop.DBus.Properties',"
> "member='PropertiesChanged'"
> ).encode()
> man.Monitoring.BecomeMonitor([mstr], 0)
> while True:
> bus.wait(1000)
> m = bus.process()
> if m.is_empty():
> continue
>
> m.process_reply(False)
> if m.get_path() == b'/org/freedesktop/systemd1/unit/myu_2eservice':
> pprint(m.body)
> ```
>
>
> on systemd v239 and bellow before the unit is active i got only 2
> messages, one `org.freedesktop.systemd1.Service` and one on
> `org.freedesktop.systemd1.Unit`. the second one notify me that the
> "SubState" is "running". when the unit ends, i get 2 messages also, and the
> last one is to tell me that the "SubState" is "dead"
>
> on v240  on the other part, before the unit ready, i get 4 messages, one
> on `org.freedesktop.systemd1.Service` -> `org.freedesktop.systemd1.Unit` ->
> `org.freedesktop.systemd1.Service` -> `org.freedesktop.systemd1.Unit`,
> where the Unit ones the substate first is "dead" and then is "running", on
> deactivating, the messages are the same between 239 and 240.
>
> so i used to tell that the unit had finished, by inspecting the messages
> on the bus, and then looking for SubState to be any of ("exited", "failed",
> "dead"), but i cant do that now.
>
> at the end of the  email i copy the dumps on the 2 versions, but my
> questions are:
>
> 1.- Is this change in behaviour, intended, or a side effect of something
> else?
> 2.- was what i was doing the best way to decide if a transient unit has
> finished? i'm super temped to instead check when the
> `org.freedesktop.systemd1.Service.MainPID == 0` i think its the best idea,
> but maybe you guys have one that is better.
>
> thanks guys!!
>
> now i paste the messages:
>
> on v239
>
> on start
> [b'org.freedesktop.systemd1.Service',
>  {b'ControlPID': 0,
>   b'ExecMainCode': 0,
>   b'ExecMainExitTimestamp': 0,
>   b'ExecMainExitTimestampMonotonic': 0,
>   b'ExecMainPID': 18328,
>   b'ExecMainStartTimestamp': 1550516822984246,
>   b'ExecMainStartTimestampMonotonic': 41004687391,
>   b'ExecMainStatus': 0,
>   b'GID': 4294967295,
>   b'MainPID': 18328,
>   b'NRestarts': 0,
>   b'Result': b'success',
>   b'StatusErrno': 0,
>   b'StatusText': b'',
>   b'UID': 4294967295,
>   b'USBFunctionDescriptors': b'',
>   b'USBFunctionStrings': b''},
>  [b'ExecStartPre',
>   b'ExecStart',
>   b'ExecStartPost',
>   b'ExecReload',
>   b'ExecStop',
>   b'ExecStopPost']]
> [b'org.freedesktop.systemd1.Unit',
>  {b'ActiveEnterTimestamp': 1550516822984291,
>   b'ActiveEnterTimestampMonotonic': 41004687437,
>   b'ActiveExitTimestamp': 0,
>   b'ActiveExitTimestampMonotonic': 0,
>   b'ActiveState': b'active',
>   b'Asse

[systemd-devel] unit been dead before been running

[aleivag]

Hi All:

i notice a change of behaviour that broke a couple of my scripts between
v239 and v240, and wanted to know that maybe i was always assuming the
wrong thing, so here it goes:

so i subscribe to

"type='signal',"
"sender='org.freedesktop.systemd1',"
"path='/org/freedesktop/systemd1/unit/myu_2eservice',"
"interface='org.freedesktop.DBus.Properties',"
"member='PropertiesChanged'"

on the bus, and then i start a transient unit like `systemd-run --pty
--unit myu.service /bin/bash` .

to do the subscribe to that event i use the following script, (its
definitely not important the script i use but just show you for
completeness),

```
#!/usr/bin/python3

from pprint import pprint
import pystemd
from pystemd.dbuslib import DBus

with DBus() as bus, pystemd.DBus.Manager(bus=bus, _autoload=True) as man:
mstr = (
"type='signal',"
"sender='org.freedesktop.systemd1',"
"path='/org/freedesktop/systemd1/unit/myu_2eservice',"
"interface='org.freedesktop.DBus.Properties',"
"member='PropertiesChanged'"
).encode()
man.Monitoring.BecomeMonitor([mstr], 0)
while True:
bus.wait(1000)
m = bus.process()
if m.is_empty():
continue

m.process_reply(False)
if m.get_path() == b'/org/freedesktop/systemd1/unit/myu_2eservice':
pprint(m.body)
```


on systemd v239 and bellow before the unit is active i got only 2 messages,
one `org.freedesktop.systemd1.Service` and one on
`org.freedesktop.systemd1.Unit`. the second one notify me that the
"SubState" is "running". when the unit ends, i get 2 messages also, and the
last one is to tell me that the "SubState" is "dead"

on v240  on the other part, before the unit ready, i get 4 messages, one on
`org.freedesktop.systemd1.Service` -> `org.freedesktop.systemd1.Unit` ->
`org.freedesktop.systemd1.Service` -> `org.freedesktop.systemd1.Unit`,
where the Unit ones the substate first is "dead" and then is "running", on
deactivating, the messages are the same between 239 and 240.

so i used to tell that the unit had finished, by inspecting the messages on
the bus, and then looking for SubState to be any of ("exited", "failed",
"dead"), but i cant do that now.

at the end of the  email i copy the dumps on the 2 versions, but my
questions are:

1.- Is this change in behaviour, intended, or a side effect of something
else?
2.- was what i was doing the best way to decide if a transient unit has
finished? i'm super temped to instead check when the
`org.freedesktop.systemd1.Service.MainPID == 0` i think its the best idea,
but maybe you guys have one that is better.

thanks guys!!

now i paste the messages:

on v239

on start
[b'org.freedesktop.systemd1.Service',
 {b'ControlPID': 0,
  b'ExecMainCode': 0,
  b'ExecMainExitTimestamp': 0,
  b'ExecMainExitTimestampMonotonic': 0,
  b'ExecMainPID': 18328,
  b'ExecMainStartTimestamp': 1550516822984246,
  b'ExecMainStartTimestampMonotonic': 41004687391,
  b'ExecMainStatus': 0,
  b'GID': 4294967295,
  b'MainPID': 18328,
  b'NRestarts': 0,
  b'Result': b'success',
  b'StatusErrno': 0,
  b'StatusText': b'',
  b'UID': 4294967295,
  b'USBFunctionDescriptors': b'',
  b'USBFunctionStrings': b''},
 [b'ExecStartPre',
  b'ExecStart',
  b'ExecStartPost',
  b'ExecReload',
  b'ExecStop',
  b'ExecStopPost']]
[b'org.freedesktop.systemd1.Unit',
 {b'ActiveEnterTimestamp': 1550516822984291,
  b'ActiveEnterTimestampMonotonic': 41004687437,
  b'ActiveExitTimestamp': 0,
  b'ActiveExitTimestampMonotonic': 0,
  b'ActiveState': b'active',
  b'AssertResult': True,
  b'AssertTimestamp': 1550516822983511,
  b'AssertTimestampMonotonic': 41004686656,
  b'ConditionResult': True,
  b'ConditionTimestamp': 1550516822983509,
  b'ConditionTimestampMonotonic': 41004686655,
  b'InactiveEnterTimestamp': 0,
  b'InactiveEnterTimestampMonotonic': 0,
  b'InactiveExitTimestamp': 1550516822984291,
  b'InactiveExitTimestampMonotonic': 41004687437,
  b'Job': (0, b'/'),
  b'StateChangeTimestamp': 1550516822984291,
  b'StateChangeTimestampMonotonic': 41004687437,
  b'SubState': b'running'},
 []]

on end

[b'org.freedesktop.systemd1.Service',
 {b'ControlPID': 0,
  b'ExecMainCode': 1,
  b'ExecMainExitTimestamp': 1550516877103509,
  b'ExecMainExitTimestampMonotonic': 41058806656,
  b'ExecMainPID': 18328,
  b'ExecMainStartTimestamp': 1550516822984246,
  b'ExecMainStartTimestampMonotonic': 41004687391,
  b'ExecMainStatus': 0,
  b'GID': 4294967295,
  b'MainPID': 0,
  b'NRestarts': 0,
  b'Result': b'success',
  b'StatusErrno': 0,
  b'StatusText': b'',
  b'UID': 4294967295,
  b'USBFunctionDescriptors': b'',
  b'USBFunctionStrings': b''},
 [b'ExecStartPre',
  b'ExecStart',
  b'ExecStartPost',
  b'ExecReload',
  b'ExecStop',
  b'ExecStopPost']]
[b'org.freedesktop.systemd1.Unit',
 {b'ActiveEnterTimestamp': 1550516822984291,
  b'ActiveEnterTimestampMonotonic': 41004687437,
  b'ActiveExitTimestamp': 1550516877103599,
  

Re: [systemd-devel] Environment-variable security?

[aleivag]

If you use  EnvironmentFile the only thing a user could do is systemctl
show, and that will tell them that what environment file was used , but not
it's content...

As long as you unset the env, you should be fine (but I'm not a expert on
this)

El lun., 12 de noviembre de 2018 7:18 p. m., David Parsley <
pars...@linuxjedi.org> escribió:

> I already scrub the environment when executing external scripts, and I've
> found that even after os.Unsetenv(...) the full environment is available to
> all processes owned by the robot in /proc//environ. I'm fleshing out a
> solution where the process consumes the environment then scrubs it from
> proc w/ execve before starting the main loop that can run external scripts.
>
> I don't know what mechanism made the environment available via API, so I
> wasn't sure if using an EnvironmentFile protected against that same
> mechanism. If effective, that would be a nice solution that parallels
> operation of the dockerized version.
>
> So, anybody know what API calls an unprivileged user can make to get that
> information from the unit file? It'd be nice to test before and after to
> make sure the measure is effective.
>
> Regards,
> -David
>
> On Mon, Nov 12, 2018 at 4:23 PM aleivag  wrote:
>
>> hi Reindl: I was protecting against "systemctl cat/show" disclosure of
>> information, as stated in the question; but i agree with you, and there are
>> always risk in passing credential in env variables, but you can always try
>> to mitigate them (e.g. the main process can read the variables and then
>> remove them from the env).
>>
>> El 12 nov. 2018 5:54 p. m., "Reindl Harald" 
>> escribió:
>>
>>
>>
>> Am 12.11.18 um 21:41 schrieb aleivag:
>>
>> > You can define those secrets on /etc/robotsecret.txt, and then on your
>> > unit you do `EnvironmentFile=/etc/robotsecret.txt`
>> >
>> > then you protect /etc/robotsecret.txt as you would normally do
>>
>> and how does that protect anything?
>>
>> on a webserver running php it's just a one-liner to get $_ENV which is
>> why sensitive data don't belong there and should never exposed that way
>> like passwords in teh commandline are plain wrong
>>
>>
>> > On Mon, Nov 12, 2018 at 4:49 PM David Parsley > > <mailto:pars...@linuxjedi.org>> wrote:
>> >
>> > It's a fairly common practice to configure services and provide
>> > secrets with environment variables. For instance, both Hubot (made
>> > by Github) and Gopherbot (made by me) can get their Slack token from
>> > an environment variable. In my case,
>> > github.com/lnxjedi/ansible-role-gopherbot
>> > <http://github.com/lnxjedi/ansible-role-gopherbot> stores the Slack
>>
>> > bot token with "Environtment=GOPHER_SLACK_TOKEN=xxx" in the systemd
>> > unit file. I had hoped to keep this info to the robot user by
>> > marking the unit file world-inaccessible. I was dismayed to see the
>> > log warning about values being accessible via the API, though super
>> > glad that my unprivileged user couldn't fetch it with a
>> > simple |systemctl cat gopherbot|. I know very little about DBUS or
>>
>> > any APIs for systemd, so wanted to ask - is there some means by
>> > which a non-privileged user can access the values provided with
>> > "Environment=..." lines? Can I disable this by disabling dbus-daemon
>> > on server systems?
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Playground ...

[aleivag]

This is great! thanks

Alvaro Leiva


On Tue, Jul 3, 2018 at 9:03 AM Bruno Vernay  wrote:

> More users, more feedbacks, that is the goal !
> Bruno
>
>
> On Tue, Jul 3, 2018 at 9:28 AM Jérémy Rosen  wrote:
>
>> Very nice...
>>
>> I am writing a systemd course and I am missing exercises and samples...
>> I'll definitely add that to my "interesting website" slide and use it at
>> various places...
>>
>>
>> On 01/07/2018 16:19, Bruno Vernay wrote:
>>
>> Hi, I created a few examples on various systemd features and more
>> to easily test and "play"https://gitlab.com/BrunoVernay/systemd-playground/
>>
>> My hope is to get feedback, since there are surely many things to improve.
>> (while keeping it simple)
>>
>> I put links to similar projects, if I missed some, let me know.
>>
>> Regards
>> Bruno
>>
>>
>>
>>
>> ___
>> 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 <01%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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to set `InitRDTimestampMonotonic` from console?

[aleivag]

Hi Paul:

properties on the manager object, you can get them with:

[~] sudo systemctl show -p InitRDTimestampMonotonic
InitRDTimestampMonotonic=0

there is also the long way:

[~] busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1
org.freedesktop.systemd1.Manager InitRDTimestampMonotonic
t 0

if you want to get this value from a shell script, you can use either, but
i recommend `systemctl show`. if you can aford not to run this on shell,
and do it in c, just bind against libsystemd and call methods in
systemd/sd-bus.h , and if you can run stuff on high level languages like
python... try pystemd (but i'm bias against the last one because i'm the
author and its not a official systemd tool)

best of lucks


Alvaro Leiva


On Tue, Jul 3, 2018 at 10:24 PM Paul Menzel <
pmenzel+systemd-de...@molgen.mpg.de> wrote:

> Dear systemd folks,
>
>
> Debian uses a shell script as `/init` in initrd, and I like to extend
> that, to set the time stamps for the initrd execution.
>
> `systemd-analyze` built from `src/analyze/analyze.c` uses D-Bus to get
> the time stamp to display that.
>
> ```
> bus_get_uint64_property(bus,
>  "/org/freedesktop/systemd1",
>  "org.freedesktop.systemd1.Manager",
>  "InitRDTimestampMonotonic",
>  _time) < 0
> ```
>
> In `src/core/manager.c` the value is set like below.
>
> ```
>  if
> (dual_timestamp_is_set(>timestamps[MANAGER_TIMESTAMP_INITRD])) {
>
>  /* The initrd case on bare-metal*/
>  kernel_usec =
> m->timestamps[MANAGER_TIMESTAMP_INITRD].monotonic -
> m->timestamps[MANAGER_TIMESTAMP_KERNEL].monotonic;
>  initrd_usec =
> m->timestamps[MANAGER_TIMESTAMP_USERSPACE].monotonic -
> m->timestamps[MANAGER_TIMESTAMP_INITRD].monotonic;
>
>  log_struct(LOG_INFO,
> "MESSAGE_ID="
> SD_MESSAGE_STARTUP_FINISHED_STR,
> "KERNEL_USEC="USEC_FMT, kernel_usec,
> "INITRD_USEC="USEC_FMT, initrd_usec,
> "USERSPACE_USEC="USEC_FMT,
> userspace_usec,
> LOG_MESSAGE("Startup finished in
> %s%s (kernel) + %s (initrd) + %s (userspace) = %s.",
> buf,
> format_timespan(kernel,
> sizeof(kernel), kernel_usec, USEC_PER_MSEC),
> format_timespan(initrd,
> sizeof(initrd), initrd_usec, USEC_PER_MSEC),
>
> format_timespan(userspace, sizeof(userspace), userspace_usec,
> USEC_PER_MSEC),
> format_timespan(sum,
> sizeof(sum), total_usec, USEC_PER_MSEC)));
> ```
>
>
>
>
> Is it possible to set that value from a shell script? If yes, could you
> please tell me how?
>
>
> Kind regards,
>
> Paul
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: starting multiple shells

[aleivag]

hi:

so for finding the pid the solution its (big surprise :D ) using systemd,
instead of just executing you systemd-nspawn in bash you start it as a
systemd-unit (you can even do this as ephemeral unit with `sytemd-run
--unit myspawn.service systemd-nspawn bla...`)

then to get the ip of the nspawn process no need to ps aux you just do
`systemctl show -pMainPID myspawn.service`, that will give you the mainpid,
and your child you can get it with `pgrep -P`.

as personal oprinion... i much like `tail -f /dev/null` better than `sleep
` as a wait to "wait for ever"

Alvaro Leiva


On Sat, Jun 23, 2018 at 2:02 PM Nikolaus Rath  wrote:

> On Jun 23 2018, Nikolaus Rath  wrote:
> > On Jun 23 2018, aleivag  wrote:
> >> short answer, yes, `machinectl login` is only suppported for
> systemd-init ,
> >> and `machinectl shell` `systemd-run` will try to talk to the container
> via
> >> dbus, so i dont think you are force to have systemd runing inside the
> >> container (i may be wrong) but you do need to have dbus (and its easy to
> >> just have systemd).  if you dont need it, you can always use nsenter to
> >> access a namespace on your machine
> >
> > Still not working:
> [..]
> > $ sudo machinectl shell root@iofabric
> > [sudo] password for nikratio:
> > Failed to get shell PTY: Cannot set property
> > StandardInputFileDescriptor, or unknown property.
>
> So this seems to be caused by systemd in the container being too old,
> and is therefore not available here.
>
> The 'nsenter' approach seems to work so far, but I don't see a generally
> applicable way to figure out the right PID. Is there a trick for that?
>
> (I ran a "sleep " in the container and grepped "ps
> ax" for the number in the host).
>
> Best,
> -Nikolaus
>
> --
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>  »Time flies like an arrow, fruit flies like a Banana.«
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: starting multiple shells

[aleivag]

short answer, yes, `machinectl login` is only suppported for systemd-init ,
and `machinectl shell` `systemd-run` will try to talk to the container via
dbus, so i dont think you are force to have systemd runing inside the
container (i may be wrong) but you do need to have dbus (and its easy to
just have systemd).  if you dont need it, you can always use nsenter to
access a namespace on your machine

```
nsenter -t  --all /bin/bash
```

where  is the process that is runing on your container

Alvaro Leiva


Alvaro Leiva


On Sat, Jun 23, 2018 at 7:38 AM Nikolaus Rath  wrote:

> Hi,
>
> On Sat, 23 Jun 2018, at 15:31, Vito Caputo wrote:
> > On Sat, Jun 23, 2018 at 03:09:04PM +0100, Nikolaus Rath wrote:
> > > How would I go about starting an additional shell in an existing
> > > container? I am starting the container with:
> > >
> > > $ systemd-nspawn -M foo --as-pid2 --register=no
> > >
> > > "foo" is a raw image retrieved with machinectl. If I simply execute the
> > > above command again, I am getting a "Disk image
> > > /var/lib/machines/foo.raw is currently busy." error.
> > >
> > > I've looked into the systemd-nspawn manpage, but couldn't find anything
> > > appropriate.
> > >
> > > What am I missing?
> > >
> > Take a look at the machinectl man page, the "shell" and "login"
> > subcommands in particular.
>
> `man systemd-nspawn` says that when not running an init system in the
> container,
> I should specify `--register=no`. But without that, `machinectl` doesn't do
> anything.  Does this mean I need to run an init system to support multiple
> shells?
>
> Best,
> -Nikolaus
>
> --
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>  »Time flies like an arrow, fruit flies like a Banana.«
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn: starting multiple shells

[aleivag]

Hi:

to get a shell on your running container , you need to get it's name
(execute `machinectl` to get a list of containers) and then

if you just want a shell you can run `systemd-run --machine= --pty
/bin/bash` or `machinectl shell  /bin/bash`

and if you want a real login promp

machinectl login 

is your best bet

hope it helps
Alvaro Leiva Geisse


On Sat, Jun 23, 2018 at 7:13 AM Nikolaus Rath  wrote:

> Hello,
>
> How would I go about starting an additional shell in an existing
> container? I am starting the container with:
>
> $ systemd-nspawn -M foo --as-pid2 --register=no
>
> "foo" is a raw image retrieved with machinectl. If I simply execute the
> above command again, I am getting a "Disk image
> /var/lib/machines/foo.raw is currently busy." error.
>
> I've looked into the systemd-nspawn manpage, but couldn't find anything
> appropriate.
>
> What am I missing?
>
>
> Thanks!
> -Nikolaus
>
> --
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>  »Time flies like an arrow, fruit flies like a Banana.«
> ___
> 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] getgroups returning a diferent result

[aleivag]

Thanks Michael, Jérémy

i found the code
https://github.com/systemd/systemd/blob/b0450864f1723ad12176d7956377d89ff4a84d8c/src/core/execute.c#L963
and you are right systemd explicitly dont load groups for root, and i guess
that is why getgroups return empty instead of failing. the good news (at
least for me :P ) is that i can execute initgroups myself on my program and
get all the groups for my user, and that also explain why i do have my
supplementary groups in my logged session (maybe logind or execute
initgroups for me).

thanks guys for your answers.

Alvaro Leiva Geisse


On Fri, Jun 15, 2018 at 1:57 AM Michael Chapman 
wrote:

> On Fri, 15 Jun 2018, Jérémy Rosen wrote:
> > Partial answer, I don't know all the details...
> >
> > We are all taught in school that each unix user belongs to to a certain
> number
> > of groups, and that is defined in /etc/passwd.
> >
> > That's kinda true, but it's an oversimplification.
> >
> > Each PROCESS has a user and a set of groups. Those groups are set when
> login
> > (or whoever does the login process) switch
> > from running as root to running as your user. At that point, it will
> > explicitely read /etc/passwd, set the correct groups then
> > switch to the final UID (which can't change groups anymore)
> >
> > This is the normal process when you login, but its a convention, not
> something
> > that is enforced by the kernel.
> >
> > IIUC systemd does not do that for services. Services only have a UID, a
> main
> > GID but no supplementary GIDs.
> >
> > Supplementary GID must be set explicitely with SupplementaryGroups= in
> > [Service] They won't be read from /etc/passwd
> >
> > That's my understanding, at least, someone else might know better...
>
> systemd does call initgroups(3) -- which populates a process's
> supplementary group list -- but only when the GID is _not_ 0. There's a
> comment in the code that it is to avoid an NSS lookup in this case, though
> I must admit I don't know the full rationale for it.
>
> It's probably got something to do with the fact that the group database
> in NSS won't necessarily be available early during boot, especially if
> it's backed onto some network
> service.___
> 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] getgroups returning a diferent result

[aleivag]

hi systemd'ers , i'm sure this is known, but for the life of me i cant
seems to know why.

tldr; aparently i loose all auxiliary groups of root when i execute a unit.

i'll explain (i try this on v238).

when i'm logged in as root, and i execute `id` i get all the groups that
root belong to. but when i do the same in a systemd unit (e.g. under a
transien unit, a la systemd-run) i loose all groups. i suspect that this is
because the getgroups system call returns a different value, but for the
life of me, i don't know why or how. i'll show

on my normal bash

```
[homex ~]# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
```

i get all the groups, but if i run it with systemd-run

```
[homex ~]# systemd-run --pty id
Running as unit: run-u207.service
Press ^] three times within 1s to disconnect TTY.
uid=0(root) gid=0(root) groups=0(root)
```

the only group i see is root, now for the semi weird part, if i execute `id
root`, i do get all the groups

```
[homex ~]# systemd-run --pty id root
Running as unit: run-u220.service
Press ^] three times within 1s to disconnect TTY.
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
```

this is because getgroups return a diferent value if i'm in the unit or
logged in

```
[homex ~]# strace id 2>&1 | grep getgroups
getgroups(0, NULL)  = 8
getgroups(8, [0, 1, 2, 3, 4, 6, 10, 19]) = 8

[homex ~]# systemd-run --pty strace id 2>&1 | grep getgroups
getgroups(0, NULL)  = 0
getgroups(0, [])= 0
```

and the reson why i gett all the groups when i execute `id root`, is
because that does not ask for groups, but call libnss instead

```
[homex ~]# systemd-run --pty strace id root 2>&1 | grep getgroups
[homex ~]# systemd-run --pty strace id root 2>&1 | grep libnss
openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/libnss_mymachines.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 3
```

i guess i just wanna understand why this is, why this system call return
different values if i'm in bash or if i'm in a unit.

thanks guys!

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

Re: [systemd-devel] systemd DB2 StartUp/Shutdown service on Red Hat Enterprise Linux Server release 7.4 (Maipo)

[aleivag]

`Before` means that if your service and everything in `Before` (e.g.
shutdown.target) is started at the same time, your service will be started
Before the other, but when all are been stopped, your service will get
Stoped After the other (you can see why you don't want your service stopped
after shutdown.taregt), After is the opposite of that.

a couple of tips on this

i would remove the Before and the Conflicts, and enable your service. since
its in multi-user.taget, it will get stoped alongside all other services.

I would put in "After" all the things you need to have runing while
shutting down your service... its a database, you probably dont need weird
stuff.. but if you connect to any other service in the same box you
probably want to put those there. i normally put sshd.service and
dbus.service, because i like to be able ssh and look at the things that are
been shutting down, and dbus because you want a semi-funtional. keep in
mind that this 2 are probably irrelevant, since you have
After=network.target.

pro-tip on "After" you can also put "mounts" to make sure you have a fs to
work with.

sometimes you want to increase the TimeoutStopSec and maybe if your
ExecStop exit inmediatly, a "sleep X"  at the end

everithing else looks good.

Hope it helps




Alvaro Leiva

On Thu, May 24, 2018 at 12:52 PM, Leonard Rofman  wrote:

> Hello everybody,
>
>
>
> I am DBA and trying to setup systemd service for DB2 V11 fix pack 2a
> (multiple instances).
>
> I’ve spent quite a bit of time on this setup without success so far.
>
> I was able to get “ExecStart” part to work, but system reboot is giving me
> troubles.
>
> DB2 crashes since “ExecStop” for some reason is not executed.
>
> Please find the contents of db2.service file below.
>
>
>
> The help on this is greatly appreciated.
>
>
>
> Regards
>
>
>
>
>
> [Unit]
>
> Description=DB2 StartUp-Shutdown
>
> After=network.target
>
> Before=shutdown.target reboot.target halt.target
>
> Conflicts=shutdown.target
>
>
>
> [Service]
>
> Type=forking
>
> RemainAfterExit=yes
>
> User=achdut2
>
> ExecStart=/bin/sh -c '/var/db2/home/achdut2/sqllib/adm/db2start'
>
> ExecStop=/bin/sh -c '/var/db2/home/achdut2/sqllib/adm/db2stop force'
>
> Restart=always
>
> Environment="DB2INSTANCE=achdut2"
>
>
>
> [Install]
>
> WantedBy=multi-user.target
>
> --
>
> Please note the MUFG logo and name is a service mark of Mitsubishi UFJ
> Financial Group, Inc. (“MUFG”) and may be used by it or other Group
> companies for marketing purposes, including MUFG Americas Holdings
> Corporation affiliates and subsidiaries. Lending, deposit, securities,
> investment banking, and other banking services are provided by banking
> and/or broker-dealer affiliates of MUFG, including, MUFG Bank, Ltd. (“MUFG
> Bank”), MUFG Union Bank, N.A. (“Union Bank”), MUFG Securities Americas Inc.
> (“MUSA”), and MUFG Securities (Canada), Ltd. (“MUS(CAN)”). MUFG Bank is not
> an FDIC-insured bank. MUB is an FDIC-insured bank. MUSA is a member of
> FINRA and SIPC. MUS(CAN) is a member of IIROC and CIPF.
>
> This message is intended for the named addressee(s) only. It may contain
> confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any mis-transmission. If
> you receive this message in error, please delete it and all copies from
> your system, destroy any hard copies and notify the sender. You must not,
> directly or indirectly, use, disclose, distribute, print or copy any part
> of this message if you are not the intended recipient. MUFG, its affiliates
> and subsidiaries reserve the right to monitor all electronic communications
> through their respective networks. Any views expressed in this message are
> those of the individual sender and do not constitute investment advice or
> recommendation, except where the message expressly states otherwise and the
> sender is authorized to furnish the same. MUFG (and its subsidiaries) shall
> (will) not be liable for the message if modified.
>
>
> ___
> 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] safe and fast shutdown/reboot

[aleivag]

>
>
> Won't work. Status changes only when job for a unit completes and jobs
> are executed in order of dependencies. Actually, jobs are *queued* in
> order of dependencies so nothing would indicate that you are going to
> shutdown until it is too late (i.e. all normal services are stopped).
>
>
yes, but those units have started, so during a `systemctl reboot` you can
execute

[~] systemctl list-jobs shutdown.target reboot.target
 JOB UNITTYPE  STATE
1972 reboot.target   start waiting
1974 shutdown.target start waiting

2 jobs listed.

and get if shutdown has started

the other thing that may help you know if you are in shutdown mode is
execute `systemctl is-system-running`  and then check if returns `stopping`,
during a shutdown is suppose to return something like that. and i think it
does this by checking is shutdown.target has started (
https://github.com/systemd/systemd/blob/7a30dfeb18d09940a844389e06b25ca2bca5e093/src/core/manager.c#L3833-L3836
)


Logically runlevel is not changed until *after* new runlevel has been
> reached. Practically systemd does not update runlevel during shutdown at
> all.


yeap, you are right here, i was wrong :D
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] safe and fast shutdown/reboot

[aleivag]

One other thing that may work, is that you could implement a ExecStop
action in your service unit, that checks if the system is been shutting
down (by checking status of {shutdown,reboot,halt}.target [or maybe also
the runlevel may work?]), and kill the unit if there is one of those
operations.


Alvaro Leiva

On Thu, Mar 15, 2018 at 9:14 PM, Zeal Jagannatha 
wrote:

> Hmm. This is probably not ideal, but you could hook a 'Type=oneshot'
> service into shutdown.target which runs 'systemctl kill {your
> service}.service'.
>
> I'm not sure if there's a simpler way to do this using targets.
>
> On Thu, Mar 15, 2018 at 8:57 PM prashantkumar dhotre <
> prashantkumardho...@gmail.com> wrote:
>
>> Thanks but I want to sigkill my services only during system shutdown and
>> not on normal service stop 'systemctl myservice stop'.
>> so I can not use ' KillSignal' setting. Is there any other way ?
>>
>> On Fri, Mar 16, 2018 at 9:23 AM, Zeal Jagannatha <
>> zealjaganna...@gmail.com> wrote:
>>
>>> I think it would be better for the services you define to specifically
>>> define their own `KillSignal` so you can control how they shutdown.
>>> https://www.freedesktop.org/software/systemd/man/systemd.
>>> kill.html#KillSignal=
>>>
>>> It's may not be safe for all the services on the machine to be shut down
>>> with SIGKILL, so you should avoid using '--force' unless you know that
>>> everything running on the system is safe to shutdown with SIGKILL.
>>>
>>> On Thu, Mar 15, 2018 at 8:43 PM prashantkumar dhotre <
>>> prashantkumardho...@gmail.com> wrote:
>>>
 Hi
 I see that default reboot/systemctl reboot command issues SIGTERM to my
 apps and hence it is doing graceful stop of apps and this may take some
 time and hence shutdown time may be little longer.

 I am looking for safe and fastest shutdown/reboot method.


 a) It is OK if my apps are stopped ungracefully during shutdown .(app
 should not start automatically again after they are killed/stopped during
 shutdown)

 b)  file system and such system level stuff needs to be cleanly shut
 down

 1) From my research, I see that 'systemctl reboot --force' is the one I
 can use.
 I understand that this command sends SIGKILL to my apps.
 So this satisfies both (a) and (b) and hence this command should be
 used to reboot faster.
 Could you please confirm ?
 If this is not right method, please comment on which method to use.

 2) Also is there a way to limit SIGKILL to only my apps when I do ' 
 'systemctl
 reboot --force'
 so that rest of the system level services still get stopped gracefully

 3) If  'systemctl reboot --force' is correct command to use in my
 case, then during shutdown , will my apps get restarted
 due to 'Restart'/'StartLimitBurst'/'StartLimitInterval' settings in
 service file ? I dont want my apps to get restarted if they are
 stopped/killed during system shutdown


 Thanks



 ___
 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[aleivag]

Hi Antoine:

2 disclosure before reading this:

1) i'm not part of systemd-devel team, and
2) this is also a shameless plug because i'm talking about a lib i created.

with that out of the way, here is my advice/solution.

do everything in python and use `pystemd` (pip install pystemd, just have
libsystemd installed and you should be fine), and also ditch the
cachedirectory in favor of PrivateTmp, that is always new when you start
your unit, and always goes away with your unit.

pystemd is  apython wrapper around a few libsystemd-dev, and it has a nice
module name pystemd.run, here is a example

import sys
import pystemd.run

pscript = """
import os
import shutil
print(shutil.copytree('/var/cache/dnf', '/tmp/dnf'))
print(os.listdir('/tmp/dnf'))
"""

pystemd.run(
['/usr/bin/python3', '-c', pscript],
stdout=sys.stdout, stderr=sys.stderr, wait=True,
env={'PYTHONUSERBASE': '/dev/null'},
extra={'DynamicUser': True, 'PrivateTmp': True},
)

this would output: something like
/tmp/dnf
['last_makecache', '.gpgkeyschecked.yum', 'rawhide-2d95c80a1fa0a67d',
'google-chrome-filenames.solvx', 'tempfiles.json',
'rawhide-filenames.solvx', 'google-chrome.solv', 'expired_repos.json',
'rawhide.solv', 'packages.db', 'google-chrome-eb0d6f10ccbdafba']


so my recommendation, create a custom script with your build process and
call it using pystemd.run. Now, you could also use systemd-run to run your
script, but then it would not have been a shameless plug, right?

hope it helps


Alvaro Leiva

On Wed, Feb 28, 2018 at 7:03 AM, Antoine Pietri 
wrote:

> On Tue, Feb 27, 2018 at 2:37 PM, Antoine Pietri
>  wrote:
> > - 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?
>
> We came up with a third option, which looks a bit weird at first but
> should work:
>
> 1) systemd-run -P \
>   -p DynamicUser=yes \
>   -p CacheDirectory=mywrapper \
>   sh -c read
>
> 2) do the file operations in the Python code
> 3) send a "\n" or just kill() the systemd-run process when the setup is
> done.
>
> I am still not satisfied with any of the three options, so I would
> love to know what you think would be best. :-)
>
> --
> Antoine Pietri
>
> On Tue, Feb 27, 2018 at 2:37 PM, Antoine Pietri
>  wrote:
> > 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
>
>
>
> --
> Antoine Pietri
> 

Re: [systemd-devel] custom var in sd_notify

[aleivag]

It make sense, Thank you for the clarification!

El 25 feb. 2018 10:09 p. m., "Mantas Mikulėnas" <graw...@gmail.com>
escribió:

On Mon, Feb 26, 2018 at 12:32 AM, aleivag <alei...@gmail.com> wrote:

> Hi all, hope you are doing:
>
> i was toying aroud sd_notify and sd-daemon.h and found this section in
> https://github.com/systemd/systemd/blob/master/src/system
> d/sd-daemon.h#L234-L235 it said:
>
> Daemons can choose to send additional variables. However, it is recommended
> to prefix variable names not listed above with X_.
> So naturally i tried
>
> sd_notify(0, "X_ANSWER=42")
>
> and apparently systemd has no problem with that, but my questions are 2
> now:
>
> 1) What does systemd do with this information?
>

Nothing. The documentation just says in other words that "the init system
must not reject packets with unknown variables", but doesn't say that
systemd or any other init will store all of them anywhere.

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

[systemd-devel] custom var in sd_notify

[aleivag]

Hi all, hope you are doing:

i was toying aroud sd_notify and sd-daemon.h and found this section in
https://github.com/systemd/systemd/blob/master/src/
systemd/sd-daemon.h#L234-L235 it said:

Daemons can choose to send additional variables. However, it is recommended
to prefix variable names not listed above with X_.
So naturally i tried

sd_notify(0, "X_ANSWER=42")

and apparently systemd has no problem with that, but my questions are 2 now:

1) What does systemd do with this information?
2) How can i query this x_answer variable i just gave?

thanks!

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

[systemd-devel] pystemd a cython wrapper around libsystemd

[aleivag]

Hi all,

shameless plug, hope its ok, i've seen people do this,, but that does not
means is ok...

so created a nice python wrapper arround sd-bus.h (and other parts of
libsystemd) the idea is to make accesible to python developer what is
already accesible to c developers.

so you can do stuff like

```
with pystemd.systemd1.Unit(b'postfix') as postfix:
postfix.Unit.Start(b'Replace')
print(f"your main pid is {postfix.Service.MainPID}")
```

but since it bind to sd-bus, it can do more stuff that just start stop
units. the github repo is https://github.com/facebookincubator/pystemd


all feedback is much appreciated

Have as nice day
Alvaro Leiva
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Back trace systemd service unit by pid

[aleivag]

the simplest way is to use busctl as

aleivag@algx:~$ busctl call org.freedesktop.systemd1
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager GetUnitByPID u
28729
o "/org/freedesktop/systemd1/unit/nginx_2eservice"

from that you are a  awk away of what you want. if you want to get clever
you can always do:

aleivag@algx:~$ busctl call org.freedesktop.systemd1
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager GetUnitByPID u
28729 | awk '{print $2}' | xargs -i busctl get-property
org.freedesktop.systemd1 {} org.freedesktop.systemd1.Unit Id

s "nginx.service"

But depending on what you want, if you are not bound to use a shell, you
can try using sd-bus.h in you code.



Alvaro Leiva

On Wed, Dec 20, 2017 at 9:48 PM, Kevin Hsu <hsu...@gmail.com> wrote:

> Hi folks,
>
> I am looking for a good way to backtrace systemd service by a process id.
> The "systemctl status " command is available to do the magic. It will
> show a full status of the service that creates the
> pid. But this command gives too many details. The only thing I need is the
> service unit name. Is there any simple way instead of parsing results from
> "systemctl status" ?
>
> For example like
>
> > systemctl service-get 5566
> > nginx.service
>
>
> Thanks,
> Kevin Hsu
>
> ___
> 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] [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

Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets

[aleivag]

>
>
> Don't connect directly to it. Use the official bus instead. Forget
> that you know about the private connection at all...
>
> Lennart
>
>
got it, "this aren't the sockets you're looking for" :), will use then
propper `sd_bus_open_*`

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

[systemd-devel] proper use of /run/{user/, }/systemd/private sockets

[aleivag]

Hi all:

hope you guys are doing great!. So i have a few questions, hope this is the
best place for them.

I've been doing a lot of work with `sd-bus.h` (basically i've been trying
to bind it to other languages to then interact with systemd natively).

I've been reading the man pages/blog post/general docs, but mostly the src
code. and i stumble across
https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L598-L605
and saw that you can connect to systemd using the sockets, for root would
be `/run/systemd/private`, and for users something like
`/run/user//systemd/private` and this trigger lots of questions, that
i have not been able to answer, so here they are:

Question 1)

what would be the advantage of connecting through dbus instead of directly
through the socket?

the way i connect to systemd is with `sd_bus_open_system` but i can also do

```
sd_bus_new();
sd_bus_set_address(bus, "unix:path=/run/systemd/private");
sd_bus_start(bus);
```

why (or when) would one be better than the other?

question 2);

i also look that you can do the same with the user connections (and this is
mostly true when the --user flag is given, at least on systemd-run), and
you can connect to something like `/run/user//systemd/private`, where
`/run/user/` is $XDG_RUNTIME_DIR, and i guess this is really the best
form to connect to systemd as a user, but is there any difference between
using that socket or doing `sd_bus_open_user`. ?

question 3)

systemd source code is pretty clear, really easy to learn from, also
sd-bus.h is incredible helpful and easy to use.

But the docs is good, don't get me wrong, but it could definitely use more
love. for instance the usage of the sockets
`/run/{user/uid,}/systemd/private`, is not documented anywhere that i could
find. is this intentional?, is this because this is a implementation detail
that may change in the future?. if so, what would be the correct way to
connect to systemd's socket?
i was particularly surprise that the sockets' path are hardcoded in the
code.

if this parts have not just gotten into the docs, i would be more than
happy to submit the PR for the docs.

Thank you guys!
Alvaro Leiva
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel