Can't open netlink socket: No such file or directory about tlsdate HOT 18 CLOSED

Oops, the main process isn't exiting because of strace being open, duh. Not a timing thing.

from tlsdate.

Do you have a /etc/tlsdate/tlsdated.conf file?

from tlsdate.

@redpig - any thoughts on the netlink stuff?

from tlsdate.

hrm,
"""
1036 socket(PF_NETLINK, SOCK_RAW, 0) = 6
1036 bind(6, {sa_family=AF_NETLINK, pid=0, groups=00000440}, 12) = 0
1036 fcntl(6, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
1036 write(2, "Can't open netlink socket: No su"..., 52) = 52
1036 write(2, "\n", 1) = 1
"""

(On a side note, I hadn't seen the event_composite_* changes -- I just got finished refactoring tlsdated to use libevent extensively. Arg.)

It looks like routeup_setup() return 0 on success
https://github.com/ioerror/tlsdate/blob/master/src/routeup.c#L62

but event_routeup() tests for 0 on failure:
https://github.com/ioerror/tlsdate/blob/master/src/event.c#L120
if (!routeup_setup(rtup))
/* fail */

which means it will always complain on success.

from tlsdate.

Ok - I'm going to tag a new release and we'll skip this issue. The next release will deal with any refactor of tlsdated by @redpig and this will hopefully be addressed at that time too.

from tlsdate.

@ioerror Cool. We can start a trend of monthly releases or something :)

from tlsdate.

I've tagged 0.0.7 - can you confirm that this is an issue and add a bit more information?

from tlsdate.

I have this issue as well on 0.0.8, I can't imagine how that code works correctly for anyone...

from tlsdate.

If you'd like to provide some information, I think we can try to debug it. I'm not using tlsdated for anything and I'm still waiting on a refactor patch from @redpig...

from tlsdate.

AFAIU inverting the return code in if (!routeup_setup(rtup)) should be enough, but I'm not really familiar with the code.

from tlsdate.

That seems plausible.

I'm happy to dig into it later - sadly when last I checked, Google uses this - so it may be that this change would break their setup. I'm not sure, I'm still waiting on hearing from @elly and @redpig... I wonder where they went?

from tlsdate.

Sorry for the disappearing act! The refactoring I did was not small, so I'll be untangling any and all changes regardless. If there's a short-term fix for active upstream users (like inverting the test), don't block on our behalf. In the meantime, I'll get a clone on github and start piecing together a reasonable pull request. Thanks and sorry again!

from tlsdate.

Does inverting the test seem fine to you? That is - would it break
anything for your users or users like you? I don't use it, so I'm
looking for guidence on how I might even test it or if anyone cares
other than the few people in this thread...

from tlsdate.

That seems correct. It looks to me like the current code is buggy and the test should be inverted. route_setup returns 0 on success which means the test looks like:

if (routeup_setup succeeds) {
fail();
}

which is emphatically not how it should work. I don't believe anyone could be successfully using this code today!

from tlsdate.

OK. I'll give tlsdated a pass soon and I'll aim for it to work on
Debian. If you (@redpig) have a patch for me - including a full
outright replacement, I'll gladly trash the current tlsdated.

from tlsdate.

I'm trying to get it integrated in my fork (branch 'upstream_now'). Once it seems stable, I'll send a pull and I'll try not to break all-the-other-supported platforms!

from tlsdate.

@redpig - sounds good - I'd say - send a pull and I'll tag a release. It is already unstable, so it has to be an improvement, right? ;-)

from tlsdate.

We've released version 0.0.9 - which should fix this issue. If it doesn't: please open a new bug as a lot of the code is completely re-written!

from tlsdate.