[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: End of hypocrisy ? (Alt. title: Learning to cope with systemd)



On Wed 06 Aug 2014 at 12:02:45 -0400, John wrote:

> On 05/08/14, Brian (ad44@cityscape.co.uk) wrote:
>  
> > >...  and then I
> > > noticed /etc/cups/cupsd-systemd-listen.conf.  I _guess_ it was
> > > installed behind my back without any warning. ...
> > It is impossible on Debian for a file to be installed behind one's
> > back. Of course, if you not look at what a package contains,
> > README.Debian, a changelog, NEWS.Debian etc then it may look like
> > that.
> 
> Does anyone read all that as a matter of routine upgrading?  I ran
> aft-file search on the file, to see what package was involved, and got
> no return, which makes it hard to figure out which changelog, etc. to
> read.

Many don't. But while they could correctly claim everything was done
without their knowledge they cannot maintain it was done behind their
backs. apt-file (or dpkg -S) would find nothing because the file is
generated by the preinst of cups-daemon.

> > I would say it is extremely unlikely that
> > cupsd-systemd-listen.conf broke your cups.
> 
>  My reason for suspecting cupsd-systemd-listen.conf is that I did not
> configure it (not knowing it was there), so it did not list anything.
> I had no localhost:631, no cups socket -- because I had nothing listed
> in that file?  Among the changes I made in getting my printer going
> again was adding
> ListenStream=127.0.0.1:631
> ListenStream=localhost:631
> ListenStream=/var/run/cups/cups.sock
> Probably overkill, I admit.
> 
> > But it is in the past, so we can leave it at that.
> 
> Unless, of course, there's a lesson here for someone trying to get
> systemd to work.

There has been a bug in writing cupsd-systemd-listen.conf but not, as
far as I know, one which leaves it completely empty.

"ListenStream=/var/run/cups/cups.sock" is taken care of in cups.socket
so the line is superfluous.

> >> 3. ... Since systemd gives pretty good error messages, life got much
> >> easier I got to read them, by amending /etc/inittab by adding
> >> --noclear thus: 1:2345:respawn:/sbin/getty
> > /etc/inittab is not a file systemd looks at.
> 
> I know.  But systemd boot messages, along with those useful hints at
> where to find errors, vanish unless --noclear is added. Maybe there's
> a journalctl option that includes boot errors, but I haven't found it
> yet.
> 
> > You may want to read the thread which contains this post:
> > [🔎] 87bns2roy6.fsf@turtle.gmx.de">https://lists.debian.org/[🔎] 87bns2roy6.fsf@turtle.gmx.de
> 
> Yeah, that's the thread where I learned to set --noclear.  I put it in
> inittab, even though systemd has its own location, just because the
> option works from there.

I think you may be misunderstanding something. Systemd puts the
"--noclear" in getty@.service and never reads initttab. All it does is
clear the screen when a getty is started and a login prompt presented. I
cannot see how doing this affects anything shown by journalctrl.


Reply to: