You are not logged in.
Hello, I need to perform one task:
* install package which deploys only one shell script e.g. test.sh - as fast as possible.
* Somewhere in the process, launch the shell script test.sh which stays alive when the pacman finishes.
My approach is to install shell script and then execute it in post_install like this
post_install () {
# This will create fork and inside it a background proccess.
# Once forked proccess finishes, test.sh is reparented
# to init and should survive without pacman proccess.
( /some_path/test.sh & )
}
Reparenting to init works, but there is a problem. post_install becomes zombie process "bash" and pacman still waits until the test.sh terminates (several minutes in my case). How is it even possible? It looks something like this
-init
-test.sh # Launched from post_install and reparented to init
-pacman_parent
-pacman -U ....pkg.tar.xz
-bash -c '/tmp/.../.INSTALL'
-bash [zombie] # Created from post_install, stays until test.sh finishes
I also tried
( /some_path/test.sh & disown )
( setsid /some_path/test.sh & disown )
/some_path/test.sh & disown
but result is the same. When the same command is launched from bash, it works. I suspect it has something to do with a chroot, as I have only very basic knowledge of it and no idea why its needed for install scripts.
Thank you.
Last edited by forinti (2016-11-29 20:51:08)
Offline
Why are you using a pacman package for this? pacman's job is not to run a script on a computer -- its job is to install software.
Trying to evade pacman and its wise attempts to keep track of the post_install tasks (which are, after all, "post_install" tasks, hence the name "post_install") is a clear indication that you were incredibly wrong to try that in the first place.
As for your suspicion about a chroot, that is because install scripts and pacman hooks need to run in the context of the installation, which implies respecting the "-r, --root" flag.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thank you for advise! I think I now understand why the chroot is used. But i still don't have any idea, why is pacman waiting for a detached sub-sub process and this processes parent becomes a zombie. This does not happen when executed from a bash.
The reason for this weird approach is because I need to upgrade an embedded system which is bricked by design and I have only one way of access - transferring files to the user directory and executing "sudo pacman args...". I can choose any pacman arguments but cannot execute any other command like bash -c '...'.
So the script is supposed to do some before upgrade magic and then execute the normal pacman upgrade from a local repository. The call to the pacman cannot take more than a 1-2 s.
Offline
Thank you for advise! I think I now understand why the chroot is used. But i still don't have any idea, why is pacman waiting for a detached sub-sub process and this processes parent becomes a zombie. This does not happen when executed from a bash.
The reason for this weird approach is because I need to upgrade an embedded system which is bricked by design and I have only one way of access - transferring files to the user directory and executing "sudo pacman args...". I can choose any pacman arguments but cannot execute any other command like bash -c '...'.
So the script is supposed to do some before upgrade magic and then execute the normal pacman upgrade from a local repository. The call to the pacman cannot take more than a 1-2 s.
The "system is so badly designed that you're trying to break into it"? Who owns the system? Is it a web-host or an internet-of-thing?
Offline
The "system is so badly designed that you're trying to break into it"?
Yes, exactly
The system runs on an embedded device and it is not connected to the internet. It's controlled through our API from the PC with Windows. Because the customer upgraded to Windows 10, the communication over g_serial (buggy kernel module) is partly broken and we are replacing it with g_ether, which works nice.
Since there were some design errors in the older packages we need to run a magic script which converts old packages (based on groups) to a new system (based on meta packages). For my defense, the older packages was designed by my ex colleague .
So, this is the explanation why I'm doing it so wrong.
Offline
Randomly forbidding root except via pacman seems like a rather strange design, and clearly not for security...
But whyever it happened, maybe you could have the package install a systemd unit or something, and activate that in the post_install. The same or similar approach is used in the AUR package "mandb-ondemand" -- a pacman hook is triggered when manpages are installed, and instead of updating the mandb itself, which can sometimes take an awkward amount of time thereby holding up pacman, it launches a `systemctl --no-block start` job to do the work in the background while pacman frees itself.
Alternatively, because it sounds like you do have a shell just no root access (if not, why do you care how long pacman lingers?)... you could use pacman to install/configure sudo to let you in. By default, you should be able to use the /etc/sudoers.d/ drop-in directory.
And then you will be able to do things in a much more elegant manner.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thank you for ideas. I guess that the systemd unit is the cleanest way. I already thought about it but it was too tempting to just launch a shell script from installation and leave it running.
In fact, I could possibly use pre_install to export files from its code, start the unit and then make the installation fail... Because I don't really need to have this package installed on the system. The service will then removes itself when finished. I will try it tomorrow, and probably close the topic.
Thank you for help.
BTW, we have sudo, but I am unable to launch any shell commands. All I can do, is to transfer files to the device and set parameters for a pacman call. For example "-U magic.pkg.tar.xz". The security is not ideal but its not as terrible as it sounds because its mostly encrypted. And as for why the pacman call cannot linger... thats just one of many design fails. Fortunately everything should be solved with a future updates once we catch our technical debt
Offline
If your sudo command is limited to only pacman, how about in the post-install "visudo" - you'd think you'd be in root then - and then change the sudo configuration to allow any command as root? This is just a guess, I've never seen someone locked out of a system where they couldn't just boot off the install medium and chroot in and change what they want then.
Offline
To clarify. sudo is granted for user without a password for everything But since it is an embedded system of specific design (fail) and it is on the other side of the planet, the only system related communication is possible as:
PC --> serial link --> Embedded device --> Application --> sudo pacman <I am able to change only these parameters>
--> store files
No other system commands are accessible
Offline
So, I tested the singleshot systemd unit with --no-block start and it works great. So I guess my problem is solved. Thank you for your help.
Offline