www.cendio.com
Bug 4471 - VSM is terminated every sunday on Ubuntu
: VSM is terminated every sunday on Ubuntu
Status: CLOSED FIXED
: ThinLinc
VSM Server
: 3.4.0
: PC Unknown
: P2 Normal
: 4.1.0
Assigned To:
:
:
:
: 5056
  Show dependency treegraph
 
Reported: 2012-11-12 09:52 by
Modified: 2014-03-31 09:47 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2012-11-12 09:52:41
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.
------- Comment #1 From cendio 2012-11-12 09:55:35 -------
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
------- Comment #3 From cendio 2012-11-26 10:16:08 -------
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.
------- Comment #4 From cendio 2012-11-27 08:51:27 -------
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.
------- Comment #5 From cendio 2012-11-27 08:54:35 -------
(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.
------- Comment #6 From cendio 2012-12-04 12:35:54 -------
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.
------- Comment #7 From cendio 2012-12-04 14:44:16 -------
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
------- Comment #8 From cendio 2012-12-04 14:52:00 -------
(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.
------- Comment #9 From cendio 2012-12-10 11:28:41 -------
I've verified that the problem is gone after removing "&> /dev/null".
------- Comment #11 From cendio 2013-01-07 12:58:11 -------
Fix commited in r26357.
------- Comment #12 From cendio 2013-01-14 09:56:07 -------
(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.
------- Comment #13 From cendio 2013-05-16 14:44:00 -------
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.
------- Comment #14 From 2014-03-30 11:08:31 -------
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.
------- Comment #15 From cendio 2014-03-31 09:46:48 -------
(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 .