Fixed in LTSP 5.3. /sbin/init-ltsp now calls /usr/share/ltsp/init-
ltsp.d/Ubuntu/50-syslog before even the real init is started.
** Changed in: ltsp (Ubuntu)
Status: Triaged => Fix Released
** Changed in: ltsp (Ubuntu)
Assignee: (unassigned) => Alkis Georgopoulos (alkisg)
--
You rec
Fixed in LTSP 5.3. /sbin/init-ltsp now calls /usr/share/ltsp/init-
ltsp.d/Ubuntu/50-syslog before even the real init is started.
** Changed in: ltsp
Status: Triaged => Fix Released
** Changed in: ltsp
Assignee: Stéphane Graber (stgraber) => Alkis Georgopoulos (alkisg)
--
You receive
** Changed in: ltsp (Ubuntu)
Status: New => Triaged
** Also affects: ltsp
Importance: Undecided
Status: New
** Changed in: ltsp
Status: New => Triaged
** Changed in: ltsp
Importance: Undecided => Medium
** Changed in: ltsp
Assignee: (unassigned) => Stéphane Grabe
Confirmed on Maverick too. :-(
For now (as a workaround) we can add the otherwise dynamically created
ltsp.conf to the /etc/rsyslog.d directory in the chroot and rebuild the chroot
image. Of course this does not allow for per client configuration of remote
syslogging (ie. in the /srv/tftp//l
I have the same problem (karmic). Rsyslog is started by an upstart script,
which starts on event 'filesystem',
while ltsp-client-setup is a System-V style init script, started at rcS. The
result is that rsyslog starts before
ltsp-client-setup has written /etc/rsyslog.d/50-ltsp.
--
rsyslog is
