systemd / pystemd

A thin Cython-based wrapper on top of libsystemd, focused on exposing the dbus API via sd-bus in an automated and easy to consume way.
GNU Lesser General Public License v2.1
409 stars 36 forks source link

Can't enable/disable services: DBusBaseError: [err -42]: Unknown arg type 255 for None #53

Closed Stefal closed 3 years ago

Stefal commented 4 years ago

Hi! I had a script which worked perfectly to enable/disable start/stop some services. Since an OS clean reinstallation (same armbian buster), it doesn't work anymore, and I really don't understand why. Here is my test:

In [10] from pystemd.systemd1 import Manager
In [11] manager = Manager(_autoload=True)
In [12]: manager.Manager.GetUnitFileState(b'str2str_tcp.service')
Out[12]: b'disabled'
In [13]: manager.Manager.EnableUnitFiles([b'str2str_tcp.service'], False, True)
---------------------------------------------------------------------------
DBusBaseError                             Traceback (most recent call last)
<ipython-input-13-e636eb23f4dc> in <module>
----> 1 manager.Manager.EnableUnitFiles([b'str2str_tcp.service'], False, True)

/usr/local/lib/python3.7/dist-packages/pystemd/base.py in _call(self, *args)
    189 def _wrap_call_with_name(func, name):
    190     def _call(self, *args):
--> 191         return func(self, name, *args)
    192
    193     return _call

/usr/local/lib/python3.7/dist-packages/pystemd/base.py in _call_method(self, method_name, *args)
    159         ]
    160
--> 161         return self._auto_call_dbus_method(method_name, in_args, *args)
    162
    163     def _auto_call_dbus_method(self, method_name, in_args, *args):

/usr/local/lib/python3.7/dist-packages/pystemd/base.py in _auto_call_dbus_method(self, method_name, in_args, *args)
    183                 self.interface_name,
    184                 x2char_star(method_name),
--> 185                 call_args,
    186             ).body
    187

pystemd/dbuslib.pyx in pystemd.dbuslib.DBus.call_method()

pystemd/dbuslib.pyx in pystemd.dbuslib.DBus._msg_append()

DBusBaseError: [err -42]: Unknown arg type 255 for None
This is DBusBaseError, a base error for DBus (i bet you did not see that coming) if you need a special error, enhance pystemd.sysdexc module!.

SBC: Orange pi Zero with armbian buster Python: v3.7.3 pystemd: v0.7.0 libsystemd-dev: 241-7~deb10u3

I have the same code working correctly inside various VM (Ubuntu 18, 20, Debian Buster, ...) and I know another user with the same problem on a Raspberry with Raspbian buster lite.

I've tested after installing pystemd from this repo with the same result.

I've tested with systemd-manager and it works.

Could somebody help me?

aleivag commented 4 years ago

oh for the life of me i can't reproduce... so lets do a few things

while i undust the raspberrypyi have in the basement, could you try repro on pystemd master. but my guess is that there is something on Raspbian that is failing...

Stefal commented 4 years ago

Thank you for you answer! Just tested with pystemd 0.8.1588314028 .......same result 😞

aleivag commented 4 years ago

could reproduce on my 4 year old raspberry py... :D

now that i can repro i can try to fix... stay tuned

aleivag commented 4 years ago

Ok so i know what this is... dont know why... i would assume combine python and arm and you get a bug making machine, but... in a nutshell

when we close a dbus container, the args_type in https://github.com/facebookincubator/pystemd/blob/master/pystemd/dbuslib.pyx#L324 gets the char 255 in arm and -1 in the rest of the architectures (by the rest i just means i864, because thats the only one i ever tried)... so then on line https://github.com/facebookincubator/pystemd/blob/master/pystemd/dbuslib.pyx#L393 when we actually need to close the container, 255 != -1.

probably its best, since we know that we need to close the container, to not make a char conversion... will probably land the fix on monday, but this is definetly a bug, and thanks for reporting it!!!

now i just wonder... why did this work before??!!!...

Stefal commented 4 years ago

Hi! I'm glad that you found so fast where the bug come from. I really don't know why it worked before a new armbian/raspbian image flash. I did so much tests that perhaps I got mixed up.

aleivag commented 4 years ago

ok, so i landed https://github.com/facebookincubator/pystemd/commit/72cd1b656bbe338ce6236a11179ae86f54ba8a5c

in my extensive weekend testing it worked...

for the reason on why it was broken, talking to @javierhonduco he pointed me to https://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default where https://stackoverflow.com/a/2054959/2452406 . i think char wen from been unsigned to been signed in arm/rpri... i'll do a bit more testing... but... "this" issue should be fixed :D

javierhonduco commented 4 years ago

As @aleivag said this is an issue with the char being signed in arm. The value -1 will become 255:

$ cat repro.c
#include <stdio.h>

int main () {
  char number = -1;
  printf ("number = %d\n", number);
  return 0;
}

On a x86 machine:

$ gcc -funsigned-char repro.c  
$ /a.out 
number = 255

With -fsigned-char it prints, as we expect, -1

Stefal commented 4 years ago

I confirm it works now, thank you!

Do you plan to publish a new release soon ?

aleivag commented 4 years ago

I confirm it works now, thank you!

nope, thank you for reporting! otherwise we would have never caught this

Do you plan to publish a new release soon ?

probably... this week or the next one, i have some typing annotation i wanna get in before the next release... because apparently that is something people care about...

Stefal commented 3 years ago

Hi @aleivag

I'm sorry to bother you with that, but is the new release still planned in a short futur time?

phobozad commented 3 years ago

Also interested in getting an new release published with this fix in it.

aleivag commented 3 years ago

ohhh!!! looks like i forgot to make a release... i'll do it on monday!

aleivag commented 3 years ago

i'll close once i made a release

aleivag commented 3 years ago

made the release, sory @phobozad and @Stefal for taking so long!!