Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #157303 > unrolled thread

Getting a serial console to work on Jessie

Back to article view | Back to linux.debian.user

Contents

  Getting a serial console to work on Jessie David Parker <dparker@utica.edu> - 2015-09-01 18:20 +0200
    Re: Getting a serial console to work on Jessie Michael Biebl <biebl@debian.org> - 2015-09-01 19:20 +0200
      Re: Getting a serial console to work on Jessie Michael Biebl <biebl@debian.org> - 2015-09-01 21:00 +0200
        Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-01 22:00 +0200
    Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-02 00:50 +0200
      Re: Getting a serial console to work on Jessie David Parker <dparker@utica.edu> - 2015-09-02 16:10 +0200
        Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-02 21:10 +0200
          Re: Getting a serial console to work on Jessie Eike Lantzsch <zp6cge@gmx.net> - 2015-09-02 23:10 +0200
            Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-02 23:40 +0200
              Re: Getting a serial console to work on Jessie Eike Lantzsch <zp6cge@gmx.net> - 2015-09-02 23:50 +0200
              Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-03 03:20 +0200
                Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-03 09:50 +0200
                Re: Getting a serial console to work on Jessie Michael Biebl <biebl@debian.org> - 2015-09-04 02:10 +0200
                  Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-04 15:20 +0200
              Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-06 21:10 +0200
                Re: Getting a serial console to work on Jessie Michael Biebl <biebl@debian.org> - 2015-09-06 22:10 +0200
                  Re: Getting a serial console to work on Jessie Christian Seiler <christian@iwakd.de> - 2015-09-06 23:10 +0200
                  Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-07 04:00 +0200
                    Re: Getting a serial console to work on Jessie David Parker <dparker@utica.edu> - 2015-09-07 16:00 +0200
                      Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-07 16:50 +0200
                        Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-07 17:50 +0200
                          Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-08 01:30 +0200
                            Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-08 14:10 +0200
                        Re: Getting a serial console to work on Jessie Bob Bernstein <bob@fanatick.org> - 2015-09-08 00:30 +0200
                          Re: Getting a serial console to work on Jessie Stephen Powell <zlinuxman@wowway.com> - 2015-09-08 13:20 +0200
                Re: Getting a serial console to work on Jessie Sven Hartge <sven@svenhartge.de> - 2015-09-06 22:10 +0200

Page 1 of 2  [1] 2  Next page →

#157303 — Getting a serial console to work on Jessie

[Multipart message — attachments visible in raw view] — view raw

Hello,

I have a bunch of Debian Wheezy servers set up with the console available
via the serial port.  Generally, I just add this line to /etc/inittab:

    co:2345:respawn:/sbin/getty -L ttyS0 9600 vt102

And then run "kill -HUP 1" and the serial console works (I could also use
"telinit q" or "init q" instead of kill -HUP").  I just did this on a
Wheezy server to make sure, and checked the getty processes prior to making
the change:

# ps -ef | grep getty
root      2660     1  0 Jul24 tty1     00:00:00 /sbin/getty 38400 tty1
root      2661     1  0 Jul24 tty2     00:00:00 /sbin/getty 38400 tty2
root      2662     1  0 Jul24 tty3     00:00:00 /sbin/getty 38400 tty3
root      2663     1  0 Jul24 tty4     00:00:00 /sbin/getty 38400 tty4
root      2664     1  0 Jul24 tty5     00:00:00 /sbin/getty 38400 tty5
root      2665     1  0 Jul24 tty6     00:00:00 /sbin/getty 38400 tty6

And then after:

# ps -ef | grep getty
root      2660     1  0 Jul24 tty1     00:00:00 /sbin/getty 38400 tty1
root      2661     1  0 Jul24 tty2     00:00:00 /sbin/getty 38400 tty2
root      2662     1  0 Jul24 tty3     00:00:00 /sbin/getty 38400 tty3
root      2663     1  0 Jul24 tty4     00:00:00 /sbin/getty 38400 tty4
root      2664     1  0 Jul24 tty5     00:00:00 /sbin/getty 38400 tty5
root      2665     1  0 Jul24 tty6     00:00:00 /sbin/getty 38400 tty6
root     31705     1  0 11:33 ttyS0    00:00:00 /sbin/getty -L ttyS0 9600
vt102

And there's the getty on ttyS0 as expected.

That's all fine and good, but when I try to do this on my desktop PC
running Jessie, it doesn't work.  My PC is running an X server, Gnome,
etc., whereas the servers are not.  Also, on Wheezy, /sbin/getty and
/sbin/agetty seem to be two copies of the same file, wheras on Jessie,
/sbin/getty is a symlink to /sbin/agetty.

The PC is using the default /etc/inittab file.  When I check the list of
getty processes after a clean reboot, there's only this:

# ps -ef | grep getty
root      2092     1  0 11:50 tty1     00:00:00 /sbin/agetty --noclear tty1
linux

If I access the virtual consoles via CTRL-ALT-F1, etc., they show up in the
process list only after they have been accessed:

# ps -ef | grep getty
root      2092     1  0 11:50 tty1     00:00:00 /sbin/agetty --noclear tty1
linux
root      2998     1  0 11:56 tty2     00:00:00 /sbin/agetty --noclear tty2
linux
root      3001     1  0 11:56 tty3     00:00:00 /sbin/agetty --noclear tty3
linux

And still not in the same way that they appear on Wheezy ("/sbin/getty
38400 tty1", etc.).  If I add the line for the serial console to
/etc/inittab and reload the init deamon, or even reboot the PC, it simply
does nothing.  No getty process shows up on ttyS0, and no serial console is
available.

I know the serial port itself works, because I can connect to it from my
laptop, then do "screen /dev/ttyS0 9600" on the PC and see characters in
the screen session as I type them on the laptop.  So the serial port works,
and I/O seems to work, but I can't seem to start a persistent getty process
on that port and access the console through it.

Any ideas or suggestions are very much appreciated.

    Thanks!
    Dave

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [next] | [standalone]

#157306

[Multipart message — attachments visible in raw view] — view raw

Am 01.09.2015 um 18:13 schrieb David Parker:
> And still not in the same way that they appear on Wheezy ("/sbin/getty
> 38400 tty1", etc.).  If I add the line for the serial console to
> /etc/inittab and reload the init deamon, or even reboot the PC, it simply
> does nothing.  No getty process shows up on ttyS0, and no serial console is
> available.
> 
> I know the serial port itself works, because I can connect to it from my
> laptop, then do "screen /dev/ttyS0 9600" on the PC and see characters in
> the screen session as I type them on the laptop.  So the serial port works,
> and I/O seems to work, but I can't seem to start a persistent getty process
> on that port and access the console through it.

Reading your description, I assume you have systemd-sysv installed and
systemd is your active PID 1. systemd no longer reads /etc/inittab, so
any configuration changes there don't have any effect.

getty's are started on demand by systemd-logind [1] and then show up as
instances of getty@.service, e.g. getty@tty1.service.
If you wanted to see your currently running instances you could use
something like "systemctl list-units | grep getty@"

For getty's on a serial console, there is a serial-getty@.service unit,
which is also started on demand.

If for some reason you want to enable those units statically, i.e.
always start them during boot, then this is no problem either.
Run
systemctl enable getty@tty2.service
systemctl enable getty@tty3.service
..
systemctl enable serial-getty@ttyS0.service
etc.

Regards,
Michael




[1] see man logind.conf -> NAutoVTs



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#157311

[Multipart message — attachments visible in raw view] — view raw

Am 01.09.2015 um 19:31 schrieb David Parker:
> Thanks, Michael!  That was indeed the problem.  I
> copied /lib/systemd/system/serial-getty@.service to /etc/systemd/system,
> edited it to use the correct baud rate and terminal type, and then ran
> "systsystemctl start serial-getty@ttyS0.service" and it worked like a charm.

Glad we could solve your problem this easily.

As for overriding the system provided service files, I usually recommend
to use drop-ins, i.e. creating a
/etc/systemd/system/foo.service.d/my_custom_config.conf
This way you only need to override what you are actually interested in.

You can use drop-ins for template files itself or for instances itself:

/etc/systemd/system/serial-getty@.service.d/my_stuff.conf
-> will apply to all instances of serial-getty@

/etc/systemd/system/serial-getty@ttyS0.service.d/my_stuff.conf
-> only applies to serial-getty@ttyS0.service.d

> Guess I need to get with the times and learn systemd!

Welcome!

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#157315

Michael Biebl <biebl@debian.org> wrote:

> As for overriding the system provided service files, I usually recommend
> to use drop-ins, i.e. creating a
> /etc/systemd/system/foo.service.d/my_custom_config.conf
> This way you only need to override what you are actually interested in.

Users of Testing/Stretch or Unstable/Sid can use systemctl directly:

# systemctl edit foo.service

and this will create the override directory in the right place and open
a new file in your preferred editor. Very handy.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#157319

On Tue, 01 Sep 2015 12:13:56 -0400 (EDT), David Parker wrote:
> 
> I have a bunch of Debian Wheezy servers set up with the console available
> via the serial port.  Generally, I just add this line to /etc/inittab:
> ...
> That's all fine and good, but when I try to do this on my desktop PC
> running Jessie, it doesn't work.
> ...

I realize that you already have a resolution to your problem, but if you're
using serial consoles on Debian Linux, you might find some useful information here:

   http://users.wowway.com/~zlinuxman/serial.htm

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#157340

[Multipart message — attachments visible in raw view] — view raw

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

Thanks!

On Tue, Sep 1, 2015 at 6:43 PM, Stephen Powell <zlinuxman@wowway.com> wrote:

> On Tue, 01 Sep 2015 12:13:56 -0400 (EDT), David Parker wrote:
> >
> > I have a bunch of Debian Wheezy servers set up with the console available
> > via the serial port.  Generally, I just add this line to /etc/inittab:
> > ...
> > That's all fine and good, but when I try to do this on my desktop PC
> > running Jessie, it doesn't work.
> > ...
>
> I realize that you already have a resolution to your problem, but if you're
> using serial consoles on Debian Linux, you might find some useful
> information here:
>
>    http://users.wowway.com/~zlinuxman/serial.htm
>
> --
>   .''`.     Stephen Powell    <zlinuxman@wowway.com>
>  : :'  :
>  `. `'`
>    `-
>
>


-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [prev] | [next] | [standalone]

#157346

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.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#157347

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.
> 
> Grüße,
> Sven.

Sven,

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/?

Cheers and thank you
Eike

[toc] | [prev] | [next] | [standalone]

#157348

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.

[toc] | [prev] | [next] | [standalone]

#157349

On Wednesday 02 September 2015 23:29:40 Sven Hartge wrote:
> 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 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.

[toc] | [prev] | [next] | [standalone]

#157352

On Wed, 02 Sep 2015 17:29:40 -0400 (EDT), Sven Hartge wrote:
> ...
> 
> 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.

Thanks for the tip, Sven.  I'll try to incorporate your suggestion in the
next revision of my serial console document.  With luck, I may get to it
this weekend.

Do you know a similar technique for overriding individual udev rules in
a system-provided rules file?

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#157360

Stephen Powell <zlinuxman@wowway.com> wrote:

> Do you know a similar technique for overriding individual udev rules in
> a system-provided rules file?

Ah, that part is a white spot on my (mind)map.

Maybe Michael Biebl can provide more input, as one of the DDs
maintaining systemd and udev he should be able to provide more input.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#157389

[Multipart message — attachments visible in raw view] — view raw

Am 03.09.2015 um 03:14 schrieb Stephen Powell:
> Do you know a similar technique for overriding individual udev rules in
> a system-provided rules file?

A similar mechanism exists for udev rules file.
See man 7 udev -> "RULES FILES"


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#157397

On Thu, 03 Sep 2015 20:06:43 -0400 (EDT), Michael Biebl wrote:
> 
> Am 03.09.2015 um 03:14 schrieb Stephen Powell:
>> Do you know a similar technique for overriding individual udev rules in
>> a system-provided rules file?
> 
> A similar mechanism exists for udev rules file.
> See man 7 udev -> "RULES FILES"

I do know about user-written rules files, and I have used them in
the past, but for some reason it never occurred to me to use a
user-written rule to change an already-applied system-written rule.
Duh!  Why didn't I think of that?  How embarrassing!  Thanks.

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#157468

On Wed, 02 Sep 2015 17:29:40 -0400 (EDT), Sven Hartge wrote:
> 
> 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.
> 

Well, Sven, that's a nice idea, but I can't get it to work for me in this
situation.  I issued

   systemctl edit serial-getty@ttyS0.service

and placed the following two lines into the file:

   [Service]
   ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151

But when I restart the service, I get the following error:

systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.

I want to override "ExecStart", not add a new one.  What am I doing wrong?

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#157474

[Multipart message — attachments visible in raw view] — view raw

Am 06.09.2015 um 21:04 schrieb Stephen Powell:

>    [Service]
>    ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
> 
> But when I restart the service, I get the following error:
> 
> systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
> 
> I want to override "ExecStart", not add a new one.  What am I doing wrong?

By default, systemd will simply merge all drop-ins.
In your case, ExecStart is a setting which can not be specified more
then once. So you need to "clear" it first. The following should do the
trick:

[Service]
ExecStart=
ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151


The "ExecStart=" resets the existing setting.

See also man 5 systemd.unit , "Example 2. Overriding vendor settings":

>        Note that for drop-in files, if one wants to remove entries from a setting that is
>        parsed as a list (and is not a dependency), such as ConditionPathExists= (or e.g.
>        ExecStart= in service units), one needs to first clear the list before re-adding all
>        entries except the one that is to be removed. See below for an example.



Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#157485

[Multipart message — attachments visible in raw view] — view raw

Hello Michael,

On 09/06/2015 10:06 PM, Michael Biebl wrote:
> See also man 5 systemd.unit , "Example 2. Overriding vendor settings":
> 
>>        Note that for drop-in files, if one wants to remove entries from a setting that is
>>        parsed as a list (and is not a dependency), such as ConditionPathExists= (or e.g.
>>        ExecStart= in service units), one needs to first clear the list before re-adding all
>>        entries except the one that is to be removed. See below for an example.

Note that that passage in the man page is only present in versions
of systemd beginning with either 216 or 217, while Jessie only has
systemd 215, and thus the man pages in Jessie don't contain that
text yet.

Christian

[toc] | [prev] | [next] | [standalone]

#157498

On Sun, 06 Sep 2015 16:06:35 -0400 (EDT), Michael Biebl wrote:
> Am 06.09.2015 um 21:04 schrieb Stephen Powell:
>> ... 
>>    [Service]
>>    ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
>> 
>> But when I restart the service, I get the following error:
>> 
>> systemd[1]: serial-getty@ttyS0.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
>> 
>> I want to override "ExecStart", not add a new one.  What am I doing wrong?
> 
> By default, systemd will simply merge all drop-ins.
> In your case, ExecStart is a setting which can not be specified more
> then once. So you need to "clear" it first. The following should do the
> trick:
> 
> [Service]
> ExecStart=
> ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
> 
> 
> The "ExecStart=" resets the existing setting.
> 
> ...

That works.  This is definitely a better solution than copying
serial-getty@.service from /lib/systemd/system to /etc/systemd/system
and then editing the copy in /etc/systemd/system to change the ExecStart
value.  It is better for two reasons:

(1) When systemd is serviced, I don't need to recopy and reedit the file
in order to keep my changes synced up with changes to the file made by
service to systemd.

(2) It allows two different serial ports to have different ExecStart values
for two different terminal types, for example.  Using my original method,
both serial ports would be locked into the same terminal type.

I shall change my documentation accordingly.  Thanks, Michael and Sven
for your suggestions and help.

Regards,

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#157518

[Multipart message — attachments visible in raw view] — view raw

Hello,

Thanks for all the clarification.  I now find myself in need of doing this
again on another server running Jessie, and I just want to make sure I'm
clear on what the best procedure is.  As I understand it, I should
copy /lib/systemd/system/serial-getty@.service to
/etc/systemd/system/serial-getty@ttyS0.service, then
edit serial-getty@ttyS0.service to include the following:

    [Service]
    ExecStart=
    ExecStart=-/sbin/agetty -8 --noclear %I 9600 vt100
    ...

Is that correct?

    Thanks!
    Dave

On Sun, Sep 6, 2015 at 9:52 PM, Stephen Powell <zlinuxman@wowway.com> wrote:

> On Sun, 06 Sep 2015 16:06:35 -0400 (EDT), Michael Biebl wrote:
> > Am 06.09.2015 um 21:04 schrieb Stephen Powell:
> >> ...
> >>    [Service]
> >>    ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
> >>
> >> But when I restart the service, I get the following error:
> >>
> >> systemd[1]: serial-getty@ttyS0.service: Service has more than one
> ExecStart= setting, which is only allowed for Type=oneshot services.
> Refusing.
> >>
> >> I want to override "ExecStart", not add a new one.  What am I doing
> wrong?
> >
> > By default, systemd will simply merge all drop-ins.
> > In your case, ExecStart is a setting which can not be specified more
> > then once. So you need to "clear" it first. The following should do the
> > trick:
> >
> > [Service]
> > ExecStart=
> > ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
> >
> >
> > The "ExecStart=" resets the existing setting.
> >
> > ...
>
> That works.  This is definitely a better solution than copying
> serial-getty@.service from /lib/systemd/system to /etc/systemd/system
> and then editing the copy in /etc/systemd/system to change the ExecStart
> value.  It is better for two reasons:
>
> (1) When systemd is serviced, I don't need to recopy and reedit the file
> in order to keep my changes synced up with changes to the file made by
> service to systemd.
>
> (2) It allows two different serial ports to have different ExecStart values
> for two different terminal types, for example.  Using my original method,
> both serial ports would be locked into the same terminal type.
>
> I shall change my documentation accordingly.  Thanks, Michael and Sven
> for your suggestions and help.
>
> Regards,
>
> --
>   .''`.     Stephen Powell    <zlinuxman@wowway.com>
>  : :'  :
>  `. `'`
>    `-
>
>


-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [prev] | [next] | [standalone]

#157520

On Mon, 07 Sep 2015 09:56:12 -0400 (EDT), David Parker wrote:
> 
> Thanks for all the clarification.  I now find myself in need of doing this
> again on another server running Jessie, and I just want to make sure I'm
> clear on what the best procedure is.
> ...

I just finished updating my web page to reflect the new information.
Once again, go to

   http://users.wowway.com/~zlinuxman/serial.htm

Make sure that you press F5 to refresh the page (or whatever your browser's
refresh key is), since an old version of the page may be in your browser's
cache if you've looked at it recently.  Then read the new instructions for
enabling a serial terminal under systemd.  If you then have any questions, 
please post a follow-up.

Sven and Michael, please review this also and correct me if I made a mistake.
I do not want to publish bad advice.

Regards,

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web