Re: Getting a serial console to work on Jessie

[Sven Hartge <sven@svenhartge.de>]

Eike Lantzsch <zp6cge@gmx.net> wrote:
> On Wednesday 02 September 2015 20:58:29 Sven Hartge wrote:
>> David Parker <dparker@utica.edu> wrote:

>>> Thanks.  I actually found that site in a Google search, and it's where
>>> I found the tip on copying the
>>> /lib/systemd/system/serial-getty@.service template file to customize
>>> the baud rate, etc.  Specifically, I found the info I needed at:
>>> 
>>> http://users.wowway.com/~zlinuxman/serial.htm#Systemd

>> Well, the advise given on that website is wrong, or at least suboptimal,
>> because it totally overrides the system configuration instead of only
>> ammending it, which preserves future changes to the system file.

> May I kindly ask you to elaborate on that? Please, because I'm
> interested too.  Where is better information to be had or can you at
> least point out where exactly one needs to start to iron out the
> failings of the mentioned document?

> I'm not exactly understanding what you mean by "preserves future
> changes to the system file". I always had the impression that my
> changes to config files can either be overwritten by updates (bad),
> merged into the newer config files (difficult without administrator
> intervention) or left alone and new config files installed as
> "release" files, or the new files installed and the old ones backed-up
> as *.pkg-old.

> Preserves seem always to be from the past yield, can the future be
> preserved?

> Also, what do you mean exactly by "system file" in the case of systemd
> - those in /lib/systemd/system/?

Please excuse this misunderstanding, my native language got the better
of me in that case. "system file" means "the one from the package". 

Now, the explanation:

systemd provides a way to override or ammend parts of units. You do this
by creating a directory structure like this:

  /etc/systemd/system/foo.service.d/

This will contain all additional config files for the unit
"foo.service".

For example: I don't want systemd to clear the screen on tty1 when it
starts a new getty. The unit responsible for this TTY is named
"getty@tty1.service". I created

  /etc/systemd/system/getty@tty1.service.d

and put a file named "noclear.conf" in it with this content:

,----
| [Service]
| TTYVTDisallocate=no
`----

This will add (or change) the TTYVTDisallocate option to the unit.
The original path to the unit is "/lib/systemd/system/getty@.service"
and if this file is changed by a package update, its new content will be
used.

If I had copied the _whole_ file to /etc/systemd/system then the new
version of the unit in "/lib/systemd/system" would never get used, just
my own version. This may be fine but may also cause major problems in
the future.

This is what I meant by "future changes are preserved" as you don't just
clobber them with your own full copy of the (then) old unit file.

You can check which files are used for a unit with systemctl:

  systemctl cat getty@tty1.service

and you will get an output like this (a bit shortened by me for this
mail):

,----
| # /lib/systemd/system/getty@.service
|
| [Unit]
| Description=Getty on %I
| Documentation=man:agetty(8) man:systemd-getty-generator(8)
| Documentation=http://0pointer.de/blog/projects/serial-console.html
| After=systemd-user-sessions.service plymouth-quit-wait.service
| <<----8<--->>
| [Service]
| # the VT is cleared by TTYVTDisallocate
| TTYVTDisallocate=yes
| KillMode=process
| IgnoreSIGPIPE=no
| SendSIGHUP=yes
|
| # Unset locale for the console getty since the console has problems
| # displaying some internationalized messages.
| Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
| LC_MONETARY= LC_MESSAGES= LC_
|
| [Install]
| WantedBy=getty.target
| DefaultInstance=tty1
|
| # /etc/systemd/system/getty@tty1.service.d/noclear.conf
| [Service]
| TTYVTDisallocate=no
`----

Note how my own addition shows up at the bottom.

Also note how a later "TTYVTDisallocate=no" overrides the earlier
"TTYVTDisallocate=yes".

You can also use "systemd-delta" to check which units have overrides or
extentions. And with newer systemd (Stretch and newer) you can even use
"systemctl edit unitname" and it will create the needed directory
structure in the correct place for you.

But you are also correct that this "override feature" is a bit different
than the normal proceedings during upgrades and dealing with
.dpkg-{old,new,dist}.

But it is the way systemd is designed and you can either work with it or
fight it every centimeter of the way.

I hope this explains my thoughts.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.