Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Autologin not working again (Read 1037 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

[SOLVED] Autologin not working again

Hi ,

It seems that autologin is not working anymore (it was working before, but after I performed an upgrade it stopped working).

Re: Autologin not working again

Reply #1 –
Autologin how? Via agetty? If so, did you see the recent annoucement on the front page? The conf file location moved.

Re: Autologin not working again

Reply #2 –
Also what happened to the amount of enabled gettys?

There used to be this line in `/etc/s6/rc.local':

# Which gettys to enable by default. Only tty2 - tty6 are valid (tty1 is provided
# by s6-linux-init). Note that every value must be separated by a space.
GETTYS="tty2 tty3 tty4"

I can no longer find it in /etc/s6/rc.local ...

Re: Autologin not working again

Reply #3 –
Wait so now we have "/etc/s6/s6.conf", "/etc/s6/rc.local", "/etc/s6/sv/someService/conf" and "/etc/s6/config/someService", why has it become this complicated?

Are all these files still relevant (all I'm seeing is a bunch of .pacsaves and .pacnews)? what's their priority order?

thanks

Re: Autologin not working again

Reply #4 –
Uh, did you read the above announcement? It answers this question.


Quote from: yolkano – on
Also what happened to the amount of enabled gettys?

There used to be this line in `/etc/s6/rc.local':

# Which gettys to enable by default. Only tty2 - tty6 are valid (tty1 is provided
# by s6-linux-init). Note that every value must be separated by a space.
GETTYS="tty2 tty3 tty4"

I can no longer find it in /etc/s6/rc.local ...


That variable was removed months ago (from s6.conf not rc.local) and also /etc/s6/s6.conf doesn't exist anymore. Again, read the announcement.

Re: [SOLVED] Autologin not working again

Reply #6 –
Quote from: yolkano – on
Wait so now we have "/etc/s6/s6.conf", "/etc/s6/rc.local", "/etc/s6/sv/someService/conf" and "/etc/s6/config/someService", why has it become this complicated?

Are all these files still relevant (all I'm seeing is a bunch of .pacsaves and .pacnews)? what's their priority order?

thanks
They serve different purposes and have different reasons for existing.

  • rc.local is a relict (or to put it better, a convention) from SysV init. It contains initialization specific to a local machine, which is not to be overwritten with upgrades. In suite66 you have an option of enabling it (I enabled it on my machine).
  • /etc/s6/s6.conf is (was) a global s6 configuration file.
  • /etc/s6/sv/someService/conf is the old convention of placing a configuration file specific to the service someService.
  • /etc/s6/config/someService is the new convention of placing a configuration file specific to the service someService.

You can see exactly when the change to the new naming convention was introduced, for example in the service syncthing-s6:

https://gitea.artixlinux.org/packagesS/syncthing-s6/blame/commit/f2ec6f516969d99607c4a57c2861489096a7624a/trunk/PKGBUILD#L14

New config file location:
https://gitea.artixlinux.org/packagesS/syncthing-s6/commit/7fd2e5c2807ba9f7a0711c33ddf9f35aad962dd3

Old config file location:
https://gitea.artixlinux.org/packagesS/syncthing-s6/commit/c75a6608e0f468d7b63ed40cf6d66ff7ecf217b6

Personally, I think the new naming convention makes more sense. All the configuration files are in one convenient location, as opposed to chasing them in individual subdirectories.

Similar convention exists in suite66.

Re: [SOLVED] Autologin not working again

Reply #7 –
Yeah, putting conf files in the source directories was a design mistake by me. I was originally copying how runit does it since it reads files from there, but that leads to package management issues. The s6-rc-compile hook will hard fail if directories in there do not have the appropriate files (type, run/contents/up depending, etc.). However conf files need to be put in the backup array so upgrades don't override user configs.

This creates a problem when a user tries to remove a service but has also made local changes to a user file. The type/run/etc. files are all removed but the conf.pacsave is left behind. This makes s6-rc-compile (correctly) fail because the directory is not a proper source directory for s6-rc. So to workaround this, the .install files had a bunch of rm -rf lines to make sure these directories were gone on uninstalls.

That's just one bad hack though. It's better to just shove the conf files all in some other place so you don't have to worry about any of this. Ideally, /etc/s6/sv has strictly only s6-rc relevant files. Hence, the change.