scosol
commented
5 years ago Noted that this appears to be a problem on SLES 12 as well. (SP3 specifically)
Open scosol opened 5 years ago
scosol
commented
5 years ago Noted that this appears to be a problem on SLES 12 as well. (SP3 specifically)
cmayer68
commented
5 years ago good idea. this should be easy to implement. can you add it as an issue in the github repo?
--curt
On Mon, Oct 15, 2018 at 11:36 AM scosol notifications@github.com wrote:
Noted that this appears to be a problem on SLES 12 as well. (SP3 specifically)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Appdynamics_HA-2Dtoolkit_issues_95-23issuecomment-2D429966685&d=DwMCaQ&c=3_5eq9zYXWRS8ywqccmjfTRKM8mRLoQp6HBg1Tdb_Pc&r=nsJ1Vt4kkj1MF7fPuYx_OHpUcucCi7WPVJJQ5IIS6oA&m=TaWWlhsKkTAwR_r9HRTgdhh0ZKtF8Y3qdiL8g1fhjuQ&s=nVqKDVHMHwwOWROECSr2ln0FF2zaeDQYVtRDvV0I_Oo&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_APNeTJbP3AguNR8NiUJSZMoiOjRgr58oks5ulNWhgaJpZM4XWJ32&d=DwMCaQ&c=3_5eq9zYXWRS8ywqccmjfTRKM8mRLoQp6HBg1Tdb_Pc&r=nsJ1Vt4kkj1MF7fPuYx_OHpUcucCi7WPVJJQ5IIS6oA&m=TaWWlhsKkTAwR_r9HRTgdhh0ZKtF8Y3qdiL8g1fhjuQ&s=XLwlmXoYaXJ3P4VKyixyUtd0j6JQNaTqMdcusq2R4Es&e= .
-- Curt Mayer | Senior Architect, Customer Success Office 707.540.3441 | Mobile 707.540.3441 http://appdynamics.com/ Watch http://appdynamics.wistia.com/medias/56gnkuk6mvour Video | Try https://portal.appdynamics.com/account/signup/signupFormour FREE Trial | Twitter http://www.twitter.com/appdynamics| Facebook http://www.facebook.com/pages/AppDynamics/193264136815?ref=nf| appdynamics.com http://www.appdynamics.com/
I've run in to several difficult-to-nail-down problems with the currently-in-use "sudo service ..." model on recent Debian and Ubuntu systems-
Doing things this way creates two (needless?) layers of obfuscation where signals and perms are getting dumped/lost: the service command actually executes systemctl, which then through sysv-init simply executes the files in /etc/init.d: appdynamics*
My recommendation is to use these /etc/init.d/appdcontroller files directly for all operations and exist completely outside of the OS's service management. IE: we can install those files "/etc/init.d/appdcontroller" and make sure they work for us and our purposes, and then whatever the OS tries to do with them on startup/shutdown/whatever is its own business.
As it is now, the failover/replicate scripts using "service..." commands results in failure of several operations.