[RESOLVED] Packages that won't install

[agatoi]

Good morning,
An issue on Windows 10 Education machines outside the domain.
The client installation (1.7.3.5) was done manually.
Upon shutdown, the packages do not install.
However, from the console of another computer, I can trigger updates and other installations.

Versions:
WAPT Server version: 1.7.3.5
WAPT Agent version: 1.7.3.5
WAPT Setup version: 1.7.3.5
WAPT Deploy version: 1.7.3.5
DB status: OK (1.7.3.2)


Below is a log file:

Code: Select all

Get packages index
u'235 paquet(s) dans le d\xe9p\xf4t\nLe syst\xe8me est \xe0 jour'
Get packages index
u'1 nouveau(x) paquet(s)\n236 paquet(s) dans le d\xe9p\xf4t\nPaquets \xe0 mettre \xe0 jour : admin-secret.stemarie-aizenay.local(=1),aiz-oembackgrounds(=1-2)'
2019-04-23 14:22:10,473 ERROR Traceback (most recent call last):

  File "C:\Program Files (x86)\wapt\lib\site-packages\rocket\worker.py", line 171, in run
    self.run_app(conn)

  File "C:\Program Files (x86)\wapt\lib\site-packages\rocket\methods\wsgi.py", line 245, in run_app
    output = self.app(environ, self.start_response)

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 2309, in __call__
    return self.wsgi_app(environ, start_response)

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 2295, in wsgi_app
    response = self.handle_exception(e)

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 1741, in handle_exception
    reraise(exc_type, exc_value, tb)

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 2292, in wsgi_app
    response = self.full_dispatch_request()

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 1815, in full_dispatch_request
    rv = self.handle_user_exception(e)

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 1718, in handle_user_exception
    reraise(exc_type, exc_value, tb)

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 1813, in full_dispatch_request
    rv = self.dispatch_request()

  File "C:\Program Files (x86)\wapt\lib\site-packages\flask\app.py", line 1799, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)

  File "C:\Program Files (x86)\wapt\waptservice\waptservice_common.py", line 102, in decorated
    return f(*args, **kwargs)

  File "C:\Program Files (x86)\wapt\waptservice\service.py", line 708, in upgrade
    wapt().update()

  File "C:\Program Files (x86)\wapt\common.py", line 4181, in update
    self._update_repos_list(force=force,filter_on_host_cap=filter_on_host_cap)

  File "C:\Program Files (x86)\wapt\common.py", line 4136, in _update_repos_list
    self.waptdb.db.execute('delete from wapt_package where repo not in (%s)' % (','.join('"%s"'% r.name for r in self.repositories)))

OperationalError: database is locked

2019-04-23 14:22:11,342 ERROR Traceback (most recent call last):
  File "C:\Program Files (x86)\wapt\lib\site-packages\rocket\main.py", line 144, in start
    time.sleep(THREAD_STOP_CHECK_INTERVAL)
IOError: [Errno 4] Interrupted function call

[htouvet]

Hello,
I suspect a conflict between waptservice and wapt-get.
When stopped, the waptexit application attempts to trigger the upgrade via waptservice.
If waptservice doesn't respond (quickly enough...), it tries to launch the upgrade directly using the wapt-get upgrade command (possible because it's running in the system account).

In your case, it's likely that the upgrade task is indeed launched but returns control to waptexit too late, and that simultaneously, wapt-get upgrade, which was mistakenly launched in parallel, is locking the database.

You should try with wapt 1.7.4 (release candidate), as waptexit's behavior has been changed. (https://wapt.tranquil.it/wapt/releases/wapt-1.7.4-rc1/ )
Specifically, waptservice returns control to waptexit before calculating the updates to apply, thus reducing the probability of a timeout.

[agatoi]

Thanks for the info.
My server is running Debian 9.8 (64-bit)
Which ".deb" file should I use?
Command uneme -r:

Code: Select all

Linux srvwapt 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

[htouvet]

https://wapt.tranquil.it/wapt/releases/ ... dcaa06.deb
and
https://wapt.tranquil.it/wapt/releases/ ... dcaa06.deb

something like:
cd
wget https://wapt.tranquil.it/wapt/releases/ ... dcaa06.deb
wget https://wapt.tranquil.it/wapt/releases/ ... dcaa06.deb

dpkg -i tis-wapt*1.7.4.6031-tisdeb9-4cdcaa06.deb

[agatoi]

The server and console updates went smoothly.

However, in the console, all devices appear as disconnected (including those that are powered on), but the console still indicates which devices require an update. I observed this with the Google Chrome package update. But since they are marked as disconnected, I cannot force updates from the console, particularly WAPT upgrade.

On one of the workstations that is giving me trouble, I manually updated the agent and it now shows up correctly in the console and is marked as connected when it is turned on.

The updates happen on shutdown, so my main problem is solved.

However, on the machine in question, the WAPT upgrade package generates an error (due to the fact that I have already manually updated the client?):

Code: Select all

Traceback (most recent call last):
  File "C:\Program Files (x86)\wapt\common.py", line 3700, in install_wapt
    packagetempdir = entry.unzip_package(cabundle=self.cabundle)
  File "C:\Program Files (x86)\wapt\waptpackage.py", line 2094, in unzip_package
    raise e
IOError: [Errno 22] invalid mode ('rb') or filename: u'c:\\windows\\temp\\wapth0dac7\\waptagent.exe'
IOError: [Errno 22] invalid mode ('rb') or filename: u'c:\\windows\\temp\\wapth0dac7\\waptagent.exe'

[agatoi]

Okay, after several restarts, the Wapt upgrade package is no longer showing an error and the computer is correctly detected.

However, I would appreciate a solution for computers that are listed as disconnected (even though they are powered on) in the console.

[sfonteneau]

The wapt package installs a task scheduled for an hour plus a few minutes.

Therefore, during this time the machine appears disconnected.