Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Starting Up at Boot #114

Open
javierdepascual opened this issue Nov 11, 2023 · 15 comments
Open

Starting Up at Boot #114

javierdepascual opened this issue Nov 11, 2023 · 15 comments

Comments

@javierdepascual
Copy link

I'm having issues understanding how to configure and operate with papertty terminal at boot. Specifically, I configured properly the services file and the start.sh file but I struggle to understand what to do here:

Then (read the unit file more carefully and) do the following steps:

sudo cp papertty.service /etc/systemd/system
sudo systemctl daemon-reload
sudo systemctl enable papertty

To disable the service:

sudo systemctl disable papertty

sudo systemctl stop papertty

This will incorporate the service with systemd and enables it. Before rebooting and trying it out, you may want to stop any other instances of the papertty.py and then see if the service works:

I'm not experience on these matters so it definitely is an issue on my end, but I hope someone can help me. I'm really close with my setup.

@mcarr823
Copy link
Collaborator

I didn't follow the guide, so the way I'm doing it isn't really the "proper" way.
(systemctl would be better, since that way you get a service which can be restarted and such)

What I did instead was create a crontab entry.
So as your pi user (or whatever you called your user) if you run
crontab -e
you'll open the crontab file.

Then down the bottom of the file on a new line I added
@reboot /home/pi/start.sh > /dev/null

I also created /home/pi/start.sh and ran
chmod +x /home/pi/start.sh
to make it executable (not sure if that step is necessary) and made its contents

#!/bin/bash
cd /home/pi
sudo papertty_venv/bin/papertty --driver IT8951 terminal --vcom 1460 --autofit --flipx --portrait --size 30 --font ubuntu-font-family-0.83/UbuntuMono-R.ttf

The command would need to be swapped with whatever you're currently running to start your panel, but otherwise it should work.

@javierdepascual
Copy link
Author

Thank you @mcarr823. I barely understand this but I'll try it. Couple of follow-up questions (sorry to bug you):

  1. Can I follow this command with another one inside the tty environment? What I mean is: I'd like to launch my vimwiki by default, use it as kind of menu, so to speak.
  2. Is there a way to launch commands when the computer shuts down? Ideally I'd like to upload/update all of my writing on the cloud somewhere. I also wonder if it can connect to a WiFi from the terminal and how would you do that (i.e. I'm at a coffeeshop, I finish my writing session, connect to the WiFi before I shut down the computer, and when I do my github with all my writing gets updated automatically.
  3. I've read in the docs that it's recommended to scrub the screen before and after using it for maximum lifespan, but I was wondering how this handles multiple commands (scrub is really slow and I would think both commands would run at the same time). I'm also having issues with the scrub command, as only 2/3s of the screen get scrubbed for some reason.

@mcarr823
Copy link
Collaborator

@javierdepascual

  1. you could use crontab for that, but not by itself. You would need to do some extra changes.
    For example, you could install tmux and run that by default, then have a crontab entry tell tmux to run vimwiki.
    eg. install tmux
    sudo apt install tmux
    then edit /home/pi/.bashrc and put
    [[ $TERM != "screen" ]] && exec tmux
    on a new line at the end. That would start tmux by default when you start a terminal session (including via SSH).
    Then you could add a crontab entry like
    @reboot sleep 5s && tmux send-keys -t "0:" "vimwiki" ENTER
    That would wait 5 seconds (need to wait for papertty to start), then send the "vimwiki" command to tmux session 0.

*Note: you should be very careful about editing .bashrc.
That will affect any terminal session you start, including over SSH, which is why I'd suggest tmux instead of running vimwiki directly.
After making any changes to .bashrc, keep your editor open and ssh onto the pi in a new terminal session to make sure it works okay.
If it doesn't, go back to your existing editor session that's open and remove your changes, then again try SSHing onto the device and confirm that it's okay now.

  1. you can, but it might require some trial and error to make sure that the command completes before shutting down.
    I currently show an image on my panel during shutdown, so the screen displays that image while it's off.
    I've done that by adding a script in /usr/lib/systemd/system-shutdown/.
    So I have /usr/lib/systemd/system-shutdown/Image.service
[Unit]
Description=Puts an image on screen

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/lib/systemd/system-shutdown/image.sh

[Install]
WantedBy=multi-user.target

and /lib/systemd/system-shutdown/image.sh

#!/bin/bash
cd /home/pi/
filename=./Pictures/sleep.png
papertty_venv/bin/papertty --driver IT8951 image --mirror --rotate 0 --stretch --image $filename
sleep 30

and of course the image ~/Pictures/sleep.png.

So you could do the same thing, but have the .sh file upload your writing somehow instead.

Personally I use syncthing for this https://syncthing.net/
The pi stores data locally, then syncs to my other computers (desktop pc, laptop, whatever happens to be on at the time) automatically whenever it can, rather than on shutdown.
But that requires a second computer to exist, have syncthing installed, and be turned on and accessible. Which may not always be the case.

As far as wifi goes, you should be able to do that from the command line.
I like to use nmtui for this, but that doesn't work well with papertty since it uses colors and highlighting.
nmcli should work fine though.
https://www.makeuseof.com/connect-to-wifi-with-nmcli/

  1. You can run scrub by default when starting up. I think you just pass in the --scrub argument when starting terminal mode.
    I don't know how important it is though. papertty already clears the screen on start. It's not the same as a proper scrub, but it's way faster.
    I think it's more important that the screen gets cleared on shutdown so it's displaying a (mostly) white screen. I believe it does this by default anyway.
    It might be worth doing a scrub every now and then, but I don't think it's practical to do it on every startup. It's just too slow.
    Maybe doing it on shutdown via a .sh file would be the way to go? You could do that after/while syncing your text to the cloud.

@javierdepascual
Copy link
Author

Wow @mcarr823, as always, extremely thankful for all your help. This does look extremely intimidating, but will try over the next few days and will keep you posted on my progress. I barely even understand the concepts, but by

That will affect any terminal session you start, including over SSH

It means that when I do these changes, after I reboot, they will execute automatically, right? Even though I won't see the desktop environment because I will only use the eink screen, will it be active over HDMI? Should I force my Raspbian OS to start on terminal on some way? I'm just scared I might turn my RPi into a brick.

Maybe doing it on shutdown via a .sh file would be the way to go? You could do that after/while syncing your text to the cloud.

Thing is when I exit papertty I can see a mild ghosting on my eink screen, and I can actually see the screen gets darker and darker as the session goes on. The only thing that does clean it up completely is when starting up papertty, and it does stay clean, so there's nothing that seems to damage the screen. So I just scrub from time to time, but for me it just reaches 2/3s of the screen and I don't know why. Anyway, I wonder, if you just have a pic as a background whenever you shut down, if I'm just paranoid and it's okay to leave the screen with the small ghosting artifacts from typing.

@javierdepascual
Copy link
Author

Ok @mcarr823 I got the crontab to run papertty on boot. Sorry, again, to bug you with a lot of questions:

keep your editor open and ssh onto the pi in a new terminal session to make sure it works okay.
If it doesn't, go back to your existing editor session that's open and remove your changes, then again try SSHing onto the device and confirm that it's okay now.

Since I run Raspbian OS Desktop, by "ssh onto the pi in a new terminal session" you mean open a new terminal window? That should work? Just making sure before I start messing around with .bashrc

  1. Since tty is only controlled by the keyboard if y press Ctrl + Alt + F1, is there any way to make it happen by default without me pressing the shortcut?
  2. Related to a previous question: is there a way to JUST run the terminal environment/SSH/whatever is called for this? and boot up the desktop GUI just if I need it?
  3. in the code you pasted, what does sleep 30 do? wait 30 seconds to go to sleep?

Thank you.

@mcarr823
Copy link
Collaborator

@javierdepascual Ah, so you're using a GUI. I just assumed you were using it without one.
In that case it makes starting programs a whole lot simpler. You don't need crontab or bashrc or anything.
On the other hand, it makes typing in papertty harder, since your input is going to the GUI instead of tty1 (which is why the Ctrl + Alt + F1 is needed).

I assume that raspberry pi OS has a "Startup Applications" program or something similar, like many linux distributions.
So for example, on Linux Mint I would run the "Startup Applications" program, then click on the plus icon and choose Custom Command.

Screenshot from 2023-11-17 08-08-38

Screenshot from 2023-11-17 08-09-50

That way you can specify programs the same way you would have from crontab.
eg. One could run your papertty command (or the .sh file containing your papertty command).
/home/pi/start.sh
Another could run tmux on tty 1 the way the papertty readme suggests running applications on a specific tty by using openvt (you might need to install this).

Let's say you have script /home/pi/tmux.sh which contains

#!/bin/bash
sudo openvt -fc 1 -- sudo -u pi tmux new -s main
tmux send-keys -t "main" "vimwiki" ENTER
tmux attach -t "main"

That would run tmux in a session called "main" on tty 1.
It would then send the command "vimwiki" to that session of tmux.
Finally, it would run "attach" to attach your current terminal window to that tmux session running on tty1.

If you can get that command to run automatically in a GUI terminal window, then the "attach" would mean that terminal window would send text straight to the tmux session running on tty1.
So even without switching tty sessions you would end up typing in the same tty as the papertty screen is running.

I think some desktop environments have a "run in terminal" checkbox when starting applications.
In other cases you can send the command as an argument to the terminal itself.
eg. Your startup application command might be something like
gnome-terminal -- /home/pi/tmux.sh
That opens gnome-terminal and tells it to run tmux.sh upon starting up.
So you'd have an open terminal window on your desktop running that command.

Note that all of the above is only going to work if you have auto-login enabled.
You also might need to use a different tty, depending on which one the raspberry pi desktop uses by default.
Raspberry pi os might use a different terminal than gnome-terminal as well.
Finally, the above opening of a terminal window and you typing into it directly without seeing the GUI depends on that window being in focus. So if your desktop environment pops up a window over the top of it (eg. a prompt to update the installed software) then you might find yourself not typing in the terminal window anymore, and nothing showing up on papertty.
So... there might be some trial and error involved.

It means that when I do these changes, after I reboot, they will execute automatically, right? Even though I won't see the desktop environment because I will only use the eink screen, will it be active over HDMI? Should I force my Raspbian OS to start on terminal on some way? I'm just scared I might turn my RPi into a brick.

Since you're using the desktop you won't need to modify bashrc. But fyi, changes to bashrc are immediate, no reboot needed. They'll happen as soon as you open a new terminal (but won't change any terminal sessions which are already open).
So usually I would modify bashrc in one terminal window, save it, then open a second terminal window to test it. If something is wrong with the second window, I'd go back to the first and revert the changes.

Your desktop would still be active over HDMI though. So even if your changes to bashrc broke something, you'd be able to go onto the desktop and fix it from there.
For anyone without a GUI, as long as you've got SSH access you could still get around the problem by running a command directly in SSH. eg.
ssh pi -t 'vi .bashrc'

Since I run Raspbian OS Desktop, by "ssh onto the pi in a new terminal session" you mean open a new terminal window? That should work? Just making sure before I start messing around with .bashrc

Since tty is only controlled by the keyboard if y press Ctrl + Alt + F1, is there any way to make it happen by default without me pressing the shortcut?
Related to a previous question: is there a way to JUST run the terminal environment/SSH/whatever is called for this? and boot up the desktop GUI just if I need it?
in the code you pasted, what does sleep 30 do? wait 30 seconds to go to sleep?

A new terminal session starts whenever you open a new terminal, a new terminal tab, or change to a new tty, or SSH onto a device.
I really just meant not to use the same terminal window you were using to modify bashrc, since the changes to bashrc will only take place for a new terminal started after those changes are made.
So if you have a terminal open and change bashrc, then open a new terminal window, only the new one will be affected.
And if the new one isn't working out so well... you still have the first window working correctly, which can be used to revert the changes.

The terminal environment stuff should run as long as it's in crontab or in your Startup Applications, as long as you've got automatic login turned on.
You can have your GUI there and just not use it. It'll still run, it just won't show unless you have your HDMI cable plugged in.
It's not a bad idea to keep the GUI just in case.

Regarding Ctrl + Alt + F1 and using the terminal instead of the desktop, I think running a terminal window with tmux on the desktop would be the safest solution.
By having tmux run on tty1, and having a terminal window on your desktop attach to that session, you end up sending keystrokes to that tty anyway. So there's no need to switch ttys with Ctrl + Alt.
That way you appear to be typing in tty1, but you actually have your GUI still in case you need it.
The only real problem is what I mentioned above, with other windows potentially popping up over the top of it and taking away the focus of your keyboard. Raspberry pi OS probably has "focus stealing prevention" or some other setting to prevent that from happening though.

@mcarr823
Copy link
Collaborator

in the code you pasted, what does sleep 30 do? wait 30 seconds to go to sleep?

I'm not sure if it's necessary. The shutdown script is something I copied from someone else.
It might be to give the panel time to display the image, or to make sure the process has time to finish.
But that's just a guess. Maybe it can be removed.

The image I use is just a fully white PNG file with black text of "SLEEP MODE" in the middle.
I made it with GIMP. Just a blank white canvas which is the same size as the waveshare panel, plus some text drawn on it.
Might be a good way to go since scrub isn't working for you.

@javierdepascual
Copy link
Author

Hi @mcarr823. I was hoping I could manage by myself the rest of the way, since you've been extremely helpful and I feel really bad bugging you again and again, but unfortunately it hasn't been the case. I can't crack a way to switch to tty1 and open vim automatically.

Thing is, my Raspbian OS/Raspberry Pi OS doesn't have any Startup Applications feature like the one you described. So I tried doing the following:

  1. After installing tmux I created a tmux.sh file with this code:
    #!/bin/bash sudo openvt -fc 1 -- sudo -u javierdepascual tmux new -s main tmux send-keys -t "main" "vim ~/writing/index.md" ENTER tmux attach -t "main"

I also changed the permissions with chmod as with the previous file.

  1. Added '[[ $TERM != "screen" ]] && exec tmux' to .bashrc
  2. Added '@reboot sleep 5s && /home/javierdepascual/tmux.sh > /dev/null' to 'crontab -e'

When rebooting nothing happens one way or the other. When executing the script by itself my tty displays a "main: missing or unsuitable terminal" message.

When choosing the "Execute in Terminal" option it actually works, though. So I guess there's something missing that I can't figure out.

Also, since changing the .bashrc file now my terminal displays that it's bash, which I don't care, it's fine, but it also displays the time at the bottom. I got worried it might impact my refresh rate and I don't know how to hide it, but now it's appearing on every terminal session, I guess since I'm working through tmux?

For the life of me I can't figure out if I have openvt installed. Normally it's pretty easy to Google how to install any utility but in this case I was completely lost. Maybe that's the issue.

Right now my RPi is at the workshop since I just got my keyboard and I have someone making a "laptop" case for it. I'll have it finished by next week and will be able to try again.

I was thinking maybe I could switch OS to something like Mint, the one you have installed, but if it impacts the work i've done so far I'd rather manage as it is.

Anyway, thank you for all the help so far and feel free to ignore me if I'm asking too much.

@mcarr823
Copy link
Collaborator

@javierdepascual It's no problem. I'd love to see what you end up with.
An e-ink laptop with a raspberry pi inside would be awesome.
3D print a laptop shell, add a hinge, put in an rpi + powerbank + low profile keyboard + e-ink panel.
Some DIY project like that would be great.

Thing is, my Raspbian OS/Raspberry Pi OS doesn't have any Startup Applications feature like the one you described.

Alright, I've just set up Raspberry Pi OS on a device here.
The desktop environment and session are pretty limited. I guess they're trying to keep it really simple.
It's missing a bunch of stuff I'd usually expect from a linux desktop.

I was thinking maybe I could switch OS to something like Mint, the one you have installed, but if it impacts the work i've done so far I'd rather manage as it is.

Linux Mint doesn't have an ARM64 version, but other distros would work.
eg. Ubuntu on ARM, or Manjaro on ARM.
Customizing Raspberry Pi OS is probably easier though, so let's go with that.

Here's what I wound up doing from a fresh install of Raspberry Pi OS.
I'm going to give 2 different (largely the same) approaches: "a" and "b".

Approach A

Involves using tmux to talk between tty1 and tty7.
So you can display a full desktop environment via HDMI while also displaying just the terminal on a waveshare panel.
This is probably more user-friendly, since you've got a desktop environment available as soon as you plug in your HDMI cable, and you don't need to remember the hotkey to switch ttys.
However, there are drawbacks. Since the desktop environment is running, that means the desktop environment can interfere.
eg. Popup windows, accidentally triggering something via hotkey, etc.
Those things can happen, but you wouldn't see them on the waveshare panel, so you wouldn't know what's wrong without plugging a monitor into the HDMI.

Approach B

Involves switching ttys.
So both a HDMI monitor and the waveshare panel would show only the terminal.
This prevents the above drawbacks, and you can still switch back to the desktop by pressing Ctrl + Alt + F7 as needed.

*In hindsight, approach "b" might actually work with crontab and the default raspberry pi desktop.
I didn't try doing that, but you could probably just do steps 10b and 11 with crontab for a similar result.
This might require openvt though (which is installed by default on raspberry pi os)

Anyway, I'll list the process for both below.
If the number has "a" after it, it's for the first approach.
If it has "b" after it, it's for the second.
If it has neither, it applies to both approaches.

1. Open a terminal

2a. Install tmux

sudo apt install tmux

3a. Create a script for running tmux

Just copy and paste the whole block into a terminal.

cat <<EOF > /home/pi/tmux.sh
#!/bin/bash
sudo openvt -fc 1 -- sudo -u pi tmux new -s main
sleep 2s
tmux send-keys -t "main" "echo testing" ENTER
tmux set -t "main" status off
tmux attach -t "main"
EOF
chmod +x /home/pi/tmux.sh

Replace "echo testing" with the command you want to run.
The "status off" command gets rid of the bar down the bottom with the session name and such.

4. Create a script for running papertty

Again, just copy and paste the whole block into a terminal.

cat <<EOF > /home/pi/start.sh
#!/bin/bash
cd /home/pi
sudo papertty_venv/bin/papertty --driver IT8951 terminal --autofit --portrait --size 30 --font ubuntu-font-family-0.83/UbuntuMono-R.ttf
EOF
chmod +x /home/pi/start.sh

Replace the papertty command with one that matches your desired driver, font, etc.

5. Install xfce

In your terminal run
sudo tasksel
then use the arrow keys to highlight xfce and press space to select it.
There should now be an asterisk next to it.
Press tab to highlight the OK option and press enter.
It'll take a while to install.

6. Update the login screen

sudo -e /etc/lightdm/lightdm.conf

Change "greeter-session" from "pi-greeter" to "lightdm-gtk-greeter"
Also comment out the autologin-session line.

greeter-session=lightdm-gtk-greeter
#autologin-session=something

Save the file.

Commenting out the autologin-session should make it autologin to your last used session.
Right now that is the default rpi desktop, but later it will be xfce.
So commenting that out now should make sure we don't reboot into an unexpected desktop.

lightdm-gtk-greeter is the default login screen for lightdm.
pi-greeter is the custom raspberry pi one, which doesn't support session switching (from what I can tell?)

7. Restart lightdm

sudo service lightdm restart
This should boot you back to the login screen.
The login screen will now look different than before.

8. Select xfce

Up the top right of the login screen there are now 3 icons.
From right to left they are: power, accessibility, session chooser.
Click on the session chooser icon and select "Xfce Session".
Now login. You should see the XFCE desktop instead of the default rpi one.

9a. Focus stealing prevention (optional)

Go to Applications -> Settings -> Window Manager Tweaks
Go to the Focus tab and check "Activate focus stealing prevention"
Also change "When a window raises itself" to "Do Nothing"
I think these will stop other programs from popping up over your terminal and interfering with what you're doing.

10a. Run tmux on login

Go to Applications -> Settings -> Session and Startup
Go to the Application Autostart tab.
Click on Add and give it details like

Name: Tmux
Description: Starts a tmux session on login
Command: xfce4-terminal --maximize -e /home/pi/tmux.sh
Trigger: on login

10b. Switch ttys on login

Go to Applications -> Settings -> Session and Startup
Go to the Application Autostart tab.
Click on Add and give it details like

Name: tty1
Description: Switch to tty1 on login
Command: sudo chvt 1
Trigger: on login

You MIGHT need to add a delay to this command so that papertty can run first.
I don't think that's required, but if it is, prefix the command with a delay.
eg.
sleep 3s && sudo chvt 1

11. Run papertty on login

Same as the previous step, click on Add and give it details like

Name: Papertty
Description: Starts papertty on login
Command: /home/pi/start.sh
Trigger: on login

And that should just about do it.
Note that I've skipped over the installation of papertty and the downloading of fonts.
Same with enabling SPI and other such things.

@mcarr823
Copy link
Collaborator

I've been working on automating the above process (and the entire setup of papertty) and ultimately created a repository here:

https://github.com/mcarr823/papertty-init

They're a couple of scripts you can run from a fresh install of Raspberry Pi OS (or Lite) which try to automate everything from start to finish, including enabling SPI, installing papertty's dependencies, running papertty on startup, and so on.

@javierdepascual
Copy link
Author

Hello @mcarr823 and, again, thank you for providing such a comprehensive and detailed solution. And happy new year! It's been a while since the last time I could work on this. I sent the RPi to a carpenter to work on a prototype case and he got delayed. Now I'm on vacation trying to finish everything so I can start writing!

I must say I encountered a bunch of issues with what you suggested, mainly because of my lack of Linux knowledge. But I'm learning a bit 🤪 I even forgot my login credentials when switching to xfce and had to remount the drive and change the password... anyway.

I tried both A and B methods. Here's my drawbacks:

  • Method A: Since it basically attaches the tmux session to the maximized terminal window, I never got vim to work properly. Basically the size of the terminal window will always be either bigger or smaller than the eink screen, so the rest of the real state is either hidden or there's a grid of dots and lines showing the limits of the screen. I don't know if there's a workaround for this issue. I tried not connecting any display through HDMI or removing the -maximize from the startup applications command. Neither of them fit the aspect ratio of the eink screen. The good thing about this method is that it launches my "index file" for my vimwiki.
  • Method B. So far it's my preferred method. It basically, as you said, reduces the chance of something interfering with the session and doesn't do any weird window-resizing shenanigans. The main drawback that I'm trying to solve now is running the vim command on startup. It's a small issue, to be honest, but I get obsessed about these details and I want everything to work as I intended. So here I was wondering if you could help me with this. I tried running openvt commands:
    sudo openvt -fc 1 vim index.md and sudo bash commands 'sudo bash -c 'vim index.md' > /dev/tty1'. Both of them seemed to work at first but they scrambled the input/output of tty1, basically rendering it unusable. Very weird.

So yeah, neither of them got it to work exactly as I expected, but I can't complain since I basically have it 95% done. I also started using syncthing (tremendous recommendation, thank you) so the file transfering to my main computers is solved.

Finally, I tried using your solution for a shutdown screensaver but for some reason it doesn't work. I had to change the permissions of the system-shutdown folder, but I don't know what I'm doing wrong.

Anyway, I also tried your papertty-init script to check how it works and it's pretty intuitive. The only thing that might generate issues is the problem with screen/terminal re-sizing that I mentioned for method A.

@mcarr823
Copy link
Collaborator

mcarr823 commented Jan 3, 2024

@javierdepascual I haven't tried this on a raspberry pi, but for Method B you could try something like
sudo chvt 1 && sleep 3s && sudo openvt -fc 1 vim index.md
I just ran that on a desktop PC running Ubuntu and it worked. I think the trick here is to make the openvt command run after you've switched to tty1, so you've already started a session there before it runs the command.

@javierdepascual
Copy link
Author

Unfortunately it doesn't work! I don't know why. It doesn't even switch to tty1. When I create a script to do the same commands it does switch to tty1 but it doesn't run the command to launch the index.

@javierdepascual
Copy link
Author

Ok, when writing a script with those commands it does work but the input becomes scrambled, basically I get a very weird vim window and whenever I write on it letters appear on various places around the screen. Very difficult to explain. It works but it goes wrong. Asking ChatGPT (lol) it suggested using tmux for that input, but I'm completely lost.

Another weird issue is happening when applying your shutdown service script. First of all, I tried placing it on the system-shutdown folder but it didn't work. Researching about systemd there's like 3 places where I can put my scripts, weirdly enough. I've decided placing them on the /lib/systemd/system folder.

Then, I used the systemctl enable img.service command to enable the systemd service. This is something you didn't mention but I saw when I was researching. I'm also using systemctl daemon-reload whenever I make any changes. For some weird reason, the service does work but only when I'm rebooting. When I actually shut down my computer, both from the GUI and the terminal, script doesn't launch. I've tried a couple of alternatives suggested by people on StackExchange but I'm totally lost to why it only works on reboot and not on shutdown.

I know you already helped a lot @mcarr823, I'll keep researching and try to solve both issues. I'm also writing this down in case someone else runs into these same issues.

@mcarr823
Copy link
Collaborator

mcarr823 commented Jan 5, 2024

Hmm, I see what you mean. It worked on my PC, but that's a rather different environment.
I tried it on a raspberry pi today with a fresh install and ran into the same problem you've described.

I suspect it's because tty1 already exists, which is why the "-f" (force) in the openvt command is needed.
I'm thinking that because openvt is being forced to run the command in a tty which is already open, rather than opening a new one (openvt's usual behavior) it's causing that weird input issue.

Opening a new vt seems to work, but only from a different tty. Not from the desktop.

I suspect the solution here might be to use a systemd script instead of using the desktop environment's autostart commands.

Regarding the shutdown script, I believe running "systemctl enable" isn't required if it's in the system-shutdown directory.
For reference this is the original post from someone else which I based that on https://www.reddit.com/r/raspberry_pi/comments/lgkzwb/comment/h1wfbvw/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants