We have got several reports of that VSM is not running on monday morning, ie that something terminates it every sunday. It probably has something to do with cron.
Discussion on mailing list: http://lists.cendio.se/pipermail/thinlinc-technical/2012-September/000174.html One of the several issues: https://intranet.lkpg.cendio.se/tracker/issue13796
Previous tests i have been able to reproduce the stop, retried today with a clean ubuntu12.04 up-to-date with thinlinc 4.0.0 setting date to Sunday 2 Dec 07:40 but failed to reproduce.
In issue https://intranet.lkpg.cendio.se/tracker/issue13796 the thinlinc pid files was moved to a subdirectory /var/run/thinlinc/ which "fixed" the the problem, by this fact we are sure that our init.d script is used to restart the services and highly probably by logratate by matching crontab run and anacron delay and timstamps on logfiles.
(In reply to comment #4) > In issue https://intranet.lkpg.cendio.se/tracker/issue13796 the thinlinc > pid files was moved to a subdirectory /var/run/thinlinc/ which "fixed" > the the problem, by this fact we are sure that our init.d script is used > to restart the services and highly probably by logratate by matching > crontab run and anacron delay and timstamps on logfiles. Note: if pid file doesn't exists, our init.d script will not detect any running thinlinc service and there for no stop/start of service will be performed. The restart of services on logrotate is to make service use the new logfile created instead of the old rotate one.. vsmserver.log will be renamed to vsmserver.log.1 and current vsmserver process will still log into vsmserver.log.1.
A sunday has passed and looking trough the logs of my physical ubuntu machines shows that, sevices are still running but... A logrotate was performed and the restart of services has not been done at all making the service to log into rotated.log.1 file instead of new rotated.log.
I've done some tests on Ubuntu with: /usr/sbin/logrotate -f /etc/logrotate.conf The -f forces the log to happen every time. There are 2 strange things with this command on Ubuntu: 1) It seems to execute in the background. 2) You get the error message: stdin: is not a tty The latter is apparently because /root/.profile is sourced, and it contains: mesg n
(In reply to comment #7) > I've done some tests on Ubuntu with: > > /usr/sbin/logrotate -f /etc/logrotate.conf > > The -f forces the log to happen every time. There are 2 strange things with > this command on Ubuntu: > > 1) It seems to execute in the background. Found the reason for this. /etc/logrotate.d/thinlinc-vsm-agent contains: /var/log/vsmagent.log { missingok postrotate /etc/init.d/vsmagent condrestart &> /dev/null endscript } The script (between postrotate and endscript) is executed through /bin/sh. However, on Ubuntu, /bin/sh is not Bash, so it doesn't understand the "&>" syntax. Instead, it is interpreted as a backgrounding operator.
I've verified that the problem is gone after removing "&> /dev/null".
Fix commited in r26357.
(In reply to comment #11) > Fix commited in r26357. Commit r26357 removed all redirection to /dev/null which produces spam mail to root when logrotate was executed. Commit r26394 adds back the redirection to /dev/null as the intention was with &> in the first place.
Tested as follows on Ubuntu 13.04: --- aaron@guinea:~$ sudo /etc/init.d/vsmagent status ThinLinc vsmagent (pid 1157) is running aaron@guinea:~$ sudo /etc/init.d/vsmserver status ThinLinc vsmserver (pid 1265) is running aaron@guinea:~$ ls -l /var/log/{vsm,tl}* -rw-r--r-- 1 root root 49936 maj 15 14:03 /var/log/tlsetup.log -rw------- 1 root root 1052 maj 15 14:06 /var/log/tlwebadm.log -rw------- 1 root root 933 maj 15 14:33 /var/log/vsmagent.log -rw------- 1 root root 1717 maj 16 14:06 /var/log/vsmserver.log aaron@guinea:~$ sudo logrotate -f /etc/logrotate.conf aaron@guinea:~$ ls -l /var/log/{vsm,tl}* -rw-r--r-- 1 root root 49936 maj 15 14:03 /var/log/tlsetup.log -rw------- 1 root root 1052 maj 15 14:06 /var/log/tlwebadm.log -rw------- 1 root root 153 maj 16 14:40 /var/log/vsmagent.log -rw------- 1 root root 1072 maj 16 14:40 /var/log/vsmagent.log.1 -rw------- 1 root root 372 maj 16 14:40 /var/log/vsmserver.log -rw------- 1 root root 2017 maj 16 14:40 /var/log/vsmserver.log.1 aaron@guinea:~$ sudo /etc/init.d/vsmserver status ThinLinc vsmserver (pid 16966) is running aaron@guinea:~$ sudo /etc/init.d/vsmagent status ThinLinc vsmagent (pid 16944) is running --- Code also looks okay; closing.
Actually, the resolution to this problem, which I assume was first removing &> /dev/null and then replacing this with 2>&1 > /dev/null (which is what I find under /etc/logrotate.d in release 4.1.1) is still not accurate. It should be > /dev/null 2>&1 (First stdout is redirected to /dev/null, then this redirection is copied to stderr.) Best regards, Mikael D.
(In reply to comment #14) > Actually, the resolution to this problem, which I assume was first removing > > &> /dev/null > > and then replacing this with > > 2>&1 > /dev/null > > (which is what I find under /etc/logrotate.d in release 4.1.1) is still not > accurate. Moved to https://www.cendio.com/bugzilla/show_bug.cgi?id=5056 .
