Bug#588666: boot message stuck onto next message
control: tags -1 +fixed-upstream [2019-08-26 16:32] Jesse Smith > On Sun, 25 Aug 2019 16:07:30 + Dmitry Bogatov wrote: > > > > > Each line a process sends: > > > > * should be prefixed by the name of the process that sent it. > > > > * should end with a newline. > > > > > > And (#398269) each line should be either from a process or the kernel, > > > distinguishable enough. > > > > > > I fully agree, that should be basic and not need discussion. > > > > Okay, reassigning then. > > > > @Jesse, yet another feature request for startpar :) > > > I have added a command line flag (-n) which causes the name of the > sending process to prefix output, unless the command is interactive. > > It looks like this: startpar -n -t 1 process-a process-b > > process-a: Starting process... > process-b: Starting process... > process-b: Done. > process-a: Done. > > This will be in the next release of startpar. I'm looking at adding a > newline to the end of output too. Great. Thank you. Tagged as-needed. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#588666: boot message stuck onto next message
On Sun, 25 Aug 2019 16:07:30 + Dmitry Bogatov wrote: > > > Each line a process sends: > > > * should be prefixed by the name of the process that sent it. > > > * should end with a newline. > > > > And (#398269) each line should be either from a process or the kernel, > > distinguishable enough. > > > > I fully agree, that should be basic and not need discussion. > > Okay, reassigning then. > > @Jesse, yet another feature request for startpar :) I have added a command line flag (-n) which causes the name of the sending process to prefix output, unless the command is interactive. It looks like this: startpar -n -t 1 process-a process-b process-a: Starting process... process-b: Starting process... process-b: Done. process-a: Done. This will be in the next release of startpar. I'm looking at adding a newline to the end of output too. - Jesse
Bug#588666: boot message stuck onto next message
control: reassign -1 startpar control: tags -1 upstream control: severity -1 wishlist [2019-08-22 21:31] Thorsten Glaser > > DB> Can you please elaborate what change to startpar you propose? I did not > > DB> understand. > > > > I think I am saying: > > > > Each line a process sends: > > * should be prefixed by the name of the process that sent it. > > * should end with a newline. > > And (#398269) each line should be either from a process or the kernel, > distinguishable enough. > > I fully agree, that should be basic and not need discussion. Okay, reassigning then. @Jesse, yet another feature request for startpar :) -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#588666: boot message stuck onto next message
On Fri, 23 Aug 2019, 積丹尼 Dan Jacobson wrote: > DB> Can you please elaborate what change to startpar you propose? I did not > DB> understand. > > I think I am saying: > > Each line a process sends: > * should be prefixed by the name of the process that sent it. > * should end with a newline. And (#398269) each line should be either from a process or the kernel, distinguishable enough. I fully agree, that should be basic and not need discussion. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#588666: boot message stuck onto next message
DB> Can you please elaborate what change to startpar you propose? I did not DB> understand. I think I am saying: Each line a process sends: * should be prefixed by the name of the process that sent it. * should end with a newline.
Bug#588666: boot message stuck onto next message
control: tags -1 +moreinfo [2010-07-11 18:45] jida...@jidanni.org > > "PR" == Petter Reinholdtsen writes: > PR> I guess smartmontools uses too long time, and thus startpar > PR> passes on incomplete lines causing such output. > > Perhaps make each line show who is doing the talking, > and only one process allowed to print per line... > That way it would be fine if several processes are talking to syslog at > the same time. Just make sure it looks like an IRC log, one person per > line. If they are still talking, then a second one of their lines will > appear later. > Or at least make sure a \n gets added to each line. Can you please elaborate what change to startpar you propose? I did not understand. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#588666: boot message stuck onto next message
reassign 588666 sysvinit-utils thanks I don't understand the problem, as wicd and smartmontools both just seem to use the standard log_daemon_msg in /etc/init.d/* . This is probably caused by startpar, which have a limit on how long it wait for a line printed by the subprocesses to complete. In this case, I guess smartmontools uses too long time, and thus startpar passes on incomplete lines causing such output. This is actually according to design of the parallel booting. I guess the timeout can be made longer, or smartmontools can be made faster. Reassigning to the package with startpar, to assign it to a package remotely related to this issue. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588666: boot message stuck onto next message
PR == Petter Reinholdtsen p...@hungry.com writes: PR I guess smartmontools uses too long time, and thus startpar PR passes on incomplete lines causing such output. Perhaps make each line show who is doing the talking, and only one process allowed to print per line... That way it would be fine if several processes are talking to syslog at the same time. Just make sure it looks like an IRC log, one person per line. If they are still talking, then a second one of their lines will appear later. Or at least make sure a \n gets added to each line. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588666: boot message stuck onto next message
X-debbugs-Cc: smartmonto...@packages.debian.org Package: initscripts Version: 2.88dsf-11 Severity: wishlist smartmontools is the only package that makes such mashed together ... # zgrep -nHi start.*start boot* boot:40:Sun Jul 11 06:26:35 2010: Starting S.M.A.R.T. daemon: smartdStarting Network connection manager: wicd. boot.0:42:Sat Jul 10 06:53:12 2010: Starting S.M.A.R.T. daemon: smartdStarting Network connection manager: wicd. boot.1.gz:42:Fri Jul 9 19:53:12 2010: Starting S.M.A.R.T. daemon: smartdStarting Network connection manager: wicd. boot.2.gz:42:Fri Jul 9 10:14:35 2010: Starting S.M.A.R.T. daemon: smartdStarting Network connection manager: wicd. ... log lines during boot, consistently. They are all followed by a line with just a dot, Sun Jul 11 06:26:35 2010: Starting S.M.A.R.T. daemon: smartdStarting Network connection manager: wicd. Sun Jul 11 06:26:43 2010: . Sun Jul 11 06:26:43 2010: Starting HTTP cache proxy server: wwwoffled wwwoffled[1686] Information: Read in 0 trusted certifi I don't understand the problem, as wicd and smartmontools both just seem to use the standard log_daemon_msg in /etc/init.d/* . Maybe it is a parallelism issue, # find /etc/rc??? -name S*smart* /etc/rc2.d/S02smartmontools /etc/rc3.d/S02smartmontools /etc/rc4.d/S02smartmontools /etc/rc5.d/S02smartmontools # find /etc/rc??? -name S*wicd\* /etc/rc2.d/S03wicd /etc/rc3.d/S03wicd /etc/rc4.d/S03wicd /etc/rc5.d/S03wicd etc. etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
