aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: 1 [2] 3

Author Topic: Auto startup of amuleweb should kill it at shutdown  (Read 11868 times)

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #15 on: July 24, 2005, 12:19:19 PM »

Quote
perform one more connection attempt
wrong. Instead, it should check the "existing" connection, whether it is still connected, or not. I agree with the error page.
Logged
concordia cum veritate

lfroen

  • Guest
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #16 on: July 24, 2005, 03:09:45 PM »

Quote
wrong. Instead, it should check the "existing" connection

No, that's wrong. Consider that your existing connection is dead (no matter reason), and you're not "still connected". Now what you do ? Silently exit ?!
You can check whether existing connection is still "alive" whatever it means, but be ready that it's not. And if it's not - you have to reconnect.
Logged

Vollstrecker

  • Administrator
  • Hero Member
  • *****
  • Karma: 67
  • Offline Offline
  • Posts: 1549
  • Unofficial Debian Packager
    • http://vollstreckernet.de
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #17 on: July 24, 2005, 10:25:16 PM »

Jep, and when you implemented that reconnect, amule can check if amulewb is already running, and then not starting a new one.
Logged
Homefucking is killing prostitution

lfroen

  • Guest
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #18 on: July 25, 2005, 08:36:14 AM »

Quote
amule can check if amulewb is already running
I have serious doubt about this. How exactly do you check this without knowing pid upfront ? Not that this is impossible, but neither trivial.
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #19 on: July 25, 2005, 09:30:04 AM »

Quote
You can check whether existing connection is still "alive"
That was what I meant.

Quote
And if it's not - you have to reconnect.
nope, instead

Quote
if not - display error page
The error page might have an option to try to reconnect (option == a link)

Quote
Quote
amule can check if amulewb is already running
I have serious doubt about this. How exactly do you check this without knowing pid upfront ? Not that this is impossible, but neither trivial.
You can check whether amuleweb is running or not (not trivial, as lfroen said), but you'll never be able to find out whether this running webserver instance wanted to connect to you.

Just imagine, that you start amuleweb, that connects to amule somewhere else. Then you decide to run amule too on this local machine. Amule would find out that a webserver is running, so it wouldn't start another one, but now it should.
Logged
concordia cum veritate

Vollstrecker

  • Administrator
  • Hero Member
  • *****
  • Karma: 67
  • Offline Offline
  • Posts: 1549
  • Unofficial Debian Packager
    • http://vollstreckernet.de
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #20 on: July 25, 2005, 10:43:53 AM »

You can check if you get an answer on webserver-port. 4711 I think. When you get an answer on this port, amuleweb is running. I don't think that it works if  you want to start a second one, on the same port, because the two amulewebs don't know to which of them you are talking. No matter if it wants to connect to you or not.
Logged
Homefucking is killing prostitution

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #21 on: July 25, 2005, 12:49:53 PM »

Quote
You can check if you get an answer on webserver-port. 4711 I think.
Yes, it is the default port. But nothing keeps users from changing it, so...
Logged
concordia cum veritate

Vollstrecker

  • Administrator
  • Hero Member
  • *****
  • Karma: 67
  • Offline Offline
  • Posts: 1549
  • Unofficial Debian Packager
    • http://vollstreckernet.de
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #22 on: July 25, 2005, 01:33:02 PM »

When I see right, you can specify only the port where amule accepts EC, not the port amuleweb listens on commandline. So I think that port is in amule.conf or remote.conf. So amule can see which port he has to check.
Logged
Homefucking is killing prostitution

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #23 on: July 25, 2005, 02:49:54 PM »

Quote
When I see right, you can specify only the port where amule accepts EC, not the port amuleweb listens on commandline.
From amuleweb man page:
Code: [Select]
      -s, --server-port=
              Webserver's HTTP port. This is the port you can point your browser to (default: 4711)
Quote
So I think that port is in amule.conf or remote.conf. So amule can see which port he has to check.
Well, remote.conf... which user? Amuleweb can be run by any user, not necessarily by the one who runs amule. The only requirement is that (s)he: 1) has an appropriate remote.conf file (or any other name, see the -f, --config-file command-line option), 2) supplies adequate command-line parameters, 3) answers the questions from amuleweb.

Actually, it could be implemented:
1) amule check for a process with a command name "amuleweb{DLG}"
2) check the command-line of the process for a -s switch
3) if not found, get the owner of the process
4) if owner of the process is not the current user, and we are not root, then give up
5) check the command-line of the process for a -f switch, if not found use "remote.conf" as config file name
6) read config file from the detected user's home directory.

I think it 1) doesn't wort the effort, 2) opens security holes, 3) people used to not like when a process just reads their secret files without a notice.

If you disagree with the above, just let me know :)

PS: And we still didn't care about things like:
1) what if a user renames amuleweb to something else, just for fun? (like amule-webserver, and leaves amuleweb as a symlink to the new name)
2) what if I use amuleweb to monitor another amule(d) somewhere else?
3) amuleweb behaves differently when started manually, manually with the -L switch, automatically...

So, certain cases can be detected, but it's more error-prone than useful.
Logged
concordia cum veritate

Vollstrecker

  • Administrator
  • Hero Member
  • *****
  • Karma: 67
  • Offline Offline
  • Posts: 1549
  • Unofficial Debian Packager
    • http://vollstreckernet.de
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #24 on: July 25, 2005, 03:05:04 PM »

Another optoin would be, that amule sends a message to conected amuleweb-processes, that it terminates. Amuleweb can then terminate, too. Without the amule process where it is connected to it is useless, and if somebody complains about that, you could add an option to remote.conf that lets amuleweb be running.
Logged
Homefucking is killing prostitution

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #25 on: July 25, 2005, 03:20:19 PM »

I also thought of it, but currently EC uses a polling mechanism (client ask something, core answers). No way to send a message from core to client. This would require rewriting EC sockets, etc (which will be done soon, so this might get implemented).

However, this is not a solution for situations when amule exits abnormally (i.e. crashes).
Logged
concordia cum veritate

lfroen

  • Guest
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #26 on: July 25, 2005, 03:27:09 PM »

Quote
Without the amule process where it is connected to it is useless

did you bothered to read thread above ?
If amule is unexpectedly quit - webserver should notify user about it. That's what it exist for - monitor remote amule.

Quote
Actually, it could be implemented:
1) amule check for a process with a command name "amuleweb{DLG}"
2) check the command-line of the process for a -s switch
3) if not found, get the owner of the process
4) if owner of the process is not the current user, and we are not root, then give up
5) check the command-line of the process for a -f switch, if not found use "remote.conf" as config file name

GonoszTopi: this is all over OS dependent. Even when available, you may not have permissions to access command line of other user's process. Consider situaltion when amuleweb started under other username.

But, let's stay focused. GonoszTopi - instead of trying to think about some imaginary scenario, where several amule's and amuleweb distributed over network and communicate with each other, let's make common case work correctly. And THEN think about exceptions.
Have you ever heard the word "usability" ?
The common case is "amuleweb" is started by amule (obviously on same machine) but amule(d) has quit unexpectedly. What we do ?

Quote
The error page might have an option to try to reconnect (option == a link)
You did not answered WHY it should be AN OPTION ? Why user would NOT want to reconnect ? Does (s)he enjoy looking in the error page ? Instead of including such link, just do it without bothering to ask user. This will provide match better experience.
Logged

lfroen

  • Guest
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #27 on: July 25, 2005, 03:31:53 PM »

Now, to the case of "amule set to start amuleweb automatically, but another one trying to reconnect". Obviously, both has been started with same options, and trying to listen on the same port. So, when amuleweb encountered situation that port can't be bound, it must simply quit, and we left with one amuleweb that reconnects and everything works as usual.
Even if user changed port in-between, nothing wrong happens - we will have 2 amuleweb's serving same page on 2 different ports.
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #28 on: July 25, 2005, 03:41:44 PM »

Quote
You did not answered WHY it should be AN OPTION ? Why user would NOT want to reconnect ? Does (s)he enjoy looking in the error page ? Instead of including such link, just do it without bothering to ask user. This will provide match better experience.
And did you think of HOW that "unexpectedly quit amule" gets restarted?

There should be an error page, that notifies user that something is wrong. Then the user can take appropriate steps (i.e. restart amule), and reconnect.

For being user-friendly, amuleweb can first try to reconnect and if that fails, only then displaying an error page (to deal with auto-restart scripts).
Logged
concordia cum veritate

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Auto startup of amuleweb should kill it at shutdown
« Reply #29 on: July 25, 2005, 03:43:30 PM »

Quote
GonoszTopi: this is all over OS dependent. Even when available, you may not have permissions to access command line of other user's process. Consider situaltion when amuleweb started under other username.

But, let's stay focused. GonoszTopi - instead of trying to think about some imaginary scenario, where several amule's and amuleweb distributed over network and communicate with each other, let's make common case work correctly. And THEN think about exceptions.
Have you ever heard the word "usability" ?
describing difficulties and drawbacks != implementing

Quote
Consider situaltion when amuleweb started under other username.
see 4)
Logged
concordia cum veritate
Pages: 1 [2] 3