I don’t want the system to shutdown in the middle of the upgrade, but I’ve already started the upgrade in the GUI.
Is there a better way, maybe involving the apt lock?
EDIT: Thank you for all the helpful suggestions. Hopefully this helps the next person. My upgrade actually finished on its own while I was posting. 😂
If you started it in the terminal and are using bash hit “ctrl+z” to put the process to sleep and get your shell back, then use “fg ; sudo shutdown - c 1”. “fg” puts a job back in the foreground.
Use “help fg” for more information. You also have “bg” (background) and “kill %1” to kill a specific job.
There’s more, but I forget how to list tasks (maybe “tasks”?)“jobs” to list jobs.I did not know about the fg; (next command)
That’s amazing! So cool.
@onlinepersona @sem “jobs”
Your GUI tool is probably running
aptunder the hood. You can find the PID of theaptprocess and do something like this:waitpid <pid> && poweroffIf you are afraid it has something to do after the
aptprocess dies, you can add some additional arbitrary delay like this:waitpid <pid> && sleep <seconds> && poweroff@sem@piefed.blahaj.zone
Alternatively, you can wait until there are no processes matching a regex with
pidwait <regex>.
If you can run sudo without a password, you could do something like:
sudo apt update && sudo shutdown -h 5
The && operator will only execute the next instruction if the first returns a zero (no error) code upon completion.
Then just run that command about every 5 minutes and it’ll shut down once the install dishes, which releases the lock so apt upgrade can go (presuming apt upgrade needs the lock - I don’t remember if it does.)
Alternatively, you could ps auxw | grep for the pid of the upgrade. Then keep running a ps for that pid, and once you don’t see it, shutdown.
If you can run sudo without a password, you could do something like:
There’s no need for password-less sudo. Instead, you can use
bash -cto run a set of commands via sudo:sudo bash -c "while true;do apt update && shutdown -h 5; sleep 5m;done"Why do you need the
while true?Otherwise it’d only check for the lock once. It’d run, go “oops, apt is in use!”, and quit, and never check again.
The loop here is what makes it check again at all.
– Frost
I suppose it would be useful for flakey internet connection, then your update would restart 5 minutes after losing the connection. It surely has a yucky aftertaste, though.
No, the idea was that
apt updatewould keep failing while the system upgrade was running (and holding the lock):$ apt update E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1704856 (apt) N: Be aware that removing the lock file is not a solution and may break your system. E: Unable to lock directory /var/lib/apt/lists/But there are better ways of waiting for a process to finish, that other people have shared
Nice. Sudo once, then run the shell until done. Much more elegant.
I was today years old when I learned that
&&on the command line is not just a after this do this shortcut, but rather how it is used literally everywhere else sort of thing. I am not a very bright knife in the shed.My daily epiphany: the commenter here who showed me:
^z fg; command
I didn’t know you could append a command to fg and essentially chain to an already built process! Awesome.
From the old world of UNIX: Using UNIX is always a series of small epiphanies. You will keep finding new options, tools, ideas, and shell snippets that will continually expand your skills.
I’ve been using UNIX and then Linux since 1996. I find new little bits any time I go look. It’s a lifetime of curiosity awaiting for you.
after this do this
This would be
;, as inecho 'after this'; echo 'do this'.||has a similar “oh that’s how it works in other places” behavior. I didn’t realize that for a while.Yeah I feel pretty silly. I have a good amount of programming experience too, which certainly amplifies the whoosh lol
Mint’s updater also does Flatpak updates not just apt.
The second part with the pid would cover both.
I forget about the flatpack stuff. That’s a great point.
☝️☝️☝️
Better run a terminal command, which you can execute a command right after the job is done. Something like
upgrade && shutdown(off course you need to fill the full command). If you can, I would stop the upgrade process in the GUI and run it as a command instead for full control. Next time you just run the command.This should be the highest rated answer. The others are complete overkill.
In fact if you really don’t care whether the upgrade was successful it could even be
upgrade ; shutdown.The context of the question was what could you do if you’ve already started the upgrade in the GUI. I can accept that it would have been better to upgrade via the terminal if i wanted to shutdown after, but the situation i was in was waiting for the gui update. So this wouldn’t be my highest rated answer, even if it is true.
Can’t you stop the upgrade process from the GUI?
I hadn’t thought of that. Can pressing cancel also leave the system in a broken state, or is it safe?
If you are not sure, then its best to leave it run. My “assumption” would be that it is safe to cancel during the download period. I am actually not familiar how Linux Mint GUI operates, as I am using the upgrade and update commands on an Archlinux* system in the terminal. So I can see exactly what it is doing, and when it enters into installation phase after downloading all necessary packages. During installation I wouldn’t cancel the process. My suggestion was for you to look into.
*EndeavourOS
Edit: Typo
Linux Mint uses apt for the regular system stuff.
with apt, canceling during the download phase is totally safe.
canceling during the install phase is ALSO fairly safe. apt tries to make sure you’re never in an unbootable state if you have to cancel it, or your power cuts out, or whatever. It will, however, put apt into an “ack things are half-done!” state and you’ll need to run
sudo dpkg --configure -aafter you’re booted up, which is “finish installing the half-installed packages that apt was in the middle of doing before”.I think we’ve heard apt is better about this than most other package managers. So it might not be a good idea on EndeavourOS (Arch-based).
– Frost
