On Tuesday 28 May 2019 01:23:45 pm Gene Heskett wrote: > On Tuesday 28 May 2019 11:53:26 am Reco wrote: > > Hi. > > > > On Tue, May 28, 2019 at 10:53:04AM -0400, Greg Wooledge wrote: > > > On Mon, May 27, 2019 at 12:11:29PM +0300, Reco wrote: > > > > On Sun, May 26, 2019 at 05:45:56PM -0400, Gene Heskett wrote: > > > > > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local > > > > > #!/bin/sh -e > > > > > > > > Any execution error will terminate the script. > > > > > > The blame is on Debian for that one. That's what Debian put in > > > the default /etc/rc.local file in every release up to jessie. > > > (They "fixed" this in stretch by not having a default > > > /etc/rc.local file at all, but if you upgraded to stretch, you > > > still have the old default file.) > > > > I disagree. /etc/rc.local is a part of init (whenever it's sysvinit > > or systemd or upstart), being run as root. If something goes wrong > > there - it should fail as verbose as possible (yep, journald is > > worthless in this regard). Helps with diagnostics and all that. > > I'll sure as hell 2nd that. If anything, rc.local should stack the > errors and keep on trucking, and when its out of things to do, then > spit out the errors if any, in the order encountered, to the syslog. > > > > Debian's policy for developers is to use -e with all shell scripts > > > (horrible!), > > > > On the contrary. Helps with error catching, limits the damage (all > > package scripts are executed as root), promotes at least some kind > > of code quality. > > Side effects may include non-removing packages (failed prerm > > script), of course, but they have bugs.debian.org for these cases. > > > > > but inflicting that same policy on end users is not wise. > > > > End users can remove that '-e' flag if they believe it's > > problematic. rc.local is a simple shell script, open to all kinds of > > abuse including this one. > > I assume the -e is a bash option? I just rescanned the man page > without find a reference other than a test for file -e=exists > filename. > > It is in the shebang line, so what does that do when its in that > position. > And at that point in composing that reply, the keyboard went dead. I thought that was cron, calling hpfax, and finding it had nothing to do, so it locks up hid-common, so I renamed hpfax to hpfox last week, figuring that would disable that scared bull in a china shop. But in looking over the boot log just now, I find hpfox running! Pardon my language but if I've renamed it, how the hell is the system finding it to run it?
from the syslog: in time order but much elided May 28 13:47:40 coyote systemd[949]: Starting D-Bus User Message Bus Socket. [...] May 28 13:47:41 coyote rc.local[842]: HEYU: The file /usr/local/var/tmp/heyu/heyu.out.ttyUSB0 does not exist or is not writable. [...] May 28 13:47:42 coyote hp[994]: io/hpmud/pp.c 627: unable to read device-id ret=-1 [...] May 28 13:47:43 coyote rc.local[842]: read: Connection reset by peer May 28 13:47:43 coyote /hpfox: [999]: error: Failed to create /var/spool/cups/tmp/.hplip [...] May 28 13:47:46 coyote systemd[1]: Started Perl-based spam filter using text analysis. Since systemd started spamassassin, I can take that back out of rc.local. I'll do that and reboot again, about 5 times since my last reply in this thread. Since I don't use hplip, no hp printers about, how do I use systemctl to disable its even starting? Thanks, but comment on the log snippets if you can. > > Reco > > Cheers, Gene Heskett Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
