up to date Tumbleweed (13.1)
systemctl start privoxy
18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details.
18:27 Crash: ~ # systemctl status privoxy privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities Loaded: loaded (/usr/lib/systemd/system/privoxy.service; disabled) Active: failed (Result: exit-code) since Wed 2013-11-20 18:27:09 EST; 15s ago Process: 9430 ExecStart=/usr/sbin/privoxy --pidfile /run/privoxy.pid --user privoxy /etc/privoxy/config (code=exited, status=1/FAILURE)
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1 Nov 20 18:27:09 Crash systemd[1]: Failed to start Privoxy Web Proxy With Advanced Filtering Capabilities. Nov 20 18:27:09 Crash systemd[1]: Unit privoxy.service entered failed state.
18:27 Crash: ~ # journalctl -xn -- Logs begin at Sat 2013-03-30 18:27:22 EDT, end at Wed 2013-11-20 -- 18:27:35 EST. -- Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... -- Subject: Unit privoxy.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
El 20/11/13 20:33, Patrick Shanahan escribió:
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1
Is the daemon configuration file correct ? it exited cleanly with EXIT_FAILURE .
* Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 18:51]:
El 20/11/13 20:33, Patrick Shanahan escribió:
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1
Is the daemon configuration file correct ? it exited cleanly with EXIT_FAILURE .
I am presently running privoxy via --no-daemon and it is active and showing no errors. It ran successfully for years until the 13.1 update. If you are referring to a file other than /var/lib/privoxy/etc/config, please tell me which,
tks,
El 20/11/13 21:46, Patrick Shanahan escribió:
- Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 18:51]:
El 20/11/13 20:33, Patrick Shanahan escribió:
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1
Is the daemon configuration file correct ? it exited cleanly with EXIT_FAILURE .
I am presently running privoxy via --no-daemon and it is active and showing no errors. It ran successfully for years until the 13.1 update. If you are referring to a file other than /var/lib/privoxy/etc/config, please tell me which,
I am refering to the file which is being read by privoxy in the unit file, that is /etc/privoxy/config
* Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 20:18]:
El 20/11/13 21:46, Patrick Shanahan escribió:
- Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 18:51]:
El 20/11/13 20:33, Patrick Shanahan escribió:
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1
Is the daemon configuration file correct ? it exited cleanly with EXIT_FAILURE .
I am presently running privoxy via --no-daemon and it is active and showing no errors. It ran successfully for years until the 13.1 update. If you are referring to a file other than /var/lib/privoxy/etc/config, please tell me which,
I am refering to the file which is being read by privoxy in the unit file, that is /etc/privoxy/config
I do have /etc/privoxy/config, but:
21:57 Crash: ~ # rpm -ql privoxy /etc/NetworkManager /etc/NetworkManager/dispatcher.d /etc/NetworkManager/dispatcher.d/privoxyd /etc/logrotate.d/privoxy /etc/privoxy /usr/lib/systemd/system/privoxy.service /usr/sbin/privoxy /usr/share/doc/packages/privoxy /usr/share/doc/packages/privoxy/AUTHORS /usr/share/doc/packages/privoxy/ChangeLog /usr/share/doc/packages/privoxy/LICENSE /usr/share/doc/packages/privoxy/README /usr/share/man/man1/privoxy.1.gz /var/lib/privoxy /var/lib/privoxy/etc /var/lib/privoxy/etc/config /var/lib/privoxy/etc/default.action /var/lib/privoxy/etc/default.filter /var/lib/privoxy/etc/match-all.action /var/lib/privoxy/etc/regression-tests.action /var/lib/privoxy/etc/templates /var/lib/privoxy/etc/templates/blocked /var/lib/privoxy/etc/templates/cgi-error-404 /var/lib/privoxy/etc/templates/cgi-error-bad-param /var/lib/privoxy/etc/templates/cgi-error-disabled /var/lib/privoxy/etc/templates/cgi-error-file /var/lib/privoxy/etc/templates/cgi-error-file-read-only /var/lib/privoxy/etc/templates/cgi-error-modified /var/lib/privoxy/etc/templates/cgi-error-parse /var/lib/privoxy/etc/templates/cgi-style.css /var/lib/privoxy/etc/templates/connect-failed /var/lib/privoxy/etc/templates/connection-timeout /var/lib/privoxy/etc/templates/default /var/lib/privoxy/etc/templates/edit-actions-add-url-form /var/lib/privoxy/etc/templates/edit-actions-for-url /var/lib/privoxy/etc/templates/edit-actions-for-url-filter /var/lib/privoxy/etc/templates/edit-actions-list /var/lib/privoxy/etc/templates/edit-actions-list-button /var/lib/privoxy/etc/templates/edit-actions-list-section /var/lib/privoxy/etc/templates/edit-actions-list-url /var/lib/privoxy/etc/templates/edit-actions-remove-url-form /var/lib/privoxy/etc/templates/edit-actions-url-form /var/lib/privoxy/etc/templates/forwarding-failed /var/lib/privoxy/etc/templates/mod-local-help /var/lib/privoxy/etc/templates/mod-support-and-service /var/lib/privoxy/etc/templates/mod-title /var/lib/privoxy/etc/templates/mod-unstable-warning /var/lib/privoxy/etc/templates/no-server-data /var/lib/privoxy/etc/templates/no-such-domain /var/lib/privoxy/etc/templates/show-request /var/lib/privoxy/etc/templates/show-status /var/lib/privoxy/etc/templates/show-status-file /var/lib/privoxy/etc/templates/show-url-info /var/lib/privoxy/etc/templates/show-version /var/lib/privoxy/etc/templates/toggle /var/lib/privoxy/etc/templates/toggle-mini /var/lib/privoxy/etc/templates/untrusted /var/lib/privoxy/etc/templates/url-info-osd.xml /var/lib/privoxy/etc/trust /var/lib/privoxy/etc/user.action /var/lib/privoxy/etc/user.filter /var/lib/privoxy/lib64 /var/lib/privoxy/log /var/lib/privoxy/var /var/lib/privoxy/var/log /var/lib/privoxy/var/log/privoxy /var/lib/privoxy/var/run
privoxy no longer has /etc/privoxy/config ???
tks
On Thu, 21 Nov 2013 04:00, Patrick Shanahan <paka@...> wrote:
- Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 20:18]:
El 20/11/13 21:46, Patrick Shanahan escribió:
- Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 18:51]:
El 20/11/13 20:33, Patrick Shanahan escribió:
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1
Is the daemon configuration file correct ? it exited cleanly with EXIT_FAILURE .
I am presently running privoxy via --no-daemon and it is active and showing no errors. It ran successfully for years until the 13.1 update. If you are referring to a file other than /var/lib/privoxy/etc/config, please tell me which,
I am refering to the file which is being read by privoxy in the unit file, that is /etc/privoxy/config
I do have /etc/privoxy/config, but:
21:57 Crash: ~ # rpm -ql privoxy
[snip]
/etc/privoxy
THIS IS A LINK (points to /var/lib/privoxy/etc)
[snip]
/var/lib/privoxy/etc /var/lib/privoxy/etc/config
THERE IS THE REAL FILE
/var/lib/privoxy/log
THE LOG DIR
/var/lib/privoxy/var/log /var/lib/privoxy/var/log/privoxy
LINK (points to /var/lib/privoxy/log)
The files that will have the most interesting infos are:
1. The main config file: /var/lib/privoxy/etc/config (also reachable throu /etc/privoxy/config)
2. The logfile written by privoxy itself, defaults to: /var/lib/privoxy/log/logfile
For the config file, search for the lines with
logdir (/log|/var/log/privoxy= logfile logfile # must exist or no logging at all
debug [num] # multiple lines, will be added up as bitfield debug 4096 # 4096 and 8192 are the minimum until privoxy debug 8192 # runs smootly
Also have a look inside the service file: /usr/lib/systemd/system/privoxy.service
The entries Type=
my handwritten file for 12.3 has Type=forking PIDFile=/var/run/privoxy.pid WorkingDirectory=/var/lib/privoxy ExecStart=/usr/sbin/privoxy --user privoxy.privoxy --pidfile /var/run/privoxy.pid --chroot /etc/config ExecReload=/bin/kill -USR1 $MAINPID
On instict I'd say something is wrong with the config. But if the logfile exists, that should give you some insights.
Otherwise, make sure that the 'logfile' entry exists, and the 'debug' lines with 4096 and 8192 are not commented out, and try again, and look at the privoxy logfile for hints.
- Yamaban.
* Yamaban foerster@lisas.de [11-20-13 22:35]:
On Thu, 21 Nov 2013 04:00, Patrick Shanahan <paka@...> wrote:
[...]
21:57 Crash: ~ # rpm -ql privoxy
[snip]
/etc/privoxy
THIS IS A LINK (points to /var/lib/privoxy/etc)
ok
[snip]
/var/lib/privoxy/etc /var/lib/privoxy/etc/config
THERE IS THE REAL FILE
understand
/var/lib/privoxy/log
THE LOG DIR
/var/lib/privoxy/var/log /var/lib/privoxy/var/log/privoxy
LINK (points to /var/lib/privoxy/log)
The files that will have the most interesting infos are:
The main config file: /var/lib/privoxy/etc/config (also reachable throu /etc/privoxy/config)
The logfile written by privoxy itself, defaults to: /var/lib/privoxy/log/logfile
contains one line for 03-12-2011
For the config file, search for the lines with
logdir (/log|/var/log/privoxy=
was: logdir /log now: logdir /var/lib/privoxy/log
logfile logfile # must exist or no logging at all
debug [num] # multiple lines, will be added up as bitfield debug 4096 # 4096 and 8192 are the minimum until privoxy debug 8192 # runs smootly
no debug was set, added 4096 and 8192
Also have a look inside the service file: /usr/lib/systemd/system/privoxy.service
The entries Type=
my handwritten file for 12.3 has Type=forking PIDFile=/var/run/privoxy.pid WorkingDirectory=/var/lib/privoxy ExecStart=/usr/sbin/privoxy --user privoxy.privoxy --pidfile /var/run/privoxy.pid --chroot /etc/config ExecReload=/bin/kill -USR1 $MAINPID
[Unit] Description=Privoxy Web Proxy With Advanced Filtering Capabilities After=network.target
[Service] Type=forking PIDFile=/run/privoxy.pid ExecStart=/usr/sbin/privoxy --pidfile /run/privoxy.pid --user privoxy /etc/privoxy/config
[Install] WantedBy=multi-user.target
On instict I'd say something is wrong with the config. But if the logfile exists, that should give you some insights.
Otherwise, make sure that the 'logfile' entry exists, and the 'debug' lines with 4096 and 8192 are not commented out, and try again, and look at the privoxy logfile for hints.
It now starts :^)
Appears there is a problem with the new privoxy configuration not following previous installations, and with the error reporting or lack of "useful error messages".
Thanks for your and Christian's help, I am now a happy camper :^).
* Patrick Shanahan paka@opensuse.org [11-20-13 23:03]: [...]
It now starts :^)
Appears there is a problem with the new privoxy configuration not following previous installations, and with the error reporting or lack of "useful error messages".
Thanks for your and Christian's help, I am now a happy camper :^).
BUT, the http://p.p url does not work ???
On 11/20/2013 10:34 PM, Yamaban wrote:
On Thu, 21 Nov 2013 04:00, Patrick Shanahan <paka@...> wrote:
- Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 20:18]:
El 20/11/13 21:46, Patrick Shanahan escribió:
- Cristian Rodríguez crrodriguez@opensuse.org [11-20-13 18:51]:
El 20/11/13 20:33, Patrick Shanahan escribió:
Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1
Is the daemon configuration file correct ? it exited cleanly with EXIT_FAILURE .
I am presently running privoxy via --no-daemon and it is active and showing no errors. It ran successfully for years until the 13.1 update. If you are referring to a file other than /var/lib/privoxy/etc/config, please tell me which,
I am refering to the file which is being read by privoxy in the unit file, that is /etc/privoxy/config
I do have /etc/privoxy/config, but:
21:57 Crash: ~ # rpm -ql privoxy
[snip]
/etc/privoxy
THIS IS A LINK (points to /var/lib/privoxy/etc)
What genius thought it was a good idea to move system-specific config data out of /etc, so that when an admin backs up /etc, they DON'T in fact have all the important stuff they are SUPPOSED to have?
I don't use privoxy or 13.1, this is a general common sense thing and doesn't matter what package or OS.
On Fri, 22 Nov 2013 11:04, Brian K. White <brian@...> wrote:
On 11/20/2013 10:34 PM, Yamaban wrote:
[snip]
/etc/privoxy
THIS IS A LINK (points to /var/lib/privoxy/etc)
What genius thought it was a good idea to move system-specific config data out of /etc, so that when an admin backs up /etc, they DON'T in fact have all the important stuff they are SUPPOSED to have?
I don't use privoxy or 13.1, this is a general common sense thing and doesn't matter what package or OS.
Have you ever heard of the concept of jailed services, or chrooted daemons?
To put their config in the base systems /etc dir fucks up their working something firce, as they operate only below a specific directory, in case of privoxy this dir is /var/lib/privoxy/ .
Anything outside of this dir is (or should be) invisible, inaccessible, and just not there for these services.
The basics of chrooted daemons should be basic knowlege of anybody that calls him- or herself admin of ANY unix-like system, this includes Linux-Kernel based systems.
For anybody else there are nicely preped lectures on deamons and their workings around for free on the internet.
- Yamaban.
On 11/22/2013 10:00 AM, Yamaban wrote:
On Fri, 22 Nov 2013 11:04, Brian K. White <brian@...> wrote:
On 11/20/2013 10:34 PM, Yamaban wrote:
[snip]
/etc/privoxy
THIS IS A LINK (points to /var/lib/privoxy/etc)
What genius thought it was a good idea to move system-specific config data out of /etc, so that when an admin backs up /etc, they DON'T in fact have all the important stuff they are SUPPOSED to have?
I don't use privoxy or 13.1, this is a general common sense thing and doesn't matter what package or OS.
Have you ever heard of the concept of jailed services, or chrooted daemons?
To put their config in the base systems /etc dir fucks up their working something firce, as they operate only below a specific directory, in case of privoxy this dir is /var/lib/privoxy/ .
Anything outside of this dir is (or should be) invisible, inaccessible, and just not there for these services.
The basics of chrooted daemons should be basic knowlege of anybody that calls him- or herself admin of ANY unix-like system, this includes Linux-Kernel based systems.
For anybody else there are nicely preped lectures on deamons and their workings around for free on the internet.
- Yamaban.
I am quite familiar with chroot jailed services.
If the real info is stored somewhere under /etc, and only a copy is generated on the fly in a jail somewhere else, that is fine. And no reason for any such symlink.
But why stop at jails? You could have 50 containerized instances of the same service. Where should a symlink like that point then?
Pick someone else to impress with your "basic knowledge of unix". ;)
"Brian K. White" brian@aljex.com writes:
If the real info is stored somewhere under /etc, and only a copy is generated on the fly in a jail somewhere else, that is fine.
That won't work if the service is able to change its config files on the fly.
Andreas.
On 11/25/2013 4:15 AM, Andreas Schwab wrote:
"Brian K. White" brian@aljex.com writes:
If the real info is stored somewhere under /etc, and only a copy is generated on the fly in a jail somewhere else, that is fine.
That won't work if the service is able to change its config files on the fly.
Andreas.
If the service needs to do that, then the start script needs to capture and replicate those changes back in /etc. What service does that anyways where the changes are actually supposed to survive restart?
I know isc-dhcpd stores leases which are run-time changes that are preserved across stop-start of the service. But they don't actually matter, it's just a cache and a mild convenience for the clients.
If I back up /etc and restore it on a new machine, the chroot dhcpd works exactly as I had previously configured even though it had to repopulate /var/run on the fly on the new machine. The only config file I ever manually edit is in /etc. The config file the daemon reads is in /var/run but it is copied and updated automatically.
Same for vsftpd. The real config files are in /etc and /etc is the only thing I ever edit, and when I back up /etc I get everything that matters for a new machine.
To be clear, I'm not saying I blindly restore an entire /etc on a new machine. I might if I knew the new machine was the exact same version of suse and had the exact same package list installed, but no I manually pull the important files that I know I need.
You need to be able to back up /etc and know that you actually got everything that matters.
And backing up the entire server is impractical.
Consider the case of, instead of a simple copy backup, you have cvs/svn/git version control your /etc so you can roll back or examine any prior state in history. You can do that easily for /etc, which is supposed to hold mostly just a lot of config data and scripts, and not a lot of binary data, databases, executables, images*. It's fast and efficient, and very valuable, to keep a full version control history of that forever, but not the entire server.
* On a normal desktop system there IS these days a fair amount of fat in /etc but I'm not saying /etc actually attains the ideal, merely saying what the ideal is we should be aiming for and why. In fact it used to attain that ideal pretty well, it has regressed over the years but not intolerably. On servers with no gnome or kde installed it's still pretty good. # du -sh /etc 8.8M /etc
# tar cj /etc >/tmp/x # du -h /tmp/x 1.5M /tmp/x
"Brian K. White" brian@aljex.com writes:
If the service needs to do that, then the start script needs to capture and replicate those changes back in /etc. What service does that anyways where the changes are actually supposed to survive restart?
$SUBJECT
Andreas.
Am Wed, 20 Nov 2013 18:33:06 -0500 schrieb Patrick Shanahan paka@opensuse.org:
up to date Tumbleweed (13.1)
systemctl start privoxy
18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details.
this looks like: https://bugzilla.novell.com/show_bug.cgi?id=849923
with the privoxy.service file attached there privoxy works for me in 13.1.
Dieter
On 11/21/2013 08:20 AM, dieter wrote:
Am Wed, 20 Nov 2013 18:33:06 -0500 schrieb Patrick Shanahan paka@opensuse.org:
up to date Tumbleweed (13.1)
systemctl start privoxy
18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details.
this looks like: https://bugzilla.novell.com/show_bug.cgi?id=849923
with the privoxy.service file attached there privoxy works for me in 13.1.
__________
- many thanks Dieter : i could not locate your attached
privoxy.service file : where may i find it please
thanks
On Thursday 21 November 2013 09.32:33 ellanios82 wrote:
On 11/21/2013 08:20 AM, dieter wrote:
Am Wed, 20 Nov 2013 18:33:06 -0500 schrieb Patrick Shanahan paka@opensuse.org:
up to date Tumbleweed (13.1)
systemctl start privoxy
18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details.
this looks like: https://bugzilla.novell.com/show_bug.cgi?id=849923
with the privoxy.service file attached there privoxy works for me in 13.1.
- many thanks Dieter : i could not locate your attached
privoxy.service file : where may i find it please
thanks
in the first comment the link to the attachement in https://bugzilla.novell.com/attachment.cgi?id=566949
* dieter d_werner@gmx.net [11-21-13 01:23]:
Am Wed, 20 Nov 2013 18:33:06 -0500 schrieb Patrick Shanahan paka@opensuse.org:
up to date Tumbleweed (13.1)
systemctl start privoxy
18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details.
this looks like: https://bugzilla.novell.com/show_bug.cgi?id=849923
with the privoxy.service file attached there privoxy works for me in 13.1.
Diff to delivered service file are "--chroot" and location of config, /etc/config vs /etc/privoxy/config.
After returning /etc/privoxy/config to it's previous state (prior to changes for 13.1), altering my servicefile and "systemctl daemon-reload", privoxy starts as expected for me.
commented bug#849923
tks,
#!/bin/sh #### Trying to connect using privoxy and tor echo " Trying to connect to connect anonimously" echo cd /etc/privoxy sudo /usr/sbin/privoxy sudo /usr/sbin/rctor start echo sudo netstat -tulpn | grep : echo echo "Thank you "
* kafula davidfrans@gmail.com [10-29-14 19:27]:
#!/bin/sh #### Trying to connect using privoxy and tor echo " Trying to connect to connect anonimously" echo cd /etc/privoxy sudo /usr/sbin/privoxy sudo /usr/sbin/rctor start echo sudo netstat -tulpn | grep : echo echo "Thank you "
systemdctl status privoxy
systemctl status privoxy privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities Loaded: loaded (/usr/lib/systemd/system/privoxy.service; enabled) Active: active (running) since Sun 2014-10-12 15:21:52 EDT; 2 weeks 3 days ago Main PID: 2367 (privoxy) CGroup: /system.slice/privoxy.service └─2367 /usr/sbin/privoxy --chroot --pidfile /run/privoxy.pid --user privoxy /etc/config
did it ever? what did you change? how are you trying to start it what system
Is any of the above really necessary?
El 29/10/14 a las #4, kafula escribió:
#!/bin/sh #### Trying to connect using privoxy and tor echo " Trying to connect to connect anonimously" echo cd /etc/privoxy sudo /usr/sbin/privoxy sudo /usr/sbin/rctor start echo sudo netstat -tulpn | grep : echo echo "Thank you "
Your message is completely useless.. you said "systemd cannot start privoxy" yet you show no error log nor the result systemctl status privoxyd (or whatever the .service is called)
-
Andreas Schwab -
Brian K. White -
Bruno Friedmann -
Cristian Rodríguez -
dieter -
ellanios82 -
kafula -
Patrick Shanahan -
Yamaban