Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for the execution functions of services #823

Merged
merged 2 commits into from Oct 29, 2015

Conversation

gao-yan
Copy link
Member

@gao-yan gao-yan commented Oct 29, 2015

Fix: services: Correctly determine if operations are in-flight

Previously, we kind of abused the return codes of upstart_job_exec(),
systemd_unit_exec() and services_os_action_execute(). For an
asynchronous operation, the return code is supposed to tell whether the
'op' should be freed by the caller. It doesn't exactly indicate whether
the 'op' is in-flight.

For instance, in services_os_action_execute(), if stat() or fork() fail,
operation_finalize() will be called for an asynchronous operation, which
will free the operation and return TRUE if the operation is
non-recurring. But in action_async_helper(), the freed operation
would be considered in-flight and added into inflight_ops list.

Previously, we kind of abused the return codes of upstart_job_exec(),
systemd_unit_exec() and services_os_action_execute(). For an
asynchronous operation, the return code is supposed to tell whether the
'op' should be freed by the caller. It doesn't exactly indicate whether
the 'op' is in-flight.

For instance, in services_os_action_execute(), if stat() or fork() fail,
operation_finalize() will be called for an asynchronous operation, which
will free the operation and return TRUE if the operation is
non-recurring. But in action_async_helper(), the freed operation
would be considered in-flight and added into inflight_ops list.
…us is closed

According to the documentation of dbus_connection_send_with_reply(), if
the connection is disconnected or you try to send Unix file descriptors
on a connection that does not support them, the DBusPendingCall will be
set to NULL. In this case, we can directly return an error instead of
waiting for timeout.
@gao-yan
Copy link
Member Author

gao-yan commented Oct 29, 2015

Fix: systemd: Directly return an error if the connection to System DBus is closed

According to the documentation of dbus_connection_send_with_reply(), if
the connection is disconnected or you try to send Unix file descriptors
on a connection that does not support them, the DBusPendingCall will be
set to NULL. In this case, we can directly return an error instead of
waiting for timeout.

@kgaillot
Copy link
Contributor

Nice catches, thanks

kgaillot added a commit that referenced this pull request Oct 29, 2015
Fixes for the execution functions of services
@kgaillot kgaillot merged commit 6df00e2 into ClusterLabs:master Oct 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants