On Wednesday 02 September 2015 23:29:40 Sven Hartge wrote: > Eike Lantzsch <zp6...@gmx.net> wrote: > > On Wednesday 02 September 2015 20:58:29 Sven Hartge wrote: > >> David Parker <dpar...@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 sure won't fight anything I do not thoroughly understand. That's always a means to lose. > > I hope this explains my thoughts. Very well. > > Grüße, > Sven.
Thank you Sven! This clears things up and sends me further[*] up the ladder to understand systemd. Herzliche Grüße Eike * I sincerely thought about writing "farther" but this ladder is figurative and fits in more with the idea of time and effort.
