Why not to use strace -p <pid> where the process is serving terminal (W $J, run set ret=$zu(-100,...) ) or host process in interoperability infrastructure to check what is wrong from point of view of syscalls. A quite standard way to figure out what goes wrong. terminal and service process has different uid,gid. terminal uid,gid has of logged user and user make sence have irisusr supplement group in order to run iris session ok. service process (in particular BusinessService) uid,gid has irisusr:irisusr. unless uid and gid has no relationship and use different name. gid name might be changed in installer, irisusr is 'fixed', but it might be changed in /etc/passwd. to know process uid,gid ps -eo pid,uid,gid,args | grep irisdb check dir access right from /data/InterSystems/IRIS/mgr/TEST01CODE and below.
For zip case, I would use command pipe and one parses output in order to know the result of operation.
If ce/iris is started by ccontrol /iris start in systemd service context then it must to be stopped also in systemd context. If one is used ccontrol/iris start directly there are consequences for system where init is systemd. 1 ce/iris processes are in cgroupv2 in user.slice hierarchy (more logical to have it in system.slice) 2 ce/iris processes are under systemd session and for example if /etc/systemd/logind.conf KillUserProcesses=yes then after user logout and user session destruction sibling processes might get signal (default SIGTERM) and handler might do process exits. Some ce/iris system daemons are terminated (mainly started by startup STU), some are not terminated (mainly control and those are forked from it). Another thing is /etc/systemd/logind.conf RemoveIPC=yes. systemd might just remove ipc resources owned by cache instance resulting cache kernel is not working correctly in very base stuff. Shortly it is worth to reread man systemd-logind, man logind.conf, man loginctl. Though systemd service wrapper for control/iris start is not quite consistent with direct use of ccontrol/iris start and systemd might lose correct service state but it never loses control on processes as being unix init process. Direct usage of ccontrol/iris start|stop requires attention to logind.conf KillUserProcesses=no, RemoveIPC=no. systemd service wrapper is worth to use as ccontrol/iris start|stop wrapper if system is managed by systemd.
I would use template variant.
cat /etc/systemd/system/isccache@.service
[Unit]
Description='isc cache'
After=network.target
#After=network-online.target
[Service]
# 1st way oneshot
Type=oneshot
RemainAfterExit=yes
# end of 1st way
# 2nd way forking
#PIDFile recommended but might be absent
# Type=forking
# end 2nd way
ExecStart=ccontrol start %i
ExecStop=ccontrol stop %i quietly
[Install]
WantedBy=multi-user.target
<end>
examples
systemctl start isccache@201772B865
systemctl status isccache@201772B865
systemctl stop isccache@201772B865
systemctl enable isccache@201772B865
systemctl disable isccache@201772B865
if systemd ce/iris service state is wrong or ce/iris shutdown fails.
ccontrol force 201772B865
systemctl stop isccache@201772B865
now it is ok for
systemctl start isccache@201772B865
ce=cache or ensemble
man sshd_config It depends on openssh server config. AuthenticationMethods = none gives access without any authentication. My guess it might global option or for given user. openssh server I mean https://github.com/PowerShell/Win32-OpenSSH/releases binary kits.
I tried windows open ssh server and I stopped to use it due to many glitches. For some version it simply doesn't work (connection failure) for others I got terminal problem after some time of working in ssh session. Yet another possible variant worth to try. https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K... Other words you might try to use telnet protocol over tls. I never tried it, but you might try since you are motivated to do it. tls for windows is expected to be robust.
Also I reported systemd bug purpose 1 run cache/iris as systemd service by not root user using polkit jscript , user must be in cache/iris management group. It is ok. purpose 2 use systemd-run to start|stop cache/iris by ccontrol/iris consistent way with systemd where user in cache/iris management group. It is not ok and subject of systemd bug. root works ok. https://github.com/systemd/systemd/issues/17224
You will be happy even for
/etc/systemd/logind.conf
RemoveIPC=yes
if cache installation uses owner=cachesys,
group allowed start/stop cache - cachemgr.
You might use either names you like instead of cachesys, cachemgr
but 'cachesys' != cacheusr (in term of uid)
It works even if cachesys uid > 1000 i.e. it is considered
as non system process.
go to post
Why not to use
strace -p <pid>
where the process is serving terminal (W $J, run set ret=$zu(-100,...) )
or host process in interoperability infrastructure
to check what is wrong from point of view of syscalls.
A quite standard way to figure out what goes wrong.
terminal and service process has different uid,gid.
terminal uid,gid has of logged user
and user make sence have irisusr supplement group in order
to run iris session ok.
service process (in particular BusinessService) uid,gid has irisusr:irisusr.
unless uid and gid has no relationship and use different name.
gid name might be changed in installer, irisusr is 'fixed',
but it might be changed in /etc/passwd.
to know process uid,gid
ps -eo pid,uid,gid,args | grep irisdb
check dir access right from
/data/InterSystems/IRIS/mgr/TEST01CODE
and below.
For zip case, I would use command pipe and one parses output
in order to know the result of operation.
go to post
thank - fixed.
go to post
If ce/iris is started by ccontrol /iris start in systemd service context then it must to be stopped also in systemd context.
If one is used ccontrol/iris start directly there are consequences for system where init is systemd.
1 ce/iris processes are in cgroupv2 in user.slice hierarchy (more logical to have it in system.slice)
2 ce/iris processes are under systemd session and for example if /etc/systemd/logind.conf KillUserProcesses=yes then after user logout and user session destruction
sibling processes might get signal (default SIGTERM) and handler might do process exits.
Some ce/iris system daemons are terminated (mainly started by startup STU), some are not terminated (mainly control and those are forked from it).
Another thing is /etc/systemd/logind.conf RemoveIPC=yes.
systemd might just remove ipc resources owned by cache instance resulting cache kernel is not working
correctly in very base stuff.
Shortly it is worth to reread man systemd-logind, man logind.conf, man loginctl.
Though systemd service wrapper for control/iris start is not quite consistent with direct use of ccontrol/iris start and systemd might lose correct service state but it never loses control on processes as being unix init process.
Direct usage of ccontrol/iris start|stop requires attention to logind.conf KillUserProcesses=no, RemoveIPC=no.
systemd service wrapper is worth to use as ccontrol/iris start|stop wrapper if system is managed by systemd.
I would use template variant.
go to post
man sshd_config
It depends on openssh server config.
AuthenticationMethods = none
gives access without any authentication.
My guess it might global option or for given user.
openssh server I mean https://github.com/PowerShell/Win32-OpenSSH/releases
binary kits.
https://docs.microsoft.com/es-us/windows-server/administration/openssh/openssh_install_firstuse
go to post
I tried windows open ssh server and I stopped to use it due to many glitches.
For some version it simply doesn't work (connection failure) for others I got terminal problem after some time of working in ssh session.
Yet another possible variant worth to try.
https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K...
Other words you might try to use telnet protocol over tls.
I never tried it, but you might try since you are motivated to do it.
tls for windows is expected to be robust.
go to post
Also I reported systemd bug
purpose 1 run cache/iris as systemd service by not root user using polkit jscript , user must be in cache/iris management group. It is ok.
purpose 2 use systemd-run to start|stop cache/iris by ccontrol/iris consistent way with systemd where user in cache/iris
management group. It is not ok and subject of systemd bug. root works ok.
https://github.com/systemd/systemd/issues/17224
go to post
Obviosly it is instance name
ccontrol qlist
ccontrol list
go to post
You will be happy even for /etc/systemd/logind.conf RemoveIPC=yes if cache installation uses owner=cachesys, group allowed start/stop cache - cachemgr. You might use either names you like instead of cachesys, cachemgr but 'cachesys' != cacheusr (in term of uid) It works even if cachesys uid > 1000 i.e. it is considered as non system process.