* 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, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* 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 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* 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:

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

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 :^). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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". ;) -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

#!/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 " -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org