Bug#829380: [Debian-med-packaging] Bug#829380: Orthanc 1.2.0

[Sébastien Jodogne]

Dear Karsten,

Just committed the following changeset, and uploaded it to Debian
Sid:
https://salsa.debian.org/med-team/orthanc/-/commit/bc7e343b6e49f5e18ad15378058257fcd0c7be1f

As you recommended, I have now added "/usr/sbin/orthanc_upgrade" as a
standalone script.

Thanks again,
Sébastien-


On 8/04/20 10:34, Karsten Hilbert wrote:
> On Wed, Apr 08, 2020 at 07:50:06AM +0200, Sébastien Jodogne wrote:
> 
>> Sorry for having overlooked this issue.
>>
>> I have migrated Karsten's instructions into the "README.Debian" file of
>> the "orthanc" package:
>> https://salsa.debian.org/med-team/orthanc/-/commit/9f004236c6190a4b3137d358b8de9d0cae498f90
> 
> Thanks for that. Do note that those haven't actually been
> tested while the attached script *has* been.
> 
> Any chance that script can be integrated ?
> 
> (just put it in /usr/sbin/ and add a note about it into README.Debian)
> 
> Of course, that's a wishlist item, not a request.
> 
> Best,
> Karsten

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Wed, Apr 08, 2020 at 07:50:06AM +0200, Sébastien Jodogne wrote:

> Sorry for having overlooked this issue.
>
> I have migrated Karsten's instructions into the "README.Debian" file of
> the "orthanc" package:
> https://salsa.debian.org/med-team/orthanc/-/commit/9f004236c6190a4b3137d358b8de9d0cae498f90

Thanks for that. Do note that those haven't actually been
tested while the attached script *has* been.

Any chance that script can be integrated ?

(just put it in /usr/sbin/ and add a note about it into README.Debian)

Of course, that's a wishlist item, not a request.

Best,
Karsten


> HTH,
> Sébastien-
>
>
> On 7/04/20 23:22, Karsten Hilbert wrote:
> > On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:
> >
> >> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
> >>> On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
> >>>
>  Sorry, my mistake: Preventing Orthanc from starting after an upgrade of 
>  the
>  database schema was on my TODO list... it is not implemented yet. I have
>  just added an issue on the upstream bug tracker to avoid forgetting it:
>  https://bitbucket.org/sjodogne/orthanc/issues/29
> 
>  This feature will be part of forthcoming 1.2.1 release.
> >>>
> >>> Thanks a lot for confirming. I will test when 1.2.1 is out
> >>> and provide a script users can run updating the database
> >>> schema if needed.
> >>
> >> Hello Karsten,
> >>
> >> Debian stable now has version 1.5.6 [1] and the upstream bug report is
> >> marked as resolved [2].  Is a separate update script still needed?  If
> >> not, can this bug report be closed?
> >
> > A separate script is never needed because Orthanc itself can
> > upgrade it's database -- if manually invoked in the right
> > environment.
> >
> > The (attached) script makes it a lot easier for users to do
> > so and it proves (on my machine) that the surprising behaviour
> > (Orthanc being started after a run with --upgrade) is fixed.
> >
> > So, the bug can be closed, regardless of the attached script
> > -- but the attached script is useful to users whenever
> > another database upgrade comes along (which there will,
> > eventually).
> >
> > Best,
> > Karsten
> > --
> > GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
> >

--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#829380: Orthanc 1.2.0

[Sébastien Jodogne]

Hello,

Sorry for having overlooked this issue.

I have migrated Karsten's instructions into the "README.Debian" file of
the "orthanc" package:
https://salsa.debian.org/med-team/orthanc/-/commit/9f004236c6190a4b3137d358b8de9d0cae498f90

HTH,
Sébastien-


On 7/04/20 23:22, Karsten Hilbert wrote:
> On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:
> 
>> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
>>> On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
>>>
 Sorry, my mistake: Preventing Orthanc from starting after an upgrade of the
 database schema was on my TODO list... it is not implemented yet. I have
 just added an issue on the upstream bug tracker to avoid forgetting it:
 https://bitbucket.org/sjodogne/orthanc/issues/29

 This feature will be part of forthcoming 1.2.1 release.
>>>
>>> Thanks a lot for confirming. I will test when 1.2.1 is out
>>> and provide a script users can run updating the database
>>> schema if needed.
>>
>> Hello Karsten,
>>
>> Debian stable now has version 1.5.6 [1] and the upstream bug report is
>> marked as resolved [2].  Is a separate update script still needed?  If
>> not, can this bug report be closed?
> 
> A separate script is never needed because Orthanc itself can
> upgrade it's database -- if manually invoked in the right
> environment.
> 
> The (attached) script makes it a lot easier for users to do
> so and it proves (on my machine) that the surprising behaviour
> (Orthanc being started after a run with --upgrade) is fixed.
> 
> So, the bug can be closed, regardless of the attached script
> -- but the attached script is useful to users whenever
> another database upgrade comes along (which there will,
> eventually).
> 
> Best,
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
> 

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:

> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
> > On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
> >
> > > Sorry, my mistake: Preventing Orthanc from starting after an upgrade of 
> > > the
> > > database schema was on my TODO list... it is not implemented yet. I have
> > > just added an issue on the upstream bug tracker to avoid forgetting it:
> > > https://bitbucket.org/sjodogne/orthanc/issues/29
> > >
> > > This feature will be part of forthcoming 1.2.1 release.
> >
> > Thanks a lot for confirming. I will test when 1.2.1 is out
> > and provide a script users can run updating the database
> > schema if needed.
>
> Hello Karsten,
>
> Debian stable now has version 1.5.6 [1] and the upstream bug report is
> marked as resolved [2].  Is a separate update script still needed?  If
> not, can this bug report be closed?

A separate script is never needed because Orthanc itself can
upgrade it's database -- if manually invoked in the right
environment.

The (attached) script makes it a lot easier for users to do
so and it proves (on my machine) that the surprising behaviour
(Orthanc being started after a run with --upgrade) is fixed.

So, the bug can be closed, regardless of the attached script
-- but the attached script is useful to users whenever
another database upgrade comes along (which there will,
eventually).

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
#!/bin/bash

#-
# GPLv2 or later, Karsten Hilbert

#set -x

LOGDIR=/var/log/orthanc
LOGFILE=${LOGDIR}/upgrade.log
ARGS="--upgrade --trace /etc/orthanc/"
ORTHANC_BINARY=`which Orthanc`


echo "Stopping Orthanc server..."
echo "#---" &> ${LOGFILE}
systemctl stop orthanc.service &>> ${LOGFILE}
RESULT=$?
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
sleep 1s
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot stop Orthanc, please inspect the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Attempting database upgrade..."
echo "#---" &>> ${LOGFILE}
echo "Running <${ORTHANC_BINARY} ${ARGS}>" >> ${LOGFILE}
sudo -u orthanc ${ORTHANC_BINARY} ${ARGS} &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
cat ${ORTHANC_LOG} &>> ${LOGFILE}
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Upgrade failed, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Restarting Orthanc server..."
sleep 1s
echo "#---" &>> ${LOGFILE}
systemctl start orthanc.service &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot restart Orthanc, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo ""
echo "Seems successful..."
echo "Log: ${LOGFILE}"
echo ""
systemctl status orthanc.service

#-

Bug#829380: Orthanc 1.2.0

[tony mancill]

On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
> On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
> 
> > Sorry, my mistake: Preventing Orthanc from starting after an upgrade of the
> > database schema was on my TODO list... it is not implemented yet. I have
> > just added an issue on the upstream bug tracker to avoid forgetting it:
> > https://bitbucket.org/sjodogne/orthanc/issues/29
> > 
> > This feature will be part of forthcoming 1.2.1 release.
> 
> Thanks a lot for confirming. I will test when 1.2.1 is out
> and provide a script users can run updating the database
> schema if needed.

Hello Karsten,

Debian stable now has version 1.5.6 [1] and the upstream bug report is
marked as resolved [2].  Is a separate update script still needed?  If
not, can this bug report be closed?

Thank you,
tony

[1] https://tracker.debian.org/pkg/orthanc
[2] https://bitbucket.org/sjodogne/orthanc/issues/29


signature.asc
Description: PGP signature

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:

> Sorry, my mistake: Preventing Orthanc from starting after an upgrade of the
> database schema was on my TODO list... it is not implemented yet. I have
> just added an issue on the upstream bug tracker to avoid forgetting it:
> https://bitbucket.org/sjodogne/orthanc/issues/29
> 
> This feature will be part of forthcoming 1.2.1 release.

Thanks a lot for confirming. I will test when 1.2.1 is out
and provide a script users can run updating the database
schema if needed.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#829380: Orthanc 1.2.0

[Sébastien Jodogne]

Hello,


No: If the "--upgrade" command-line option is provided, the Orthanc server
will never start. If no upgrade is required, this is a void operation that
returns immediately.


I would have thought so. However, why does this script: [...]
producing the following log ? [...]

#---
Running 
W1229 13:29:01.755332 main.cpp:1238] Orthanc version: 1.2.0
W1229 13:29:01.79 main.cpp:1095] Performance warning: Non-release 
build, runtime debug assertions are turned on
[...]
I1229 13:29:01.934832 DicomServer.cpp:63] DICOM server started

Anything I am doing wrong here ?


Sorry, my mistake: Preventing Orthanc from starting after an upgrade of 
the database schema was on my TODO list... it is not implemented yet. I 
have just added an issue on the upstream bug tracker to avoid forgetting it:

https://bitbucket.org/sjodogne/orthanc/issues/29

This feature will be part of forthcoming 1.2.1 release.

Regards,
Sébastien-

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Thu, Dec 29, 2016 at 11:02:25AM +0100, Sébastien Jodogne wrote:

> > may I ask for confirmation of the following behaviour:
> > 
> > If Orthanc is manually started for a DB upgrade
> > 
> > (say, on Debian:)
> > /usr/sbin/Orthanc --upgrade --trace /etc/orthanc/
> > 
> > BUT the database is already at the required version THEN
> > Orthanc will not run the upgrade and fall back to starting
> > up as if --upgrade was not specified on the command line.
> 
> No: If the "--upgrade" command-line option is provided, the Orthanc server
> will never start. If no upgrade is required, this is a void operation that
> returns immediately.

I would have thought so. However, why does this script:

#-
#!/bin/bash

# GPLv2 or later, Karsten Hilbert

set -x

LOGDIR=/var/log/orthanc
LOGFILE=${LOGDIR}/upgrade.log
ARGS="--upgrade --trace /etc/orthanc/"
ORTHANC_BINARY=`which Orthanc`


echo "Stopping Orthanc server..."
echo "#---" &> ${LOGFILE}
systemctl stop orthanc.service &>> ${LOGFILE}
RESULT=$?
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
sleep 1s
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot stop Orthanc, please inspect the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Attempting database upgrade..."
echo "#---" &>> ${LOGFILE}
echo "Running <${ORTHANC_BINARY} ${ARGS}>" >> ${LOGFILE}
sudo -u orthanc ${ORTHANC_BINARY} ${ARGS} &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
cat ${ORTHANC_LOG} &>> ${LOGFILE}
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Upgrade failed, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Restarting Orthanc server..."
sleep 1s
echo "#---" &>> ${LOGFILE}
systemctl start orthanc.service &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot restart Orthanc, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo ""
echo "Seems successful..."
echo "Log: ${LOGFILE}"
echo ""
systemctl status orthanc.service
#-

stop at "Attempting database upgrade" until I hit
CTRL-C and show this output:

#-
Skript gestartet auf Do 29 Dez 2016 13:28:46 CET
root@hermes:~/orthanc# ./orthanc-upgrade_db 
+ LOGDIR=/var/log/orthanc
+ LOGFILE=/var/log/orthanc/upgrade.log
+ ARGS='--upgrade --trace /etc/orthanc/'
++ which Orthanc
+ ORTHANC_BINARY=/usr/sbin/Orthanc
+ echo 'Stopping Orthanc server...'
Stopping Orthanc server...
+ echo '#---'
+ systemctl stop orthanc.service
+ RESULT=0
+ echo '#---'
+ systemctl status orthanc.service
+ sleep 1s
+ '[' 0 -ne 0 ']'
+ echo 'Attempting database upgrade...'
Attempting database upgrade...
+ echo '#---'
+ echo 'Running '
+ sudo -u orthanc /usr/sbin/Orthanc --upgrade --trace /etc/orthanc/
^C+ RESULT=0
+ '[' 0 -ne 0 ']'
+ echo 'Restarting Orthanc server...'
Restarting Orthanc server...
+ sleep 1s
+ echo '#---'
+ systemctl start orthanc.service
+ RESULT=0
+ '[' 0 -ne 0 ']'
+ echo ''

+ echo 'Seems successful...'
Seems successful...
+ echo 'Log: /var/log/orthanc/upgrade.log'
Log: /var/log/orthanc/upgrade.log
+ echo ''

+ systemctl status orthanc.service

● orthanc.service - LSB: Orthanc init script
   Loaded: loaded (/etc/init.d/orthanc; generated; vendor preset: 
enabled)
   Active: active (running) since Thu 2016-12-29 13:29:26 
CET; 19ms ago
 Docs: man:systemd-sysv-generator(8)
  Process: 29048 ExecStop=/etc/init.d/orthanc stop (code=exited, 
status=0/SUCCESS)
  Process: 29146 ExecStart=/etc/init.d/orthanc start (code=exited, 
status=0/SUCCESS)
Tasks: 1 (limit: 4915)

Bug#829380: Orthanc 1.2.0

[Sébastien Jodogne]

Dear Karsten,

Sorry for the delay.



may I ask for confirmation of the following behaviour:

If Orthanc is manually started for a DB upgrade

(say, on Debian:)
/usr/sbin/Orthanc --upgrade --trace /etc/orthanc/

BUT the database is already at the required version THEN
Orthanc will not run the upgrade and fall back to starting
up as if --upgrade was not specified on the command line.


No: If the "--upgrade" command-line option is provided, the Orthanc 
server will never start. If no upgrade is required, this is a void 
operation that returns immediately.




The Orthanc book makes me think that when an upgrade is
actually run Orthanc will automatically stop after upgrading.


Yes, this is the currently implemented behavior.



If you can confirm that Orthanc does NOT stop if no upgrade
is required even if --upgrade is specified then I would like
to ask for a change of this behaviour. Typically, one would
expect Orthanc to end up in the same state (DB upgraded and
server stopped) after an --upgrade run regardless of whether
an actual upgrade was performed.

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

That would make the process predictable and thereby
scriptable.


Yes, this is my view too: The "--upgrade" option is a special 
maintenance operation, and it should NOT start the server afterwards.




The exit code would make it possible to
differentiate between success and failure where
nothing-to-do-because-up-to-date counts as success.


Yes, the status code will be non-zero if any error occurs during the 
upgrade process.


HTH,
Sébastien-

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

Hello Sebastian,

may I ask for confirmation of the following behaviour:

If Orthanc is manually started for a DB upgrade

(say, on Debian:)
/usr/sbin/Orthanc --upgrade --trace /etc/orthanc/

BUT the database is already at the required version THEN
Orthanc will not run the upgrade and fall back to starting
up as if --upgrade was not specified on the command line.

The Orthanc book makes me think that when an upgrade is
actually run Orthanc will automatically stop after upgrading.

If you can confirm that Orthanc does NOT stop if no upgrade
is required even if --upgrade is specified then I would like
to ask for a change of this behaviour. Typically, one would
expect Orthanc to end up in the same state (DB upgraded and
server stopped) after an --upgrade run regardless of whether
an actual upgrade was performed.

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

That would make the process predictable and thereby
scriptable. The exit code would make it possible to
differentiate between success and failure where
nothing-to-do-because-up-to-date counts as success.

Any chance this can get implemented ?

(Should be pretty much a one-liner.)

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Wed, Dec 14, 2016 at 10:43:07AM +0100, Sebastien Jodogne wrote:

> > Well, once Orthanc 1.2 shows up in my sources.lst I will test
> > the suggested script and report back. Since I don't assume
> > Orthanc 1.1 -> 1.2 to actually need a database upgrade (?) I
> > expect the script to gracefully do nothing.
> 
> Indeed, an upgrade of the Orthanc database is only necessary if the version
> of the DB changes.

I know.

> The last modification of the DB schema was introduced in Orthanc 0.9.5
> (released on December 2nd, 2015).

I recalled as much which is why I inferred that, currently,
no upgrade is necessary.

> the database schema is now considered as stable

I sure wish that to be so but there's always Famous Last Words.

> Furthermore, I personally feel that the upgrade process should imply a
> manual operation from the user.

Sure.

> As a consequence, I am not convinced that providing an automated script is 
> necessary.

No one suggested an _automated_ script.

I suggest to provide a script which calls "Orthanc -upgrade"
in the Debian-specific technically proper way _when run by
the user_. Which is what the suggested script does.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#829380: Orthanc 1.2.0

[Sebastien Jodogne]

Dear Karsten,


Well, once Orthanc 1.2 shows up in my sources.lst I will test
the suggested script and report back. Since I don't assume
Orthanc 1.1 -> 1.2 to actually need a database upgrade (?) I
expect the script to gracefully do nothing.


Indeed, an upgrade of the Orthanc database is only necessary if the 
version of the DB changes. The internals are explained in the Orthanc Book:

http://book.orthanc-server.com/developers/db-versioning.html

The last modification of the DB schema was introduced in Orthanc 0.9.5 
(released on December 2nd, 2015). This means that any post-0.9.5 release 
will transparently work without having to upgrade the database. Since 
that release, the database schema is now considered as stable, and no 
upgrade should be necessary.


Furthermore, I personally feel that the upgrade process should imply a 
manual operation from the user. The official documentation of Orthanc 
clearly explains what should be done in such a case:

http://book.orthanc-server.com/users/replication.html#upgrade-the-database-schema

As a consequence, I am not convinced that providing an automated script 
is necessary. Maybe it would be sufficient to simply point to the 
section of the Orthanc Book above in the "README.Debian".


HTH,
Sébastien-

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Wed, Dec 14, 2016 at 06:49:20AM +0100, Sébastien Jodogne wrote:

> This issue is very low priority wrt. my TODO list for the upstream project.

Understandable.

> Anyone is obviously welcome to help me and contribute by packaging this
> script into the orthanc Debian package.

...

> Le 14 déc. 2016 06:42, "Andreas Tille"  a écrit :

> Do you plan to provide any upgrade script as it was asked for in
> 
>https://bugs.debian.org/829380

Actually, that bug report did not simply _ask_ for a script
but also provided a concrete suggestion which I hoped would
be looked at, obvious errors pointed out so I can fix them,
and then included in one of the next versions.

Well, once Orthanc 1.2 shows up in my sources.lst I will test
the suggested script and report back. Since I don't assume
Orthanc 1.1 -> 1.2 to actually need a database upgrade (?) I
expect the script to gracefully do nothing. If that's so I'll
confirm this here and hope to get the script included in the
debian git tree.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#829380: Orthanc 1.2.0

[Andreas Tille]

Hi Sébastien,

On Wed, Dec 14, 2016 at 06:49:20AM +0100, Sébastien Jodogne wrote:
> This issue is very low priority wrt. my TODO list for the upstream project.
> 
> Anyone is obviously welcome to help me and contribute by packaging this
> script into the orthanc Debian package.

Thanks for the clarification.  The new package is uploaded.  Please git
pull for a bumped debhelper compat level.

Kind regards

 Andreas.
 
> Le 14 déc. 2016 06:42, "Andreas Tille"  a écrit :
> 
> Do you plan to provide any upgrade script as it was asked for in
> 
>https://bugs.debian.org/829380

-- 
http://fam-tille.de