I assume that the GLIB-Critical messages can be avoided by adding some statements to reset the IDs in the source to prevent calling g_source_remove with an id that was already removed once:
e.g. for consolekit:
ck-job.c
if (job->priv->out_watch_id > 0) { g_source_remove (job->priv->out_watch_id);
+ job->priv->out_watch_id = 0;
}
if (job->priv->err_watch_id > 0) { g_source_remove (job->priv->err_watch_id);
+ job->priv->err_watch_id = 0;
}
(Not sure whether I correctly identified all cases where a variable should be reset after use.)
As already stated by others - the ssh hang most probably is not related to the GLIB critical error message noise.
I assume that the GLIB-Critical messages can be avoided by adding some statements to reset the IDs in the source to prevent calling g_source_remove with an id that was already removed once:
e.g. for consolekit: >out_watch_ id > 0) {
g_source_ remove (job->priv- >out_watch_ id); >out_watch_ id = 0; >err_watch_ id > 0) {
g_source_ remove (job->priv- >err_watch_ id); >err_watch_ id = 0;
ck-job.c
if (job->priv-
+ job->priv-
}
if (job->priv-
+ job->priv-
}
ck-run-programs.c
g_source_ remove (cd->timeout_id);
+ cd->timeout_id = 0;
ck-tty- idle-monitor. c monitor- >priv-> timeout_ id > 0) {
g_source_ remove (tty_idle_ monitor- >priv-> timeout_ id); monitor- >priv-> timeout_ id = 0;
if (tty_idle_
+ tty_idle_
}
ck-vt-monitor.c >priv-> process_ queue_id > 0) {
g_source_ remove (vt_monitor- >priv-> process_ queue_id) ; >priv-> process_ queue_id = 0;
if (vt_monitor-
+ vt_monitor-
}
(Not sure whether I correctly identified all cases where a variable should be reset after use.)
As already stated by others - the ssh hang most probably is not related to the GLIB critical error message noise.