flickerfly

Other way around. Ubuntu 16.04 uses Systemd where it used to use Upstart. The one thing I can't replicate is gathering the status from the service in the same way as was done before.

Here is what I ended up coming up with. It should be put in /etc/systemd/system/ https://github.com/flickerfly/My-Script-Collection/blob/50b70155000cfe86c18e2587d85cd80e12a866fa/rcl.service [Unit] Description=Retrospect backup client After=network.target local-fs.target system.slice systemd-journald-dev-log.socket basic.target sysinit.target systemd-journald.socket Before=shutdown.target graphical.target multi-user.target [Service] ExecStart=/usr/local/retrospect/client/retroclient ExecStop=/usr/local/retrospect/client/retrocpl -stop Restart=on-failure RestartSec=60s [Install] WantedBy=multi-user.target

Very nice, I haven't messed with 11.0 yet. I'm glad to hear it.

It appears that client 10.05 works fine on Ubuntu 16.04 server, but the startup scripts do not operate properly. $ sudo systemctl start rcl Failed to start rcl.service: Unit rcl.service not found. $ sudo service rcl start Failed to start rcl.service: Unit rcl.service not found. Has anyone built startup scripts for the systemd yet?

This turned out to be a version mismatch. Linux client version 10.5.0.103 doesn't work with server version 10.0.2. Despite what the errors were communicating, it wasn't a network issues at all.

Here is my little script I'm using to clean up a server before I install the latest client. I hope it help out. I'm also working on my own installer as I'm finding the current one for Ubuntu continues to be really buggy. If you are interested, pm me. #!/bin/bash # Stop the running client if [ -f "/usr/local/dantz/client/retrocpl" ]; then /usr/local/dantz/client/retrocpl -stop > /dev/null fi if [ -f "/usr/local/retrospect/client/retrocpl" ]; then /usr/local/retrospect/client/retrocpl -stop > /dev/null fi # Remove the running client from startup update-rc.d -f rcl remove update-rc.d -f retroclient remove # Uninstall rpm or deb versions of th client sudo apt-get -y remove retroclient sudo apt-get -y remove RetroClient sudo yum -y remove retroclient sudo yum -y remove RetroClient # Remove any files that may be lingering about rm -rf /usr/local/retrospect/ rm -rf /usr/local/dantz/ rm /etc/init.d/rcl rm /etc/init.d/retroclient # Don't remove excludes file cause that comes in handy #rm /etc/retroclient.excludes # Don't remove state file or you have to reactivate client at server #rm /var/log/retroclient.state rm /var/log/\retroclient.history rm /var/log/retroclient.history rm /var/log/retroclient.log rm /var/log/retroclient.*.gz rm /var/log/retropds.log rm /usr/local/man/man1/retroc* rm /usr/man/man1/retroc* rm /usr/share/info/retroclient.info.gz

I'm working on upgrading all my linux clients to the 10.5.x version of the RetroClient. Typically I have not removed the retroclient.state file, but on one it just happened for some reason. Anyway, as I'm trying to add the client back into Retrospect Server by IP, the test works fine showing the client name, IP and version; but when I click "Add" I get the message "Sorry, couldn't add the backup client, error -519 (network communication failed)". This is a virtual machine on a VMWare environment like all my other clients. I have tried removing the state file again, completely removing all files related to retrospect and installing again and I'm getting the same results no matter what. One difference that I wonder if it is related, the server is under heavy load. Swapping that load elsewhere isn't currently an option. I see others in a physical network have moved their machines around and found that there was some grumpiness in the network that caused this error. I'm in a virtual network so that seems an awkward diagnosis. What should I be trying to get this client reconnected? In my /var/log/retrospect.log file I get the following each time I try to add. I have the log level turned up to 9 for this. 2015-10-14T15:08:55: NetCheckNewInterfaces: Handle 10 open 2015-10-14T15:08:56: NetCheckNewInterfaces: Handle 10 closed 2015-10-14T15:08:56: connListener: starting thread connAccept 2015-10-14T15:08:56: connListener: Handle 8 open 2015-10-14T15:08:56: SThreadSpawn: starting thread 1532163840 2015-10-14T15:08:56: Remote connection established by X.X.5.192:55964 2015-10-14T15:08:56: connSetOptions: Changing TCP_NODELAY from 0 to 1 2015-10-14T15:08:56: NetSockAdd: adding socket 8 to interface 2 2015-10-14T15:08:56: *** netPrintList: interface = 127.0.0.1:0 2015-10-14T15:08:56: *** socket 6 2015-10-14T15:08:56: *** netPrintList: interface = X.X.65.43:0 2015-10-14T15:08:56: *** socket 9 2015-10-14T15:08:56: *** socket 5 2015-10-14T15:08:56: *** socket 8 2015-10-14T15:08:56: connTCPConnection: conn = 1207962272, code = 112, tid = 0, count = 4 2015-10-14T15:08:57: connTCPConnection: conn = 1207962272, code = 112, tid = 0, count = 4 2015-10-14T15:09:00: connTCPConnection: conn = 1207962272, code = 104, tid = 0, count = 36 2015-10-14T15:09:00: connLogin: successful 2015-10-14T15:09:00: connTCPConnection: non-stream packet too large: 229185216 2015-10-14T15:09:00: NetSockDel: removing socket 8 2015-10-14T15:09:00: connDoLogout: logged out 2015-10-14T15:09:00: connAccept: socket 8 deleted from interface 2 2015-10-14T15:09:00: sThreadExit: exiting thread 1532163840 2015-10-14T15:09:00: NetCheckNewInterfaces: Handle 8 open 2015-10-14T15:09:01: NetCheckNewInterfaces: Handle 8 closed 2015-10-14T15:09:05: NetCheckNewInterfaces: Handle 8 open 2015-10-14T15:09:06: NetCheckNewInterfaces: Handle 8 closed

What is the suggested upgrade procedure to move version 7.7 and version 9 Linux clients to version 10?

When I see that error, I can simply stop and restart the rcl service and life moves on. I get it somewhat regularly, but less so on the more recent versions.

Yeah, even the new 64-bit client is apparently only a 64-bit installer because it requires the i386 libraries

Retrospect support said to install the i386 libs like we did with the pre-9.5 installer to fix this. It does seem to work. I was really hoping to get away from that extra baggage with a 64-bit package of the installer.

I haven't heard anything about the reason for those yet.

I'm getting "Error -540" while doing Block level incremental backups of a Ubuntu 14.04 linux client. I note here that there was a work around for this many years ago and it was eventually resolved in the last version fo the linux client, but perhaps the same thing has returned? History: http://forums.retrospect.com/index.php?/topic/18634-error-540/.

This information, I believe, is saved in /var/log/retroclient.state. If that file is being removed from Mint in any way, that would potentially cause this issue.

I cleaned up my version of the install script a bit more and cleared out some bugs I introduced. I also started on an uninstall script. Install.txt Uninstall.txt