sdwdate and sdwdate-gui development thread

Development
61
sdwdate-daemon probably does not require inotifywait. It can do normal writes. Those are infrequent enough. That's fine.
I was meaning inotify in sdwdate-gui.

Pushed new sdwdate-gui packages. GitHub - troubadoour/sdwdate-gui.

As usual, a couple of lintian warnings.
There must be a way around “new-package-should-close-itp-bug”. I won’t file a bug in Debian, or add “Close #123456”.
Tried to override “zero-byte-file-in-doc-directory” without luck.

62
There must be a way around "new-package-should-close-itp-bug". I won't file a bug in Debian, or add "Close #123456".
No need. It will go away with the next version number. Just bump the version number. When the second changelog entry exists, it won't complain about this anymore.

Handy shortcut.

make deb-chl-bumpup
Tried to override "zero-byte-file-in-doc-directory" without luck.
Will look into this now.
63

No need to override. It’s because changelog.upstream is still empty. deb-chl-bumpup will also fix this.

export DEBFULLNAME="Full Name"
export DEBEMAIL=your@emai.net
make deb-chl-bumpup

(You could set this environment variables more comfortably in a location of your choice to make those permanent.)
(deb-chl-bumpup is just automating and imho simplifying usage of debchange.)

64

Updated the wiki.

Package name. After your mail to Whonix-devel and the name naturally used in TimeSync: Whonix ™ Time Synchronization Mechanism, I think sdwdate-tray is more descriptive than sdwdate-gui, which sounds too general. I propose to rename the package sdwdate-tray.

65

Not sure. How likely is it that sdwdate-tray turns into a full gui? Especially the left click action could show a comprehensive overview of all states of the various checks.

66
How likely is it that sdwdate-tray turns into a full gui?
Quite likely. So we keep sdwdate-gui.
67

Two commits:

Using QFileSystemWatcher in sdwdate-gui for monitoring sdwdate status file.

A few remarks:

  • the Exit menu entry in sdwdate-gui context menu is for testing. Will be removed.
  • a single status file: python objects are serialized in sdwdate and deserialized in sdwdate-gui. We could put anything in there…
  • the icons are downloaded from mediawiki, for demonstration.
  • three icons at this stage: success, busy, error.

More to come. Minor and perhaps less minor debugging, and some questions.

68

Actually, I think a right click menu button to close the tray icon is a required feature. Please keep it.

69

Pushed check_sdwdate() · troubadoour/sdwdate-gui@03f6c9d · GitHub

Checking if sdwdate is running. It looks sort of awkward, asking the user to stop and restart the program once/if the problem is fixed. Could make a loop checking sdwdate, but that would require a separate thread in sdwdate-gui. Still far from ideal.

I was thinking of writing a separate program that checks sdwdate before launching sdwdate-gui. It could popup a GUI in case of failure. Same for bootclockrandomization, but non blocking.
[sdwdate-gui would then live by its name, becoming a mere monitor (hence the name below) . Good in the perspective of “standard” distributions.]

Using “Time Synchronization Monitor” in the tool tip text. Does it sound right for the gui name in desktop applications?

70

Let’s try to go real simple. sdwdate-daemon provides all the information, sdwdate-gui shows them in a usable way.

I guess the babysitting daemons way won’t work. Sdwdate shouldn’t crash. If it crashes, we should fix the bug. But in normal operation there should never be the case that it’ stopped without having the user intent that. To more we try to add any error handling code for such situations with loops and what not, the more we are creating the issue we want to fix. Does that make sense?

I mean, how often does this situation happen? systemd also supports restarting the service if it crashed for unrelated reasons. sd_notify, remember that [unrelated] discussion on the tracker. (⚓ T274 control-port-filter-proxy sd_notify support)

A loop sounds awkward indeed. Then you need to keep polling the file system. Best would be to get notified by inotifywait as soon as sdwdate creates any files that sdwdate-gui can use for output. Plus once sdwdate-gui starts, check the folder for existing files. (Because inotifywait won’t cover already existing files at time of startup.) If sdwdate does not run, i.e. if it hasn’t created any files, just say so. You could indeed advice the user to run “sudo service sdwdate restart” in such situations (or to use the right click action for that).

Maybe if sdwdate has not provided any status files yet, run “sudo service sdwdate status” once? Add the output of that to the tooltip? Then no loop. Just rely on inotifywait to notify about newly creates status files.

If it was any useful, this could also work the other way around. systemd unit files support stuff like ExecStartPre/Post, ExecStopPre/Post. This could be used to send some signal to sdwdate-gui. But I don’t think we need that for now. Just useful to know.

The name sounds alright to me. I am open to that.

71
I guess the babysitting daemons way won't work. Sdwdate shouldn't crash. If it crashes, we should fix the bug. But in normal operation there should never be the case that it' stopped without having the user intent that. To more we try to add any error handling code for such situations with loops and what not, the more we are creating the issue we want to fix. Does that make sense?
Yes, we could easily shoot our own foot.

But because we have to make some sdwdate check when the GUI is loaded , I implemented it (roughly) as suggested in your post.

  • check if status file exists.
  • if not, ask the user to try restarting sdwdate. If the icon is still red, report the bug. sdwdate-gui watch the folder (something equivalent to “inotifywait -e create path”). If the status file is created, it starts watching it.

That should be safe, and no sdwdate-gui exit-restart is required.

The last commit is a typo correction.

72

A batch of commits. The main ones:

  • orange icon only if fetching remotes not finished after boot, green in normal cycles.
  • modified the logic in the main loop so that the success file is written even if set_new_time is false
  • inform sdwdate-gui if sdwdate was stopped by the user.
  • separate status and message in sdwdate_loop.
  • different sleep times, retry on error.

At this stage, the latter is done only for “No values returned from url_to_unixtime”. The reason is that it happens randomly, without apparent cause, when running sdwdate at short intervals (less than a minute). It’s back to normal on the next cycle. In normal conditions, the probability that this happens is very low, but swdate would stop and the icon stay red for the duration of the next sleeping period.

It might have to do with my internet connection, but I suspect the problem lies with gevent timeout. If you could test it for a few hours with a short sleep time and read the log, that would help clarifying.

The sleeping time is adjustable after an error occurs too, which let us retry at will.

Next would be:

  • what to do on left click action (probably display the tool-tip text, or an expanded version)?
  • do we re-implement restart fresh in the menu?
  • anything else in the menu?
73

Commits not pushed to github yet?

74

Could this informing also be as lightweight as watching status files change?

- what to do on left click action (probably display the tool-tip text, or an expanded version)?
For start perhaps just the same message as the tool-tip.
- do we re-implement restart fresh in the menu?
- anything else in the menu?
Maybe like this... [Only development comments.] The "-----" should symbol dividing lines. (Just have a look at a few existing systray icons. Many are using these deciding lines as a stylistic feature.)
  • “View status.” (same as left click)
  • “Open sdwdate’s log.”
  • “Restart sdwdate - Gradually adjust the time.” [“normal restart”]
  • “Restart sdwdate - Clock jump.” [“restart fresh”]
  • “Stop sdwdate.”
  • “Exit.”

But this are all with question marks. We could use help with comments on usability.

Maybe “View status.” and “Open sdwdate’s log.” could be combined. So “Open sdwdate’s log.” would be a click to expand button or simpler just starting it in an editor. I guess the latter is simpler, better and sufficient.

75
Commits not pushed to github yet?
Yes, they are pushed.
76

Last change was on Aug 9, 2015.

Last commit I can see is:

Does not register changes from August 11, 2015.

77

Should have mentioned, most of the changes are in sdwdate.

From move test .f files to /usr/share · troubadoour/sdwdate@2e8bf67 · GitHub

78 
                    if len(self.already_picked_index_pool_one) == len(self.pool_one):

Could we make that?

                    if len(self.already_picked_index_pool_one) >= len(self.pool_one):

I want to make sure that also in corner cases that we cannot foresee that loop cannot lock up.

Please add python-gevent to dependencies.

WARNING - Signal SIGTERM received. Exiting.

Arguably that should also just be DEBUG because that happens during normal operation (shutdown). Let’s not have users report such warnings.

To check if sdwdate-daemon runs sane, the log needs to provide more information.

  • pid number of sdwdate [in first part of the log] to detect eventual duplicate daemons
  • everywhere where unitime is prevented, it also requires a human readable date
  • url comments [to catch eventual non-randomness of picked links, the .onion url gibberish cannot be well remembered]

Maybe a bit like sdwdate-bash log looked like. We don’t have to replicate the shortcomings of it of course. sdwdate-bash log was far from perfect.

25014: get : msydqstlz2kzerdg.onion:80 | local time: Wed Aug 12 14:40:17 UTC 2015 | link_comment_part: https://ahmia.fi/address/msydqstlz2kzerdg 25014: result: msydqstlz2kzerdg.onion:80 | local time: Wed Aug 12 14:40:24 UTC 2015 | status: success | took: 10s | diff: 0 second(s)
  • took: looks like that information would be difficult to get? Not that important.
  • diff: quite useful

Also the results overview.

25014: Results summary: one: -1 | two: 1 | three: 0 | second(s)
25014: Min: -1 | Max: 1 | Median diff: 0 second(s) [0 nanosecond(s)]
25014: local unixtime : 1439390426 | local time : Wed Aug 12 14:40:26 UTC 2015
25014: remote unixtime: 1439390426 | remote time: Wed Aug 12 14:40:26 UTC 2015
79

Icons belong into sdwdate-gui. Not sdwdate. In folder /usr/share/icons/sdwdate-gui/. Not anon-icon-pack.

80
Should have mentioned, most of the changes are in sdwdate.
My mistake.

Can we make the passive tooltip text (mouse hover over) copyable? Only if not too much effort.

When you keep your mouse on that tooltip, the tooltip won’t change until you move your mouse away and there again. Is this something that could be made more dynamic?

Non fatal / crashing error. Got this while running from cli. (Not by autostart.)

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sdwdate_gui/sdwdate_gui.py", line 70, in status_changed
    status = pickle.load(f)
  File "/usr/lib/python2.7/pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "/usr/lib/python2.7/pickle.py", line 858, in load
    dispatch[key](self)
  File "/usr/lib/python2.7/pickle.py", line 880, in load_eof
    raise EOFError
EOFError
 with open(self.status_path, 'rb') as f:

Do you think this should be put within exception handling? Perhaps there could be race conditions while sdwdate-gui tries to read the file while sdwdate-daemon just rewrote it so the read would fail?