For instance, you could do something such as Basically, this should copy the certicates that were accepted by msysgit so they can be used by TortoiseGit.Īnother, and possibly better solution, is to create a symbolic link so that those 2 folders are in fact a single one. What you will want to do next is go to C:\Program Files (x86)\Git\.subversion and copy everything into %USERPROFILE%\.subversion. This step is crucial to get the certificate details saved onto your machine. The first step is to run some git command, for instance git clone via a command line so that git may auto-accept (or ask you to accept) the certificate. You will need to have msysgit installed and available in your PATH for the following to work. ![]() But it is possible to get your git repository to work with TortoiseGit (and work with the required certificate). For instance, accepting self-signed certificated is not possible, which gives you the known issue 318.Īs of TortoiseGit 1.8.5.0, it is still not possible to accept certificates through the GUI. I will have to do more research as to how/why this issue occurs as I’ve seen it happen only on CentOS machines so far (the master server is a Debian machine).įor some odd reason it seems that the system designed into TortoiseGit doesn't allow the user to interact with git when it requires user interaction. After the removal of the semaphore, it is possible again to run munin correctly and the identifier removed error is gone. In my case the “fix” itself was to remove the semaphore that the plugin wasn’t able to obtain (the reason of this still elude me though). ![]() With that semid you can do two things: first, you can check if it is still alive by calling ipcs, second, you can remove it with ipcrm -s semid. Read(4, "\n redo if $Internal instead of 0x2ab08bb67cf0. Ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff13da8e30) = -1 ENOTTY (Inappropriate ioctl for device) I went ahead and launched strace munin-run mysql_files_tables which outputted a lot of stuff and then stopped at the following point: Tonight I remembered about strace, which is pretty awesome in circumstances like this one. After a couple of days though the second server also decided to exhibit a similar issue… After a minor change, one of two client nodes stopped working correctly while the other was still fine. Munin and the mysql plugins were installed on two servers and it was working fine on both of them (and a third one as master node). I had left this issue on the side for a couple of days hoping to come back to it at some point. Thus, I didn’t expect to receive much help out of it (and I didn’t). Obviously, one can see quickly that this is a quite specific question that not many may have actually encountered. Has anyone faced this problem? (a quick search on google didn’t present any relevant help) I haven’t yet rebooted the machine as it is used for many projects (I’d obviously like to be able to diagnose the problem without requiring a restart if it was possible). Since it is a module related to shared memory, I tried tracking down shared memory segments with ipcs without much success. I do not have any knowledge about the IPC or the ShareLite library so I don’t really know were to start looking. IPC::ShareLite store() error: Identifier removed at /usr/lib/perl5/vendor_perl/5.8.8/Cache/SharedMemoryBackend.pm line 156īut after a while it will revert to the previous error. All was working fine until I tried to add the apache plugin (which works fine).įor some odd reason, the mysql plugins for munin that used to work ceased to work… I’m now getting a weird error whenever I’m running the plugin with munin-run. I’ve recently setup a munin-node on a CentOS server. I posted the following on in hope I’d get help from someone more experienced than I am. ![]() The following depicts how I “solved” a problem I recently had regarding munin, its mysql plugins and the shared memory cache library used by the plugins (written in perl and using IPC::ShareLite).įirst off, let’s begin with a description of the problem.
0 Comments
Leave a Reply. |